[Intel-gfx] ✓ Fi.CI.BAT: success for Add crtc i915_pipe debugfs file
== Series Details == Series: Add crtc i915_pipe debugfs file URL : https://patchwork.freedesktop.org/series/115343/ State : success == Summary == CI Bug Log - changes from CI_DRM_12878 -> Patchwork_115343v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/index.html Participating hosts (34 -> 34) -- Additional (1): bat-atsm-1 Missing(1): bat-dg1-6 Known issues Here are the changes found in Patchwork_115343v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-elk-e7500: NOTRUN -> [SKIP][7] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/fi-elk-e7500/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][8] ([i915#5354]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - fi-elk-e7500: [DMESG-FAIL][9] -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - fi-elk-e7500: [ABORT][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][13] ([i915#8073]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html Warnings * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][15] ([i915#7911] / [i915#7913]) -> [INCOMPLETE][16] ([i915#6972] / [i915#7913]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][17] ([i915#6367] / [i915#7996]) -> [DMESG-FAIL][18] ([i915#6367]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/bat-rpls-1/igt@i915_selftest@l...@slpc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115343v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079 [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6972]: https://gitlab.freedesktop.org/drm/intel/issues/6972 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7996]: https://gitlab.f
[Intel-gfx] ✓ Fi.CI.IGT: success for Add MTL DP and HDMI Sequences
== Series Details ==
Series: Add MTL DP and HDMI Sequences
URL : https://patchwork.freedesktop.org/series/115339/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12878_full -> Patchwork_115339v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115339v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_vblank@pipe-d-ts-continuation-dpms-suspend:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-dg1-15/igt@kms_vbl...@pipe-d-ts-continuation-dpms-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-dg1-14/igt@kms_vbl...@pipe-d-ts-continuation-dpms-suspend.html
Known issues
Here are the changes found in Patchwork_115339v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk4/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl: [PASS][5] -> [SKIP][6] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-apl3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-apl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-apl7/igt@gem_lmem_swapp...@heavy-random.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][10] -> [ABORT][11] ([i915#5566])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3886]) +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-apl1/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-glk7/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-shrfb-draw-mmap-cpu:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +76 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-apl1/igt@kms_frontbuffer_track...@psr-2p-scndscrn-pri-shrfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@constant-alpha-max@pipe-c-dp-1:
- shard-apl: NOTRUN -> [FAIL][15] ([i915#4573]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-apl1/igt@kms_plane_alpha_blend@constant-alpha-...@pipe-c-dp-1.html
* igt@kms_psr2_su@page_flip-p010:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-apl7/igt@kms_psr2_su@page_flip-p010.html
Possible fixes
* igt@device_reset@unbind-reset-rebind:
- {shard-rkl}:[FAIL][17] ([i915#4778]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-rkl-5/igt@device_re...@unbind-reset-rebind.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-rkl-6/igt@device_re...@unbind-reset-rebind.html
* igt@drm_read@short-buffer-nonblock:
- {shard-rkl}:[SKIP][19] ([i915#4098]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-rkl-5/igt@drm_r...@short-buffer-nonblock.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/shard-rkl-6/igt@drm_r...@short-buffer-nonblock.html
* i
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add crtc i915_pipe debugfs file
== Series Details == Series: Add crtc i915_pipe debugfs file URL : https://patchwork.freedesktop.org/series/115343/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./drivers/gpu/drm/i915/intel_uncore.h:351:1: warning: trying to copy expression type 31 +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced s
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add crtc i915_pipe debugfs file
== Series Details == Series: Add crtc i915_pipe debugfs file URL : https://patchwork.freedesktop.org/series/115343/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] ✗ Fi.CI.BUILD: warning for Add crtc i915_pipe debugfs file
== Series Details == Series: Add crtc i915_pipe debugfs file URL : https://patchwork.freedesktop.org/series/115343/ State : warning == Summary == Error: git fetch origin failed
Re: [Intel-gfx] [PATCH 1/4] drm/i915/mtl: Squashed Phy Support
Hi Radhakrishna,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Radhakrishna-Sripada/drm-i915-mtl-Squashed-Phy-Support/20230318-090025
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230318005852.2303937-2-radhakrishna.sripada%40intel.com
patch subject: [Intel-gfx] [PATCH 1/4] drm/i915/mtl: Squashed Phy Support
config: x86_64-randconfig-a016-20230313
(https://download.01.org/0day-ci/archive/20230318/202303181322.tigxe4wa-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/09eaa092cb75c3ac2a82dbf3b83bff437be2abfa
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Radhakrishna-Sripada/drm-i915-mtl-Squashed-Phy-Support/20230318-090025
git checkout 09eaa092cb75c3ac2a82dbf3b83bff437be2abfa
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303181322.tigxe4wa-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_cx0_phy.c:2174:13: warning: variable
>> 'multiplier' is used uninitialized whenever 'if' condition is false
>> [-Wsometimes-uninitialized]
} else if (pll_state->mplla[6] & C20_MPLLA_FRACEN) {
^~
drivers/gpu/drm/i915/display/intel_cx0_phy.c:2184:10: note: uninitialized
use occurs here
tmp2 = (multiplier << 15) + frac_quot +
DIV_ROUND_CLOSEST(frac_rem,frac_den);
^~
drivers/gpu/drm/i915/display/intel_cx0_phy.c:2174:9: note: remove the 'if'
if its condition is always true
} else if (pll_state->mplla[6] & C20_MPLLA_FRACEN) {
^~~~
drivers/gpu/drm/i915/display/intel_cx0_phy.c:2162:25: note: initialize the
variable 'multiplier' to silence this warning
unsigned int multiplier, refclk = 38400;
^
= 0
1 warning generated.
vim +2174 drivers/gpu/drm/i915/display/intel_cx0_phy.c
2157
2158 int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
2159 const struct intel_c20pll_state
*pll_state)
2160 {
2161 unsigned int frac_quot = 0, frac_rem = 0, frac_den = 1;
2162 unsigned int multiplier, refclk = 38400;
2163 unsigned ref_clk_mpllb_div = 0;
2164 unsigned fb_clk_div4_en = 0;
2165 unsigned long tmp1, tmp2;
2166
2167 if (pll_state->mpllb[6] & C20_MPLLB_FRACEN) {
2168 multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK,
pll_state->mpllb[0]);
2169 ref_clk_mpllb_div =
REG_FIELD_GET(C20_REF_CLK_MPLLB_DIV_MASK, pll_state->mpllb[6]);
2170 fb_clk_div4_en = REG_FIELD_GET(C20_FB_CLK_DIV4_EN,
pll_state->mpllb[6]);
2171 frac_den = pll_state->mpllb[7];
2172 frac_quot = pll_state->mpllb[8];
2173 frac_rem = pll_state->mpllb[9];
> 2174 } else if (pll_state->mplla[6] & C20_MPLLA_FRACEN) {
2175 multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK,
pll_state->mplla[0]);
2176 ref_clk_mpllb_div =
REG_FIELD_GET(C20_REF_CLK_MPLLB_DIV_MASK, pll_state->mpllb[6]);
2177 fb_clk_div4_en = REG_FIELD_GET(C20_FB_CLK_DIV4_EN,
pll_state->mpllb[6]);
2178 frac_den = pll_state->mpllb[7];
2179 frac_quot = pll_state->mplla[8];
2180 frac_rem = pll_state->mplla[9];
2181 }
2182
2183 tmp1 = DIV_ROUND_CLOSEST(refclk * (1 << (1 + fb_clk_div4_en)),
1 << ref_clk_mpllb_div);
2184 tmp2 = (multiplier << 15) + frac_quot +
DIV_ROUND_CLOSEST(frac_rem,frac_den);
2185
2186 return DIV_ROUND_CLOSEST((tmp1 * tmp2) >> 17, 10);
2187 }
2188
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3)
== Series Details ==
Series: series starting with [v2,1/4] drm/i915: Update vblank timestamping
stuff on seamless M/N change (rev3)
URL : https://patchwork.freedesktop.org/series/114999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12878_full -> Patchwork_114999v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114999v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_softpin@evict-prime-sanity-check@vecs0:
- {shard-tglu}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-tglu-4/igt@gem_softpin@evict-prime-sanity-ch...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-tglu-6/igt@gem_softpin@evict-prime-sanity-ch...@vecs0.html
Known issues
Here are the changes found in Patchwork_114999v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk4/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl: [PASS][5] -> [SKIP][6] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-apl3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-apl3/igt@gem_lmem_swapp...@heavy-random.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][10] -> [ABORT][11] ([i915#5566])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3886]) +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-apl2/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-glk1/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-shrfb-draw-mmap-cpu:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +76 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-apl2/igt@kms_frontbuffer_track...@psr-2p-scndscrn-pri-shrfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@constant-alpha-max@pipe-c-dp-1:
- shard-apl: NOTRUN -> [FAIL][15] ([i915#4573]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-apl2/igt@kms_plane_alpha_blend@constant-alpha-...@pipe-c-dp-1.html
* igt@kms_psr2_su@page_flip-p010:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-apl3/igt@kms_psr2_su@page_flip-p010.html
* igt@perf@stress-open-close:
- shard-glk: [PASS][17] -> [ABORT][18] ([i915#5213])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk5/igt@p...@stress-open-close.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/shard-glk2/igt@p...@stress-open-close.html
Possible fixes
* igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +9 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-rkl-2/igt@api_intel...@object-reloc-keep-cache.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/s
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Don't use stolen memory for ring buffers with LLC (rev5)
== Series Details == Series: drm/i915: Don't use stolen memory for ring buffers with LLC (rev5) URL : https://patchwork.freedesktop.org/series/115334/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115334/revisions/5/mbox/ not applied Applying: drm/i915: Don't use stolen memory for ring buffers with LLC Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_ring.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_ring.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_ring.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Don't use stolen memory for ring buffers with LLC When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
[Intel-gfx] ✓ Fi.CI.BAT: success for Add MTL DP and HDMI Sequences
== Series Details == Series: Add MTL DP and HDMI Sequences URL : https://patchwork.freedesktop.org/series/115339/ State : success == Summary == CI Bug Log - changes from CI_DRM_12878 -> Patchwork_115339v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/index.html Participating hosts (34 -> 33) -- Additional (1): bat-atsm-1 Missing(2): bat-dg1-6 fi-pnv-d510 Known issues Here are the changes found in Patchwork_115339v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-atsm-1/igt@fb...@eof.html * igt@gem_exec_suspend@basic-s3@smem: - fi-cfl-8700k: [PASS][2] -> [ABORT][3] ([i915#8213]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-cfl-8700k/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-cfl-8700k/igt@gem_exec_suspend@basic...@smem.html - bat-rpls-1: [PASS][4] -> [ABORT][5] ([i915#6687] / [i915#7978]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#4083]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][7] ([i915#8062]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#4077]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#4079]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][10] ([i915#8060]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][11] -> [ABORT][12] ([i915#7911] / [i915#7913]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][13] -> [TIMEOUT][14] ([i915#6794]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/bat-rpls-1/igt@i915_selftest@l...@mman.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-elk-e7500: NOTRUN -> [SKIP][15] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-elk-e7500/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-n3050: NOTRUN -> [SKIP][16] ([fdo#109271]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - fi-elk-e7500: [DMESG-FAIL][17] -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - fi-elk-e7500: [ABORT][19] -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][21] ([i915#7911] / [i915#7913]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115339v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][23] ([i915#8073]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-skl-guc/igt@i915_selftest@l...@h
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Add MTL DP and HDMI Sequences
== Series Details == Series: Add MTL DP and HDMI Sequences URL : https://patchwork.freedesktop.org/series/115339/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add MTL DP and HDMI Sequences
== Series Details == Series: Add MTL DP and HDMI Sequences URL : https://patchwork.freedesktop.org/series/115339/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add MTL DP and HDMI Sequences
== Series Details == Series: Add MTL DP and HDMI Sequences URL : https://patchwork.freedesktop.org/series/115339/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] [V2 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
From: Jani Nikula
The pipe may differ from crtc index if pipes are fused off. For testing
purposes, IGT needs to know the pipe.
There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
the upcoming Xe driver won't have that IOCTL, and going forward, we'll
want a unified interface for testing i915 and Xe, as they share the
display code. Thus add the debugfs for i915 display.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 29c049aac252..4e489f5aade7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file *m,
void *data)
}
DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
+/* Pipe may differ from crtc index if pipes are fused off */
+static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
+{
+ struct intel_crtc *crtc = m->private;
+
+ seq_printf(m, "%d\n", crtc->pipe);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
debugfs_create_file("i915_current_bpc", 0444, root, crtc,
&i915_current_bpc_fops);
+ debugfs_create_file("i915_pipe", 0444, root, crtc,
+ &intel_crtc_pipe_fops);
}
--
2.40.0
[Intel-gfx] [V2 1/2] drm/i915/debugfs: switch crtc debugfs to struct intel_crtc
From: Jani Nikula
Convert the crtc debugfs code to use struct intel_crtc instead of struct
drm_crtc.
V2: - Fix build failures in CI
Signed-off-by: Jani Nikula
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
.../drm/i915/display/intel_display_debugfs.c | 22 ++-
.../drm/i915/display/intel_display_debugfs.h | 6 ++---
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index b79a8834559f..60e52c5abd82 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -212,7 +212,7 @@ static void intel_crtc_destroy(struct drm_crtc *_crtc)
static int intel_crtc_late_register(struct drm_crtc *crtc)
{
- intel_crtc_debugfs_add(crtc);
+ intel_crtc_debugfs_add(to_intel_crtc(crtc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 65585f19c6c8..29c049aac252 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -805,10 +805,10 @@ static const struct file_operations crtc_updates_fops = {
.write = crtc_updates_write
};
-static void crtc_updates_add(struct drm_crtc *crtc)
+static void crtc_updates_add(struct intel_crtc *crtc)
{
- debugfs_create_file("i915_update_info", 0644, crtc->debugfs_entry,
- to_intel_crtc(crtc), &crtc_updates_fops);
+ debugfs_create_file("i915_update_info", 0644, crtc->base.debugfs_entry,
+ crtc, &crtc_updates_fops);
}
#else
@@ -818,7 +818,7 @@ static void crtc_updates_info(struct seq_file *m,
{
}
-static void crtc_updates_add(struct drm_crtc *crtc)
+static void crtc_updates_add(struct intel_crtc *crtc)
{
}
#endif
@@ -1640,7 +1640,7 @@ static const struct file_operations i915_dsc_bpc_fops = {
*/
static int i915_current_bpc_show(struct seq_file *m, void *data)
{
- struct intel_crtc *crtc = to_intel_crtc(m->private);
+ struct intel_crtc *crtc = m->private;
struct intel_crtc_state *crtc_state;
int ret;
@@ -1722,15 +1722,17 @@ void intel_connector_debugfs_add(struct intel_connector
*intel_connector)
*
* Failure to add debugfs entries should generally be ignored.
*/
-void intel_crtc_debugfs_add(struct drm_crtc *crtc)
+void intel_crtc_debugfs_add(struct intel_crtc *crtc)
{
- if (!crtc->debugfs_entry)
+ struct dentry *root = crtc->base.debugfs_entry;
+
+ if (!root)
return;
crtc_updates_add(crtc);
- intel_drrs_crtc_debugfs_add(to_intel_crtc(crtc));
- intel_fbc_crtc_debugfs_add(to_intel_crtc(crtc));
+ intel_drrs_crtc_debugfs_add(crtc);
+ intel_fbc_crtc_debugfs_add(crtc);
- debugfs_create_file("i915_current_bpc", 0444, crtc->debugfs_entry, crtc,
+ debugfs_create_file("i915_current_bpc", 0444, root, crtc,
&i915_current_bpc_fops);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
index d3a79c07c384..e1f479b7acd1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
@@ -6,18 +6,18 @@
#ifndef __INTEL_DISPLAY_DEBUGFS_H__
#define __INTEL_DISPLAY_DEBUGFS_H__
-struct drm_crtc;
struct drm_i915_private;
struct intel_connector;
+struct intel_crtc;
#ifdef CONFIG_DEBUG_FS
void intel_display_debugfs_register(struct drm_i915_private *i915);
void intel_connector_debugfs_add(struct intel_connector *connector);
-void intel_crtc_debugfs_add(struct drm_crtc *crtc);
+void intel_crtc_debugfs_add(struct intel_crtc *crtc);
#else
static inline void intel_display_debugfs_register(struct drm_i915_private
*i915) {}
static inline void intel_connector_debugfs_add(struct intel_connector
*connector) {}
-static inline void intel_crtc_debugfs_add(struct drm_crtc *crtc) {}
+static inline void intel_crtc_debugfs_add(struct intel_crtc *crtc) {}
#endif
#endif /* __INTEL_DISPLAY_DEBUGFS_H__ */
--
2.40.0
[Intel-gfx] [V2 0/2] Add crtc i915_pipe debugfs file
The pipe may differ from crtc index if pipes are fused off. For testing purposes, IGT needs to know the pipe. There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However, the upcoming Xe driver won't have that IOCTL, and going forward, we'll want a unified interface for testing i915 and Xe, as they share the display code. Thus add the debugfs for i915 display. Test-with: 20230317165044.2616573-1-bhanuprakash.mo...@intel.com Jani Nikula (2): drm/i915/debugfs: switch crtc debugfs to struct intel_crtc drm/i915/debugfs: add crtc i915_pipe debugfs file drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- .../drm/i915/display/intel_display_debugfs.c | 35 +-- .../drm/i915/display/intel_display_debugfs.h | 6 ++-- 3 files changed, 29 insertions(+), 14 deletions(-) -- 2.40.0
Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC
On 3/17/2023 05:58, Greg KH wrote:
On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
On 3/15/2023 10:57, Greg KH wrote:
On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
On 3/15/2023 00:51, Greg KH wrote:
On Mon, Mar 13, 2023 at 07:22:11PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula
(cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Also queued up for 5.10.y, you forgot that one :)
I'm still working through the backlog of them.
Note that these patches must all be applied as a pair. The 'don't use
stolen' can be applied in isolation but won't totally fix the problem.
However, applying 'don't use BAR mappings' without applying the stolen patch
first will results in problems such as the failure to boot that was recently
reported and resulted in a revert in one of the trees.
I do not understand, you only submitted 1 patch here, what is the
"pair"?
The original patch series was two patches -
https://patchwork.freedesktop.org/series/114080/. One to not use stolen
memory and the other to not use BAR mappings. If the anti-BAR patch is
applied without the anti-stolen patch then the i915 driver will attempt to
access stolen memory directly which will fail. So both patches must be
applied and in the correct order to fix the problem of cache aliasing when
using BAR accesses on LLC systems.
As above, I am working my way through the bunch of 'FAILED patch' emails.
The what-to-do instructions in those emails explicitly say to send the patch
individually in reply to the 'FAILED' message rather than as part of any
original series.
So what commits exactly in Linus's tree should be in these stable
branches? Sorry, I still do not understand if we are missing one or if
we need to revert something.
confused,
greg k-h
As far as I can tell, I have replied to all the "FAILED: patch" emails
now. There should be a versions of these two patches available for all
trees (being 4.14, 4.19, 5.4, 5.10 and 5.15):
690e0ec8e63d drm/i915: Don't use stolen memory for ring buffers
with LLC
85636167e320 drm/i915: Don't use BAR mappings for ring buffers with LLC
They should be applied in the order of 'stolen memory' first and 'BAR
mappings' second.
Thanks,
John.
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3) URL : https://patchwork.freedesktop.org/series/114999/ State : success == Summary == CI Bug Log - changes from CI_DRM_12878 -> Patchwork_114999v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/index.html Participating hosts (34 -> 34) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_114999v3 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][1] -> [ABORT][2] ([i915#7911] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: [PASS][3] -> [ABORT][4] ([i915#4983]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#4983]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/bat-rpls-1/igt@i915_selftest@l...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-elk-e7500: NOTRUN -> [SKIP][7] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-elk-e7500/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-n3050: NOTRUN -> [SKIP][8] ([fdo#109271]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#5354]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - fi-elk-e7500: [DMESG-FAIL][10] -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - fi-elk-e7500: [ABORT][12] -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][14] ([i915#7911] / [i915#7913]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][16] ([i915#8073]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114999v3/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 Build changes - * Linux: CI_DRM_12878 -> Patchwork_114999v3 CI-20190529: 20190529 CI_DRM_12878: 80a77071b23a1ef75b5446cd397dd9048580ec8d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7204: 0dc71800a0dd867e1fa32ee01c2dbf42b46ec3e2 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114999v3: 80a77071b23a1ef75b5446cd397dd9048580ec8d @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits d2173e7648a7 drm/i915: Extract intel_crtc_scanline_offset() 8bf688807786 drm/i915: Relocate intel_crtc_update_active_timings() a185f7772761 drm/i915: Add belts and suspenders locking for seamless M/N changes b082181116ba drm/i915: Update vblank timestamping stuff on seamless M/N change == Logs == For more
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3) URL : https://patchwork.freedesktop.org/series/114999/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3) URL : https://patchwork.freedesktop.org/series/114999/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:11
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev3) URL : https://patchwork.freedesktop.org/series/114999/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] Reverted patch reappears!
Jani/Rodrigo,
Original Subject: Re: [Intel-gfx] [PATCH] Revert "drm/i915/hwmon: Enable PL1
power limit"
On Wed, 15 Feb 2023 09:19:07 -0800, Rodrigo Vivi wrote:
>
> On Wed, Feb 15, 2023 at 08:24:51AM -0800, Dixit, Ashutosh wrote:
> > On Wed, 15 Feb 2023 07:37:30 -0800, Jani Nikula wrote:
> > >
> > > On Wed, 08 Feb 2023, Rodrigo Vivi wrote:
> > > > On Wed, Feb 08, 2023 at 11:03:12AM -0800, Ashutosh Dixit wrote:
> > > >> This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610.
> > > >>
> > > >> 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect
> > > >> and
> > > >> caused a major regression on ATSM. The change enabled the PL1 power
> > > >> limit
> > > >> but FW sets the default value of the PL1 limit to 0 which implies HW
> > > >> now
> > > >> works at minimum power and therefore the lowest effective frequency.
> > > >> This
> > > >> means all workloads now run slower resulting in even GuC FW load
> > > >> operations
> > > >> timing out, rendering ATSM unusable.
> > > >>
> > > >> A different solution to the original issue of the PL1 limit being
> > > >> disabled
> > > >> on ATSM is needed but till that is developed, revert 0349c41b0596.
> > > >>
> > > >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
> > > >
> > > > pushed to drm-intel-next and removed from drm-intel-fixes.
> > > >
> > > > Thanks for the quick reaction.
> > >
> > > Please always add Fixes: tags also to reverts.
> > >
> > > I suppose we should fix dim to also detect reverts, but I ended up
> > > cherry-picking and pushing the original commit out to
> > > drm-intel-next-fixes before realizing it's been reverted.
> >
> > Oops, sorry!
>
> That's my mistake. I should had thought about this when pushing
> and removing from the fixes. I just realized yet, when this patch
> showed up in my -fixes cherry-pick again, but without the revert.
>
> I'm sorry.
Not sure if it's related to this, but the reverted patch below has
reappeared on drm-tip. Newest on top:
ee892ea83d996 drm/i915/hwmon: Enable PL1 power limit
05d5562e401eb Revert "drm/i915/hwmon: Enable PL1 power limit"
0349c41b05968 drm/i915/hwmon: Enable PL1 power limit
The new patch is:
commit ee892ea83d99610fa33bea612de058e0955eec3a
Author: Ashutosh Dixit
AuthorDate: Fri Feb 3 07:53:09 2023 -0800
Commit: Jani Nikula
CommitDate: Mon Mar 13 11:38:05 2023 +0200
drm/i915/hwmon: Enable PL1 power limit
Sorry I couldn't track which branch did this new patch come from (looks
like drm-tip itself?).
This is breaking ATSM again:
https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
so needs to be reverted again and stay reverted. I could send a revert or
any of you can also do it.
Thanks.
--
Ashutosh
[Intel-gfx] [PATCH 5.15.y] drm/i915: Don't use stolen memory for ring buffers with LLC
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula
(cherry picked from commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index 7c4d5158e03b..7d82545d15e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -113,7 +113,7 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt
*ggtt, int size)
struct i915_vma *vma;
obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE);
- if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
+ if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);
--
2.39.1
[Intel-gfx] ✓ Fi.CI.IGT: success for Add OAM support for MTL
== Series Details ==
Series: Add OAM support for MTL
URL : https://patchwork.freedesktop.org/series/115330/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12878_full -> Patchwork_115330v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115330v1_full:
### IGT changes ###
Possible regressions
* {igt@perf@gen12-group-exclusive-stream-ctx-handle} (NEW):
- shard-apl: NOTRUN -> [FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-apl7/igt@p...@gen12-group-exclusive-stream-ctx-handle.html
- shard-glk: NOTRUN -> [FAIL][2] +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-glk4/igt@p...@gen12-group-exclusive-stream-ctx-handle.html
* {igt@perf@global-sseu-config-invalid@0-rcs0} (NEW):
- {shard-tglu}: NOTRUN -> [SKIP][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-tglu-9/igt@perf@global-sseu-config-inva...@0-rcs0.html
* {igt@perf@global-sseu-config@0-rcs0} (NEW):
- {shard-rkl}:NOTRUN -> [SKIP][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-rkl-5/igt@perf@global-sseu-con...@0-rcs0.html
- {shard-dg1}:NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-dg1-15/igt@perf@global-sseu-con...@0-rcs0.html
New tests
-
New tests have been introduced between CI_DRM_12878_full and
Patchwork_115330v1_full:
### New IGT tests (17) ###
* igt@perf@blocking@0-rcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s
* igt@perf@buffer-fill@0-rcs0:
- Statuses : 5 pass(s)
- Exec time: [0.0] s
* igt@perf@enable-disable@0-rcs0:
- Statuses : 5 pass(s)
- Exec time: [0.0] s
* igt@perf@gen12-group-concurrent-oa-buffer-read:
- Statuses : 4 pass(s) 1 skip(s)
- Exec time: [0.0] s
* igt@perf@gen12-group-exclusive-stream-ctx-handle:
- Statuses : 2 fail(s) 2 pass(s) 1 skip(s)
- Exec time: [0.0] s
* igt@perf@gen12-group-exclusive-stream-sample-oa:
- Statuses : 2 fail(s) 2 pass(s) 1 skip(s)
- Exec time: [0.0] s
* igt@perf@gen12-invalid-class-instance:
- Statuses : 4 pass(s) 1 skip(s)
- Exec time: [0.0] s
* igt@perf@gen12-mi-rpc@rcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s
* igt@perf@gen12-oa-tlb-invalidate@0-rcs0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@perf@gen12-unprivileged-single-ctx-counters@rcs0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@perf@global-sseu-config-invalid@0-rcs0:
- Statuses : 4 skip(s)
- Exec time: [0.0] s
* igt@perf@global-sseu-config@0-rcs0:
- Statuses : 5 skip(s)
- Exec time: [0.0] s
* igt@perf@non-zero-reason@0-rcs0:
- Statuses : 5 pass(s)
- Exec time: [0.0] s
* igt@perf@oa-exponents@0-rcs0:
- Statuses : 5 pass(s)
- Exec time: [0.0] s
* igt@perf@oa-formats@0-rcs0:
- Statuses : 4 pass(s)
- Exec time: [0.0] s
* igt@perf@polling@0-rcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s
* igt@perf@stress-open-close@0-rcs0:
- Statuses : 4 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_115330v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk4/igt@gem_exec_f...@basic-deadline.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-apl6/igt@gem_lmem_swapp...@heavy-random.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][11] -> [ABORT][12] ([i915#5566])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_dc@dc9-dpms:
- shard-apl: [PASS][1
[Intel-gfx] [PATCH 2/4] drm/i915/mtl/display: Implement DisplayPort sequences
From: José Roberto de Souza
The differences between MTL and TGL DP sequences are big enough to
MTL have its own functions.
Also it is much easier to follow MTL sequences against spec with
its own functions.
One change worthy to mention is the move of
'intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain)'.
This call is not necessary for MTL but we have _put() counter part in
intel_ddi_post_disable_dp() that needs to balanced.
We could add a display version check on it but instead here it is
moving it to intel_ddi_pre_enable_dp() so it is executed for all
platforms in a single place and this will not cause any harm in MTL
and newer platforms.
BSpec: 65448 65505
Cc: Matt Roper
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
Signed-off-by: Mika Kahola
---
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 8 +
drivers/gpu/drm/i915/display/intel_ddi.c | 372 +-
drivers/gpu/drm/i915/i915_reg.h | 5 +
3 files changed, 366 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index f8917f20a151..a4901aa41ad5 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -72,9 +72,17 @@
_XELPDP_PORT_BUF_CTL1_LN0_B, \
_XELPDP_PORT_BUF_CTL1_LN0_USBC1, \
_XELPDP_PORT_BUF_CTL1_LN0_USBC2))
+#define XELPDP_PORT_BUF_D2D_LINK_ENABLE REG_BIT(29)
+#define XELPDP_PORT_BUF_D2D_LINK_STATEREG_BIT(28)
#define XELPDP_PORT_BUF_SOC_PHY_READY REG_BIT(24)
+#define XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK REG_GENMASK(19, 18)
+#define XELPDP_PORT_BUF_PORT_DATA_10BIT
REG_FIELD_PREP(XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK, 0)
+#define XELPDP_PORT_BUF_PORT_DATA_20BIT
REG_FIELD_PREP(XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK, 1)
+#define XELPDP_PORT_BUF_PORT_DATA_40BIT
REG_FIELD_PREP(XELPDP_PORT_BUF_PORT_DATA_WIDTH_MASK, 2)
#define XELPDP_PORT_REVERSAL REG_BIT(16)
+#define XELPDP_PORT_BUF_IO_SELECTION REG_BIT(11)
+#define XELPDP_PORT_BUF_PHY_IDLE REG_BIT(7)
#define XELPDP_TC_PHY_OWNERSHIPREG_BIT(6)
#define XELPDP_TCSS_POWER_REQUEST REG_BIT(5)
#define XELPDP_TCSS_POWER_STATEREG_BIT(4)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 774e09825bfb..1efa3b6f4101 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -40,6 +40,7 @@
#include "intel_connector.h"
#include "intel_crtc.h"
#include "intel_cx0_phy.h"
+#include "intel_cx0_phy_regs.h"
#include "intel_ddi.h"
#include "intel_ddi_buf_trans.h"
#include "intel_de.h"
@@ -170,6 +171,18 @@ static void hsw_prepare_hdmi_ddi_buffers(struct
intel_encoder *encoder,
trans->entries[level].hsw.trans2);
}
+static void mtl_wait_ddi_buf_idle(struct drm_i915_private *i915, enum port
port)
+{
+ int ret;
+
+ /* FIXME: find out why Bspec's 100us timeout is too short */
+ ret = wait_for_us((intel_de_read(i915, XELPDP_PORT_BUF_CTL1(port)) &
+ XELPDP_PORT_BUF_PHY_IDLE), 1);
+ if (ret)
+ drm_err(&i915->drm, "Timeout waiting for DDI BUF %c to get
idle\n",
+ port_name(port));
+}
+
void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
enum port port)
{
@@ -197,7 +210,9 @@ static void intel_wait_ddi_buf_active(struct
drm_i915_private *dev_priv,
return;
}
- if (IS_DG2(dev_priv)) {
+ if (DISPLAY_VER(dev_priv) >= 14) {
+ timeout_us = 1;
+ } else if (IS_DG2(dev_priv)) {
timeout_us = 1200;
} else if (DISPLAY_VER(dev_priv) >= 12) {
if (intel_phy_is_tc(dev_priv, phy))
@@ -208,8 +223,12 @@ static void intel_wait_ddi_buf_active(struct
drm_i915_private *dev_priv,
timeout_us = 500;
}
- ret = _wait_for(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
- DDI_BUF_IS_IDLE), timeout_us, 10, 10);
+ if (DISPLAY_VER(dev_priv) >= 14)
+ ret = _wait_for(!(intel_de_read(dev_priv,
XELPDP_PORT_BUF_CTL1(port)) & XELPDP_PORT_BUF_PHY_IDLE),
+ timeout_us, 10, 10);
+ else
+ ret = _wait_for(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
DDI_BUF_IS_IDLE),
+ timeout_us, 10, 10
[Intel-gfx] [PATCH 3/4] drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI
From: Ankit Nautiyal
MTL requires the PORT_CTL_WIDTH, TRANS_DDI_FUNC_CTL and DDI_BUF_CTL
to be filled with 4 lanes for TMDS mode.
This patch enables D2D link and fills PORT_WIDTH in appropriate
registers.
Signed-off-by: Ankit Nautiyal
Signed-off-by: Taylor, Clinton A
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_ddi.c | 48 +---
drivers/gpu/drm/i915/i915_reg.h | 2 +
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1efa3b6f4101..a5a0b76c1b10 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -542,6 +542,8 @@ intel_ddi_transcoder_func_reg_val_get(struct intel_encoder
*encoder,
temp |= TRANS_DDI_HDMI_SCRAMBLING;
if (crtc_state->hdmi_high_tmds_clock_ratio)
temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
+ if (DISPLAY_VER(dev_priv) >= 14)
+ temp |= TRANS_DDI_PORT_WIDTH(crtc_state->lane_count);
} else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
temp |= (crtc_state->fdi_lanes - 1) << 1;
@@ -3142,6 +3144,10 @@ static void intel_enable_ddi_hdmi(struct
intel_atomic_state *state,
if (has_buf_trans_select(dev_priv))
hsw_prepare_hdmi_ddi_buffers(encoder, crtc_state);
+ /* e. Enable D2D Link for C10/C20 Phy */
+ if (DISPLAY_VER(dev_priv) >= 14)
+ mtl_ddi_enable_d2d(encoder);
+
encoder->set_signal_levels(encoder, crtc_state);
/* Display WA #1143: skl,kbl,cfl */
@@ -3187,13 +3193,39 @@ static void intel_enable_ddi_hdmi(struct
intel_atomic_state *state,
*
* On ADL_P the PHY link rate and lane count must be programmed but
* these are both 0 for HDMI.
+*
+* But MTL onwards HDMI2.1 is supported and in TMDS mode this
+* is always filled with 4 lanes, already set in the crtc_state.
+* The same is required to be filled in PORT_BUF_CTL for C10/20 Phy.
*/
- buf_ctl = dig_port->saved_port_bits | DDI_BUF_CTL_ENABLE;
- if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy)) {
- drm_WARN_ON(&dev_priv->drm,
!intel_tc_port_in_legacy_mode(dig_port));
- buf_ctl |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
+ if (DISPLAY_VER(dev_priv) >= 14) {
+ u32 ddi_buf = 0;
+ u8 lane_count = mtl_get_port_width(crtc_state->lane_count);
+ u32 port_buf = 0;
+
+ port_buf |= XELPDP_PORT_WIDTH(lane_count);
+
+ if (intel_bios_encoder_lane_reversal(encoder->devdata))
+ port_buf |= XELPDP_PORT_REVERSAL;
+
+ intel_de_rmw(dev_priv, XELPDP_PORT_BUF_CTL1(port), 0, port_buf);
+
+ ddi_buf |= DDI_BUF_CTL_ENABLE |
+ DDI_PORT_WIDTH(lane_count);
+
+ intel_de_write(dev_priv, DDI_BUF_CTL(port),
+ dig_port->saved_port_bits | ddi_buf);
+
+ /* i. Poll for PORT_BUF_CTL Idle Status == 0, timeout after 100
us */
+ intel_wait_ddi_buf_active(dev_priv, port);
+ } else {
+ buf_ctl = dig_port->saved_port_bits | DDI_BUF_CTL_ENABLE;
+ if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy))
{
+ drm_WARN_ON(&dev_priv->drm,
!intel_tc_port_in_legacy_mode(dig_port));
+ buf_ctl |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
+ }
+ intel_de_write(dev_priv, DDI_BUF_CTL(port), buf_ctl);
}
- intel_de_write(dev_priv, DDI_BUF_CTL(port), buf_ctl);
intel_wait_ddi_buf_active(dev_priv, port);
@@ -3702,7 +3734,11 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
fallthrough;
case TRANS_DDI_MODE_SELECT_DVI:
pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
- pipe_config->lane_count = 4;
+ if (DISPLAY_VER(dev_priv) >= 14)
+ pipe_config->lane_count =
+ ((temp & DDI_PORT_WIDTH_MASK) >>
DDI_PORT_WIDTH_SHIFT) + 1;
+ else
+ pipe_config->lane_count = 4;
break;
case TRANS_DDI_MODE_SELECT_DP_SST:
if (encoder->type == INTEL_OUTPUT_EDP)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 82c9ba8f44b6..4c89f706481b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6751,6 +6751,8 @@ enum skl_power_gate {
#define TRANS_DDI_HDCP_SELECT REG_BIT(5)
#define TRANS_DDI_BFI_ENABLE (1 << 4)
#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1 << 4)
+#define TRANS_DDI_PORT_WIDTH_MASK REG_GENMAS
[Intel-gfx] [PATCH 4/4] drm/i915/mtl: Skip pcode qgv restrictions for MTL
Communicating QGV points restriction to PUnit happens via PM Demand
instead of the Pcode mailbox in the previous platforms. GV point
restriction is handled by the PM demand code.
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 87c20bf52123..c292e63bdcbb 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -150,6 +150,9 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
{
int ret;
+ if (DISPLAY_VER(dev_priv) >= 14)
+ return 0;
+
/* bspec says to keep retrying for at least 1 ms */
ret = skl_pcode_request(&dev_priv->uncore,
ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
points_mask,
--
2.34.1
[Intel-gfx] [PATCH 0/4] Add MTL DP and HDMI Sequences
This series is dependent on the Meteorlake Phy enabling series which is being reviewed here [1]. The first patch of the series is a squashed patch of all the patches in [1]. The second and third patches in the series add Display port and HDMI programming sequences respectively. The last patch in the series skips programming the pcode for qgv bandwidth restrictions which is handled by PM Demand patch part of the squashed patch 1 and patch no 07/22 in [1]. [1] https://patchwork.freedesktop.org/series/109714/ Ankit Nautiyal (1): drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI Clint Taylor (1): drm/i915/mtl: Squashed Phy Support José Roberto de Souza (1): drm/i915/mtl/display: Implement DisplayPort sequences Radhakrishna Sripada (1): drm/i915/mtl: Skip pcode qgv restrictions for MTL drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/display/intel_bw.c |7 +- drivers/gpu/drm/i915/display/intel_bw.h |2 + drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2802 + drivers/gpu/drm/i915/display/intel_cx0_phy.h | 57 + .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 233 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 458 ++- .../drm/i915/display/intel_ddi_buf_trans.c| 85 +- .../drm/i915/display/intel_ddi_buf_trans.h|6 + drivers/gpu/drm/i915/display/intel_display.c | 25 +- .../drm/i915/display/intel_display_power.c|9 +- .../i915/display/intel_display_power_map.c|1 + .../i915/display/intel_display_power_well.c |2 +- .../drm/i915/display/intel_display_types.h| 23 + drivers/gpu/drm/i915/display/intel_dp.c | 23 +- drivers/gpu/drm/i915/display/intel_dpll.c | 22 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +- drivers/gpu/drm/i915/display/intel_hdmi.c |7 +- drivers/gpu/drm/i915/display/intel_hdmi.h |1 + .../drm/i915/display/intel_modeset_verify.c |2 + drivers/gpu/drm/i915/display/intel_tc.c | 177 +- drivers/gpu/drm/i915/i915_drv.h |6 + drivers/gpu/drm/i915/i915_irq.c | 276 +- drivers/gpu/drm/i915/i915_reg.h | 76 +- drivers/gpu/drm/i915/i915_reg_defs.h | 57 + drivers/gpu/drm/i915/intel_pm.c | 289 ++ drivers/gpu/drm/i915/intel_pm.h | 36 + 27 files changed, 4631 insertions(+), 54 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h -- 2.34.1
[Intel-gfx] [PATCH 5.10.y] drm/i915: Don't use stolen memory for ring buffers with LLC
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula
(cherry picked from commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index 69b2e5509d67..de67b2745258 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -108,7 +108,7 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt
*ggtt, int size)
struct i915_vma *vma;
obj = ERR_PTR(-ENODEV);
- if (i915_ggtt_has_aperture(ggtt))
+ if (i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);
--
2.39.1
[Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use stolen memory for ring buffers with LLC
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula
(cherry picked from commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index 808269b2108f..125f7bb67bee 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1268,10 +1268,11 @@ static struct i915_vma *create_ring_vma(struct
i915_ggtt *ggtt, int size)
{
struct i915_address_space *vm = &ggtt->vm;
struct drm_i915_private *i915 = vm->i915;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = NULL;
struct i915_vma *vma;
- obj = i915_gem_object_create_stolen(i915, size);
+ if (!HAS_LLC(i915))
+ obj = i915_gem_object_create_stolen(i915, size);
if (!obj)
obj = i915_gem_object_create_internal(i915, size);
if (IS_ERR(obj))
--
2.39.1
[Intel-gfx] ✓ Fi.CI.BAT: success for Add OAM support for MTL
== Series Details == Series: Add OAM support for MTL URL : https://patchwork.freedesktop.org/series/115330/ State : success == Summary == CI Bug Log - changes from CI_DRM_12878 -> Patchwork_115330v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/index.html Participating hosts (34 -> 35) -- Additional (1): fi-kbl-soraka Known issues Here are the changes found in Patchwork_115330v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gem_contexts: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][5] ([i915#7913]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +16 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-elk-e7500: NOTRUN -> [SKIP][8] ([fdo#109271]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-elk-e7500/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-n3050: NOTRUN -> [SKIP][9] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][10] ([i915#5354]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - fi-elk-e7500: [DMESG-FAIL][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-elk-e7500/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - fi-elk-e7500: [ABORT][13] -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-elk-e7500/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [ABORT][15] ([i915#7911] / [i915#7913]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][17] ([i915#8073]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12878/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115330v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 Build changes - * IGT: IGT
[Intel-gfx] [PATCH 4.19.y] drm/i915: Don't use stolen memory for ring buffers with LLC
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula
(cherry picked from commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 979d130b24c4..16eec72f0fed 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1132,10 +1132,11 @@ static struct i915_vma *
intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
{
struct i915_address_space *vm = &dev_priv->ggtt.vm;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = NULL;
struct i915_vma *vma;
- obj = i915_gem_object_create_stolen(dev_priv, size);
+ if (!HAS_LLC(dev_priv))
+ obj = i915_gem_object_create_stolen(dev_priv, size);
if (!obj)
obj = i915_gem_object_create_internal(dev_priv, size);
if (IS_ERR(obj))
--
2.39.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add OAM support for MTL
== Series Details == Series: Add OAM support for MTL URL : https://patchwork.freedesktop.org/series/115330/ State : warning == Summary == Error: dim checkpatch failed 93434691b915 drm/i915/perf: Drop wakeref on GuC RC error c40cc05504d3 drm/i915/mtl: Synchronize i915/BIOS on C6 enabling d194cc9f3edc drm/i915/perf: Validate OA sseu config outside switch b3b5fcc2d234 drm/i915/perf: Group engines into respective OA groups 5836e0c6edcc drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM 153f0bca1480 drm/i915/perf: Parse 64bit report header formats correctly cc070b2eb1bf drm/i915/perf: Handle non-power-of-2 reports 79ae4cbb7ada drm/i915/perf: Add engine class instance parameters to perf 2f9c6b4a38c6 drm/i915/perf: Add support for OA media units ec0848be5f4e drm/i915/perf: Pass i915 object to perf revision helper 08e4b2ac590f drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS -:45: CHECK:LINE_SPACING: Please don't use multiple blank lines #45: FILE: drivers/gpu/drm/i915/i915_perf.c:4233: + + total: 0 errors, 0 warnings, 1 checks, 65 lines checked
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Add OAM support for MTL
== Series Details == Series: Add OAM support for MTL URL : https://patchwork.freedesktop.org/series/115330/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add OAM support for MTL
== Series Details == Series: Add OAM support for MTL URL : https://patchwork.freedesktop.org/series/115330/ State : warning == Summary == Error: git fetch origin failed
[Intel-gfx] [PATCH 4.14.y] drm/i915: Don't use stolen memory for ring buffers with LLC
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula
(cherry picked from commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6c7563c1ab5f..f0b923e037df 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1359,10 +1359,11 @@ static struct i915_vma *
intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
{
struct i915_address_space *vm = &dev_priv->ggtt.base;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = NULL;
struct i915_vma *vma;
- obj = i915_gem_object_create_stolen(dev_priv, size);
+ if (!HAS_LLC(dev_priv))
+ obj = i915_gem_object_create_stolen(dev_priv, size);
if (!obj)
obj = i915_gem_object_create_internal(dev_priv, size);
if (IS_ERR(obj))
--
2.39.1
Re: [Intel-gfx] [PATCH] drm/i915/audio: update audio keepalive clock values
On Thu, Mar 16, 2023 at 04:46:54PM -0700, Clint Taylor wrote:
> BSPEC has updated the cdclk audio keepalives AUD_TS_CDCLK_M value to 60
> for all supported platforms and refclks.
>
> BSPEC: 54034
> BSPEC: 55409
> BSPEC: 65243
> Cc: Kai Vehmanen
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Clint Taylor
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 65151f5dcb15..3d5a9bbc6fde 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -983,11 +983,7 @@ void intel_audio_cdclk_change_pre(struct
> drm_i915_private *i915)
>
> static void get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct
> aud_ts_cdclk_m_n *aud_ts)
> {
> - if (refclk == 24000)
> - aud_ts->m = 12;
> - else
> - aud_ts->m = 15;
> -
> + aud_ts->m = 60;
> aud_ts->n = cdclk * aud_ts->m / 24000;
> }
>
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] [PATCH v7 02/11] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling
From: Vinay Belgaumkar
If BIOS enables/disables C6, i915 should do the same. Also, retain
this value across driver reloads. This is needed only for MTL as
of now due to an existing bug in OA which needs C6 disabled for
it to function. BIOS behavior is also different across platforms
in terms of how C6 is enabled.
Signed-off-by: Vinay Belgaumkar
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 26 ---
drivers/gpu/drm/i915/gt/intel_rc6.h | 2 ++
drivers/gpu/drm/i915/gt/intel_rc6_types.h | 2 ++
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index f4150f61f39c..f760586f9f46 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -420,6 +420,21 @@ static void vlv_rc6_enable(struct intel_rc6 *rc6)
GEN7_RC_CTL_TO_MODE | VLV_RC_CTL_CTX_RST_PARALLEL;
}
+bool intel_check_bios_c6_setup(struct intel_rc6 *rc6)
+{
+ if (!rc6->bios_state_captured) {
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ rc6->bios_rc_state = intel_uncore_read(uncore,
GEN6_RC_STATE);
+
+ rc6->bios_state_captured = true;
+ }
+
+ return rc6->bios_rc_state & RC_SW_TARGET_STATE_MASK;
+}
+
static bool bxt_check_bios_rc6_setup(struct intel_rc6 *rc6)
{
struct intel_uncore *uncore = rc6_to_uncore(rc6);
@@ -503,10 +518,10 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
- if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
- gt->type == GT_MEDIA) {
+ if (IS_METEORLAKE(gt->i915) &&
+ !intel_check_bios_c6_setup(rc6)) {
drm_notice(&i915->drm,
- "Media RC6 disabled on A step\n");
+ "C6 disabled by BIOS\n");
return false;
}
@@ -707,9 +722,14 @@ void intel_rc6_disable(struct intel_rc6 *rc6)
void intel_rc6_fini(struct intel_rc6 *rc6)
{
struct drm_i915_gem_object *pctx;
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
intel_rc6_disable(rc6);
+ /* We want the BIOS C6 state preserved across loads for MTL */
+ if (IS_METEORLAKE(rc6_to_i915(rc6)) && rc6->bios_state_captured)
+ set(uncore, GEN6_RC_STATE, rc6->bios_rc_state);
+
pctx = fetch_and_zero(&rc6->pctx);
if (pctx)
i915_gem_object_put(pctx);
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h
b/drivers/gpu/drm/i915/gt/intel_rc6.h
index 456fa668a276..e137c2c397c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.h
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
@@ -27,4 +27,6 @@ u64 intel_rc6_residency_us(struct intel_rc6 *rc6, enum
intel_rc6_res_type id);
void intel_rc6_print_residency(struct seq_file *m, const char *title,
enum intel_rc6_res_type id);
+bool intel_check_bios_c6_setup(struct intel_rc6 *rc6);
+
#endif /* INTEL_RC6_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
index fa23c4dce00b..cd4587098162 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
@@ -29,6 +29,7 @@ struct intel_rc6 {
u64 cur_residency[INTEL_RC6_RES_MAX];
u32 ctl_enable;
+ u32 bios_rc_state;
struct drm_i915_gem_object *pctx;
@@ -36,6 +37,7 @@ struct intel_rc6 {
bool enabled : 1;
bool manual : 1;
bool wakeref : 1;
+ bool bios_state_captured : 1;
};
#endif /* INTEL_RC6_TYPES_H */
--
2.36.1
[Intel-gfx] [PATCH v7 07/11] drm/i915/perf: Handle non-power-of-2 reports
Some of the newer OA formats are not powers of 2. For those formats,
adjust the hw_tail accordingly when checking for new reports.
v2: (Ashutosh)
- Switch to OA_TAKEN for diff calculation
- Use OA_BUFFER_SIZE instead of the vma size
- Update comments
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 51 +---
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d1f7266bec6d..8c4bcdce8019 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -534,6 +534,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
bool pollin;
u32 hw_tail;
u64 now;
+ u32 partial_report_size;
/* We have to consider the (unlikely) possibility that read() errors
* could result in an OA buffer reset which might reset the head and
@@ -543,10 +544,15 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
- /* The tail pointer increases in 64 byte increments,
-* not in report_size steps...
+ /* The tail pointer increases in 64 byte increments, not in report_size
+* steps. Also the report size may not be a power of 2. Compute
+* potentially partially landed report in the OA buffer
*/
- hw_tail &= ~(report_size - 1);
+ partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
+ partial_report_size %= report_size;
+
+ /* Subtract partial amount off the tail */
+ hw_tail = gtt_offset + OA_TAKEN(hw_tail, partial_report_size);
now = ktime_get_mono_fast_ns();
@@ -669,6 +675,8 @@ static int append_oa_sample(struct i915_perf_stream *stream,
{
int report_size = stream->oa_buffer.format->size;
struct drm_i915_perf_record_header header;
+ int report_size_partial;
+ u8 *oa_buf_end;
header.type = DRM_I915_PERF_RECORD_SAMPLE;
header.pad = 0;
@@ -682,8 +690,20 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return -EFAULT;
buf += sizeof(header);
- if (copy_to_user(buf, report, report_size))
+ oa_buf_end = stream->oa_buffer.vaddr + OA_BUFFER_SIZE;
+ report_size_partial = oa_buf_end - report;
+
+ if (report_size_partial < report_size) {
+ if (copy_to_user(buf, report, report_size_partial))
+ return -EFAULT;
+ buf += report_size_partial;
+
+ if (copy_to_user(buf, stream->oa_buffer.vaddr,
+report_size - report_size_partial))
+ return -EFAULT;
+ } else if (copy_to_user(buf, report, report_size)) {
return -EFAULT;
+ }
(*offset) += header.size;
@@ -747,12 +767,11 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* An out of bounds or misaligned head or tail pointer implies a driver
* bug since we validate + align the tail pointers we read from the
* hardware and we are in full control of the head pointer which should
-* only be incremented by multiples of the report size (notably also
-* all a power of two).
+* only be incremented by multiples of the report size.
*/
if (drm_WARN_ONCE(&uncore->i915->drm,
- head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+ head > OA_BUFFER_SIZE ||
+ tail > OA_BUFFER_SIZE,
"Inconsistent OA buffer pointers: head = %u, tail =
%u\n",
head, tail))
return -EIO;
@@ -766,22 +785,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
u32 ctx_id;
u64 reason;
- /*
-* All the report sizes factor neatly into the buffer
-* size so we never expect to see a report split
-* between the beginning and end of the buffer.
-*
-* Given the initial alignment check a misalignment
-* here would imply a driver bug that would result
-* in an overrun.
-*/
- if (drm_WARN_ON(&uncore->i915->drm,
- (OA_BUFFER_SIZE - head) < report_size)) {
- drm_err(&uncore->i915->drm,
- "Spurious OA head ptr: non-integral report
offset\n");
- break;
- }
-
/*
* The reason field includes flags identifying what
* triggered this specific report (mostly timer
--
2.36.1
[Intel-gfx] [PATCH v7 08/11] drm/i915/perf: Add engine class instance parameters to perf
One or more engines map to a specific OA unit. All reports from these
engines are captured in the OA buffer managed by this OA unit.
Current i915 OA implementation supports only the OAG unit. OAG primarily
caters to render engine, so i915 OA uses render as the default engine
in the OA implementation. Since there are more OA units on newer
hardware that map to other engines, allow user to pass engine class and
instance to select and program specific OA units.
UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
https://patchwork.freedesktop.org/patch/522822/?series=114023
https://patchwork.freedesktop.org/patch/522826/?series=114023
https://patchwork.freedesktop.org/patch/522828/?series=114023
https://patchwork.freedesktop.org/patch/522816/?series=114023
https://patchwork.freedesktop.org/patch/522825/?series=114023
v2: (Ashutosh)
- Clarify commit message
- Add drm_dbg
- Clarify uapi description
v3: (Ashutosh)
- Remove irrelevant info from the uapi comment
v4: Ensure engine class:instance is passed together (Ashutosh)
v5: Remove unnecessary quote (Ashutosh)
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 71
include/uapi/drm/i915_drm.h | 19 +
2 files changed, 63 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8c4bcdce8019..081d1dd743e0 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4012,48 +4012,32 @@ static int read_properties_unlocked(struct i915_perf
*perf,
{
struct drm_i915_gem_context_param_sseu user_sseu;
u64 __user *uprop = uprops;
+ bool config_instance = false;
+ bool config_class = false;
bool config_sseu = false;
+ u8 class, instance;
u32 i;
int ret;
memset(props, 0, sizeof(struct perf_open_properties));
props->poll_oa_period = DEFAULT_POLL_PERIOD_NS;
- if (!n_props) {
- drm_dbg(&perf->i915->drm,
- "No i915 perf properties given\n");
- return -EINVAL;
- }
-
- /* At the moment we only support using i915-perf on the RCS. */
- props->engine = intel_engine_lookup_user(perf->i915,
-I915_ENGINE_CLASS_RENDER,
-0);
- if (!props->engine) {
- drm_dbg(&perf->i915->drm,
- "No RENDER-capable engines\n");
- return -EINVAL;
- }
-
- if (!engine_supports_oa(props->engine)) {
- drm_dbg(&perf->i915->drm,
- "Engine not supported by OA %d:%d\n",
- I915_ENGINE_CLASS_RENDER, 0);
- return -EINVAL;
- }
-
/* Considering that ID = 0 is reserved and assuming that we don't
* (currently) expect any configurations to ever specify duplicate
* values for a particular property ID then the last _PROP_MAX value is
* one greater than the maximum number of properties we expect to get
* from userspace.
*/
- if (n_props >= DRM_I915_PERF_PROP_MAX) {
+ if (!n_props || n_props >= DRM_I915_PERF_PROP_MAX) {
drm_dbg(&perf->i915->drm,
- "More i915 perf properties specified than exist\n");
+ "Invalid number of i915 perf properties given\n");
return -EINVAL;
}
+ /* Defaults when class:instance is not passed */
+ class = I915_ENGINE_CLASS_RENDER;
+ instance = 0;
+
for (i = 0; i < n_props; i++) {
u64 oa_period, oa_freq_hz;
u64 id, value;
@@ -4174,7 +4158,15 @@ static int read_properties_unlocked(struct i915_perf
*perf,
}
props->poll_oa_period = value;
break;
- case DRM_I915_PERF_PROP_MAX:
+ case DRM_I915_PERF_PROP_OA_ENGINE_CLASS:
+ class = (u8)value;
+ config_class = true;
+ break;
+ case DRM_I915_PERF_PROP_OA_ENGINE_INSTANCE:
+ instance = (u8)value;
+ config_instance = true;
+ break;
+ default:
MISSING_CASE(id);
return -EINVAL;
}
@@ -4182,6 +4174,28 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ if ((config_class && !config_instance) ||
+ (config_instance && !config_class)) {
+ drm_dbg(&perf->i915->drm,
+ "OA engine-class and engine-instance parameters must be
passed together\n");
+ return -EINVAL;
+ }
+
+ props->engine = intel_
[Intel-gfx] [PATCH v7 06/11] drm/i915/perf: Parse 64bit report header formats correctly
Now that OA formats come in flavor of 64 bit reports, the report header
has 64 bit report-id, timestamp, context-id and gpu-ticks fields. When
filtering these reports, use the right width for these fields.
Note that upper dword of context id is reserved, so squash lower dword
only.
v2: (Ashutosh)
- Drop inline
- Update comment with dword definitions - report id and timestamp
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 109 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
2 files changed, 90 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 584e3e7b9e77..d1f7266bec6d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -441,6 +441,67 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream
*stream)
return oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
}
+#define oa_report_header_64bit(__s) \
+ ((__s)->oa_buffer.format->header == HDR_64_BIT)
+
+static u64 oa_report_id(struct i915_perf_stream *stream, void *report)
+{
+ return oa_report_header_64bit(stream) ? *(u64 *)report : *(u32 *)report;
+}
+
+static u64 oa_report_reason(struct i915_perf_stream *stream, void *report)
+{
+ return (oa_report_id(stream, report) >> OAREPORT_REASON_SHIFT) &
+ (GRAPHICS_VER(stream->perf->i915) == 12 ?
+ OAREPORT_REASON_MASK_EXTENDED :
+ OAREPORT_REASON_MASK);
+}
+
+static void oa_report_id_clear(struct i915_perf_stream *stream, u32 *report)
+{
+ if (oa_report_header_64bit(stream))
+ *(u64 *)report = 0;
+ else
+ *report = 0;
+}
+
+static bool oa_report_ctx_invalid(struct i915_perf_stream *stream, void
*report)
+{
+ return !(oa_report_id(stream, report) &
+ stream->perf->gen8_valid_ctx_bit) &&
+ GRAPHICS_VER(stream->perf->i915) <= 11;
+}
+
+static u64 oa_timestamp(struct i915_perf_stream *stream, void *report)
+{
+ return oa_report_header_64bit(stream) ?
+ *((u64 *)report + 1) :
+ *((u32 *)report + 1);
+}
+
+static void oa_timestamp_clear(struct i915_perf_stream *stream, u32 *report)
+{
+ if (oa_report_header_64bit(stream))
+ *(u64 *)&report[2] = 0;
+ else
+ report[1] = 0;
+}
+
+static u32 oa_context_id(struct i915_perf_stream *stream, u32 *report)
+{
+ u32 ctx_id = oa_report_header_64bit(stream) ? report[4] : report[2];
+
+ return ctx_id & stream->specific_ctx_id_mask;
+}
+
+static void oa_context_id_squash(struct i915_perf_stream *stream, u32 *report)
+{
+ if (oa_report_header_64bit(stream))
+ report[4] = INVALID_CTX_ID;
+ else
+ report[2] = INVALID_CTX_ID;
+}
+
/**
* oa_buffer_check_unlocked - check for data and update tail ptr state
* @stream: i915 stream instance
@@ -509,21 +570,22 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail -= gtt_offset;
tail = hw_tail;
- /* Walk the stream backward until we find a report with dword 0
-* & 1 not at 0. Since the circular buffer pointers progress by
-* increments of 64 bytes and that reports can be up to 256
-* bytes long, we can't tell whether a report has fully landed
-* in memory before the first 2 dwords of the following report
-* have effectively landed.
+ /* Walk the stream backward until we find a report with report
+* id and timestmap not at 0. Since the circular buffer pointers
+* progress by increments of 64 bytes and that reports can be up
+* to 256 bytes long, we can't tell whether a report has fully
+* landed in memory before the report id and timestamp of the
+* following report have effectively landed.
*
* This is assuming that the writes of the OA unit land in
* memory in the order they were written to.
* If not : (╯°□°）╯︵ ┻━┻
*/
while (OA_TAKEN(tail, aged_tail) >= report_size) {
- u32 *report32 = (void *)(stream->oa_buffer.vaddr +
tail);
+ void *report = stream->oa_buffer.vaddr + tail;
- if (report32[0] != 0 || report32[1] != 0)
+ if (oa_report_id(stream, report) ||
+ oa_timestamp(stream, report))
break;
tail = (tail - report_size) & (OA_BUFFER_SIZE - 1);
@@ -702,7 +764,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
u8 *report = oa_buf_base + head;
u32 *report32 = (void *)report;
u32 ctx_id;
- u32 reas
[Intel-gfx] [PATCH v7 10/11] drm/i915/perf: Pass i915 object to perf revision helper
In some cases, perf revision may rely on specific steppings of a
platform. To determine the platform, pass i915 object to the perf
revision helper.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_perf.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 61ef2d9cfa62..2238e096c957 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -173,7 +173,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = INTEL_INFO(i915)->has_coherent_ggtt;
break;
case I915_PARAM_PERF_REVISION:
- value = i915_perf_ioctl_version();
+ value = i915_perf_ioctl_version(i915);
break;
case I915_PARAM_OA_TIMESTAMP_FREQUENCY:
value = i915_perf_oa_timestamp_frequency(i915);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 247dad57ab89..18afa76653b7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -5289,7 +5289,7 @@ void i915_perf_fini(struct drm_i915_private *i915)
*
* This version number is used by userspace to detect available features.
*/
-int i915_perf_ioctl_version(void)
+int i915_perf_ioctl_version(struct drm_i915_private *i915)
{
/*
* 1: Initial version
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index 253637651d5e..accf626f2b13 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -22,7 +22,7 @@ int i915_perf_init(struct drm_i915_private *i915);
void i915_perf_fini(struct drm_i915_private *i915);
void i915_perf_register(struct drm_i915_private *i915);
void i915_perf_unregister(struct drm_i915_private *i915);
-int i915_perf_ioctl_version(void);
+int i915_perf_ioctl_version(struct drm_i915_private *i915);
int i915_perf_sysctl_register(void);
void i915_perf_sysctl_unregister(void);
--
2.36.1
[Intel-gfx] [PATCH v7 09/11] drm/i915/perf: Add support for OA media units
MTL introduces additional OA units dedicated to media use cases. Add
support for programming these OA units by passing the media engine class
and instance parameters.
UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
https://patchwork.freedesktop.org/patch/522822/?series=114023
https://patchwork.freedesktop.org/patch/522826/?series=114023
https://patchwork.freedesktop.org/patch/522828/?series=114023
https://patchwork.freedesktop.org/patch/522816/?series=114023
https://patchwork.freedesktop.org/patch/522825/?series=114023
v2: (Ashutosh)
- check for IP_VER(12, 70) instead of MTL
- remove PERF_GROUP_OAG comment in mtl_oa_base
- remove oa_buffer.group
- use engine->oa_group->type in engine_supports_oa_format
- remove fw_domains and use FORCEWAKE_ALL
- remove MPES/MPEC comment
- s/xehp/mtl/ in b counter validation function name
- remove engine_supports_oa in __oa_engine_group
- remove warn_ON from __oam_engine_group
- refactor oa_init_groups and oa_init_regs
- assign g->type correctly
- use enum oa_type definition
v3: (Ashutosh)
- Drop oa_unit_functional as engine_supports_oa is enough
v4:
- s/DRM_DEBUG/drm_dbg/
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 184 ---
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 78 ++
drivers/gpu/drm/i915/i915_perf_types.h | 30
drivers/gpu/drm/i915/intel_device_info.h | 1 +
include/uapi/drm/i915_drm.h | 4 +
7 files changed, 278 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6254aa977398..d81c35407d25 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -858,6 +858,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(INTEL_INFO(dev_priv)->has_oa_bpc_reporting)
#define HAS_OA_SLICE_CONTRIB_LIMITS(dev_priv) \
(INTEL_INFO(dev_priv)->has_oa_slice_contrib_limits)
+#define HAS_OAM(dev_priv) \
+ (INTEL_INFO(dev_priv)->has_oam)
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a8d942b16223..621730b6551c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info adl_p_info = {
.has_mslice_steering = 1, \
.has_oa_bpc_reporting = 1, \
.has_oa_slice_contrib_limits = 1, \
+ .has_oam = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
.has_rps = 1, \
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 081d1dd743e0..247dad57ab89 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
*/
#include
+#include
#include
#include
@@ -326,6 +327,12 @@ static const struct i915_oa_format
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
[I915_OAR_FORMAT_A32u40_A4u32_B8_C8]= { 5, 256 },
[I915_OA_FORMAT_A24u40_A14u32_B8_C8]= { 5, 256 },
+ [I915_OAM_FORMAT_MPEC8u64_B8_C8]= { 1, 192, TYPE_OAM,
HDR_64_BIT },
+ [I915_OAM_FORMAT_MPEC8u32_B8_C8]= { 2, 128, TYPE_OAM,
HDR_64_BIT },
+};
+
+static const u32 mtl_oa_base[] = {
+ [PERF_GROUP_OAM_SAMEDIA_0] = 0x393000,
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -418,11 +425,17 @@ static void free_oa_config_bo(struct i915_oa_config_bo
*oa_bo)
kfree(oa_bo);
}
+static inline const
+struct i915_perf_regs *__oa_regs(struct i915_perf_stream *stream)
+{
+ return &stream->engine->oa_group->regs;
+}
+
static u32 gen12_oa_hw_tail_read(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
- return intel_uncore_read(uncore, GEN12_OAG_OATAILPTR) &
+ return intel_uncore_read(uncore, __oa_regs(stream)->oa_tail_ptr) &
GEN12_OAG_OATAILPTR_MASK;
}
@@ -875,7 +888,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
i915_reg_t oaheadptr;
oaheadptr = GRAPHICS_VER(stream->perf->i915) == 12 ?
- GEN12_OAG_OAHEADPTR : GEN8_OAHEADPTR;
+ __oa_regs(stream)->oa_head_ptr :
+ GEN8_OAHEADPTR;
spin_lock_irqsave(&stream->oa_buffer.ptr_lock, flags);
@@ -928,7 +942,8 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
return -EIO;
oastatus_reg = GRAPHICS_VER(stream->perf->i915) == 12 ?
- GEN12_OAG_OASTATUS : GEN8_OASTATUS;
+ __oa_regs(stream)->oa_status :
+ GEN8_OASTATUS;
oastatus = intel_uncore_read(uncore, oastatus_reg);
@@ -1637,6 +1652,1
[Intel-gfx] [PATCH v7 05/11] drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM
i915_perf_init can fail due to OOM. Fail driver init if i915_perf_init
fails.
v2: (Jani)
- Reorder patch in the series
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_driver.c | 4 +++-
drivers/gpu/drm/i915/i915_perf.c | 8 ++--
drivers/gpu/drm/i915/i915_perf.h | 2 +-
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index da249337c23b..8dde3512d2d1 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -469,7 +469,9 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
if (ret)
return ret;
- i915_perf_init(dev_priv);
+ ret = i915_perf_init(dev_priv);
+ if (ret)
+ return ret;
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index cf4ea5e389a5..584e3e7b9e77 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4902,7 +4902,7 @@ static void i915_perf_init_info(struct drm_i915_private
*i915)
* Note: i915-perf initialization is split into an 'init' and 'register'
* phase with the i915_perf_register() exposing state to userspace.
*/
-void i915_perf_init(struct drm_i915_private *i915)
+int i915_perf_init(struct drm_i915_private *i915)
{
struct i915_perf *perf = &i915->perf;
@@ -5018,12 +5018,16 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->i915 = i915;
ret = oa_init_engine_groups(perf);
- if (ret)
+ if (ret) {
drm_err(&i915->drm,
"OA initialization failed %d\n", ret);
+ return ret;
+ }
oa_init_supported_formats(perf);
}
+
+ return 0;
}
static int destroy_config(int id, void *p, void *data)
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index f96e09a4af04..253637651d5e 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -18,7 +18,7 @@ struct i915_oa_config;
struct intel_context;
struct intel_engine_cs;
-void i915_perf_init(struct drm_i915_private *i915);
+int i915_perf_init(struct drm_i915_private *i915);
void i915_perf_fini(struct drm_i915_private *i915);
void i915_perf_register(struct drm_i915_private *i915);
void i915_perf_unregister(struct drm_i915_private *i915);
--
2.36.1
[Intel-gfx] [PATCH v7 04/11] drm/i915/perf: Group engines into respective OA groups
Now that we may have multiple OA units in a single GT as well as on
separate GTs, create an engine group that maps to a single OA unit.
v2: (Jani)
- Drop warning on ENOMEM
- Reorder patch in the series
v3: (Ashutosh)
- Remove unused members from perf structs
- Update comments
- Update engine_supports_oa check
- Just return 1 in num_perf_groups_per_gt for now
- Set engine->oa_group to NULL to begin with
v4: Use engine_supports_oa() check in oa_init_reg_state (Ashutosh)
v5: Rebase after dropping engine_supports_oa helper
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +++
drivers/gpu/drm/i915/gt/intel_sseu.c | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 93 ++--
drivers/gpu/drm/i915/i915_perf_types.h | 33 ++-
4 files changed, 127 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 0a071e5da1a8..960291f88fd6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -53,6 +53,8 @@ struct intel_gt;
struct intel_ring;
struct intel_uncore;
struct intel_breadcrumbs;
+struct intel_engine_cs;
+struct i915_perf_group;
typedef u32 intel_engine_mask_t;
#define ALL_ENGINES ((intel_engine_mask_t)~0ul)
@@ -617,6 +619,14 @@ struct intel_engine_cs {
} props, defaults;
I915_SELFTEST_DECLARE(struct fault_attr reset_timeout);
+
+ /*
+* The perf group maps to one OA unit which controls one OA buffer. All
+* reports corresponding to this engine will be reported to this OA
+* buffer. An engine will map to a single OA unit, but a single OA unit
+* can generate reports for multiple engines.
+*/
+ struct i915_perf_group *oa_group;
};
static inline bool
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 6c6198a257ac..1141f875f5bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -6,6 +6,7 @@
#include
#include "i915_drv.h"
+#include "i915_perf_types.h"
#include "intel_engine_regs.h"
#include "intel_gt_regs.h"
#include "intel_sseu.h"
@@ -677,7 +678,7 @@ u32 intel_sseu_make_rpcs(struct intel_gt *gt,
* If i915/perf is active, we want a stable powergating configuration
* on the system. Use the configuration pinned by i915/perf.
*/
- if (gt->perf.exclusive_stream)
+ if (gt->perf.group && gt->perf.group[PERF_GROUP_OAG].exclusive_stream)
req_sseu = >->perf.sseu;
slices = hweight8(req_sseu->slice_mask);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ebd76b5c9712..cf4ea5e389a5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1570,12 +1570,18 @@ free_noa_wait(struct i915_perf_stream *stream)
i915_vma_unpin_and_release(&stream->noa_wait, 0);
}
+static bool engine_supports_oa(const struct intel_engine_cs *engine)
+{
+ return engine->oa_group;
+}
+
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct i915_perf *perf = stream->perf;
struct intel_gt *gt = stream->engine->gt;
+ struct i915_perf_group *g = stream->engine->oa_group;
- if (WARN_ON(stream != gt->perf.exclusive_stream))
+ if (WARN_ON(stream != g->exclusive_stream))
return;
/*
@@ -1584,7 +1590,7 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
*
* See i915_oa_init_reg_state() and lrc_configure_all_contexts()
*/
- WRITE_ONCE(gt->perf.exclusive_stream, NULL);
+ WRITE_ONCE(g->exclusive_stream, NULL);
perf->ops.disable_metric_set(stream);
free_oa_buffer(stream);
@@ -3182,6 +3188,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
+ struct i915_perf_group *g;
struct intel_gt *gt;
int ret;
@@ -3191,6 +3198,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
return -EINVAL;
}
gt = props->engine->gt;
+ g = props->engine->oa_group;
/*
* If the sysfs metrics/ directory wasn't registered for some
@@ -3221,7 +3229,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
* counter reports and marshal to the appropriate client
* we currently only allow exclusive access
*/
- if (gt->perf.exclusive_stream) {
+ if (g->exclusive_stream) {
drm_dbg(&stream->perf->i915->drm,
"OA unit already in use\n");
return -EBUSY;
@@ -3316,7 +3324,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
strea
[Intel-gfx] [PATCH v7 01/11] drm/i915/perf: Drop wakeref on GuC RC error
From: Chris Wilson
If we fail to adjust the GuC run-control on opening the perf stream,
make sure we unwind the wakeref just taken.
v2: Retain old goto label names (Ashutosh)
Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled")
Signed-off-by: Chris Wilson
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 14 +-
drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 824a34ec0b83..283a4a3c6862 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,9 +1592,7 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
/*
* Wa_16011777198:dg2: Unset the override of GUCRC mode to enable rc6.
*/
- if (intel_uc_uses_guc_rc(>->uc) &&
- (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
-IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)))
+ if (stream->override_gucrc)
drm_WARN_ON(>->i915->drm,
intel_guc_slpc_unset_gucrc_mode(>->uc.guc.slpc));
@@ -3305,8 +3303,10 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
if (ret) {
drm_dbg(&stream->perf->i915->drm,
"Unable to override gucrc mode\n");
- goto err_config;
+ goto err_gucrc;
}
+
+ stream->override_gucrc = true;
}
ret = alloc_oa_buffer(stream);
@@ -3345,11 +3345,15 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
free_oa_buffer(stream);
err_oa_buf_alloc:
- free_oa_configs(stream);
+ if (stream->override_gucrc)
+ intel_guc_slpc_unset_gucrc_mode(>->uc.guc.slpc);
+err_gucrc:
intel_uncore_forcewake_put(stream->uncore, FORCEWAKE_ALL);
intel_engine_pm_put(stream->engine);
+ free_oa_configs(stream);
+
err_config:
free_noa_wait(stream);
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h
b/drivers/gpu/drm/i915/i915_perf_types.h
index ca150b7af3f2..e36f046fe2b6 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -316,6 +316,12 @@ struct i915_perf_stream {
* buffer should be checked for available data.
*/
u64 poll_oa_period;
+
+ /**
+* @override_gucrc: GuC RC has been overridden for the perf stream,
+* and we need to restore the default configuration on release.
+*/
+ bool override_gucrc:1;
};
/**
--
2.36.1
[Intel-gfx] [PATCH v7 00/11] Add OAM support for MTL
The OAM unit captures OA reports specific to the media engines. Add support to program the OAM unit on media tile on MTL. The OAM unit is selected by passing the class:instance of a media engine to perf parameters. Corresponding UMD changes are posted to the igt-dev repo as part of supporting the GPUvis tool. v2: Incorporate review feedback (Jani, Ashutosh) v3: Incorporate review feedback (Jani, Ashutosh) v4: Incorporate review feedback (Ashutosh) v5: - Enforce paired engine-class and engine-instance configuration - Include fix for Wa_14017512683 v6: Rebase to fix build failure v7: Incorporate review comments Signed-off-by: Umesh Nerlige Ramappa Test-with: 20230316233323.2638668-1-umesh.nerlige.rama...@intel.com Chris Wilson (1): drm/i915/perf: Drop wakeref on GuC RC error Umesh Nerlige Ramappa (9): drm/i915/perf: Validate OA sseu config outside switch drm/i915/perf: Group engines into respective OA groups drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM drm/i915/perf: Parse 64bit report header formats correctly drm/i915/perf: Handle non-power-of-2 reports drm/i915/perf: Add engine class instance parameters to perf drm/i915/perf: Add support for OA media units drm/i915/perf: Pass i915 object to perf revision helper drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS Vinay Belgaumkar (1): drm/i915/mtl: Synchronize i915/BIOS on C6 enabling drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 + drivers/gpu/drm/i915/gt/intel_rc6.c | 26 +- drivers/gpu/drm/i915/gt/intel_rc6.h | 2 + drivers/gpu/drm/i915/gt/intel_rc6_types.h| 2 + drivers/gpu/drm/i915/gt/intel_sseu.c | 3 +- drivers/gpu/drm/i915/i915_driver.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_getparam.c | 2 +- drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 574 +++ drivers/gpu/drm/i915/i915_perf.h | 4 +- drivers/gpu/drm/i915/i915_perf_oa_regs.h | 78 +++ drivers/gpu/drm/i915/i915_perf_types.h | 75 ++- drivers/gpu/drm/i915/intel_device_info.h | 1 + include/uapi/drm/i915_drm.h | 23 + 15 files changed, 683 insertions(+), 124 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH v7 11/11] drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS
OAM does not work with media C6 enabled on some steppings of MTL.
Disable OAM if we detect that media C6 was enabled in bios.
v2: (Ashutosh)
- Remove drm_notice from the driver load path
- Log a drm_err when opening an OAM stream on affected steppings
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 41
1 file changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 18afa76653b7..823379d63caf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -209,6 +209,7 @@
#include "gt/intel_gt_regs.h"
#include "gt/intel_lrc.h"
#include "gt/intel_lrc_reg.h"
+#include "gt/intel_rc6.h"
#include "gt/intel_ring.h"
#include "gt/uc/intel_guc_slpc.h"
@@ -4216,6 +4217,20 @@ static int read_properties_unlocked(struct i915_perf
*perf,
return -EINVAL;
}
+ /*
+* Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
+* C6 disable in BIOS. Fail if Media C6 is enabled on steppings where
OAM
+* does not work as expected.
+*/
+ if (IS_MTL_MEDIA_STEP(props->engine->i915, STEP_A0, STEP_C0) &&
+ props->engine->gt->type == GT_MEDIA &&
+ intel_check_bios_c6_setup(&props->engine->gt->rc6)) {
+ drm_dbg(&perf->i915->drm,
+ "OAM requires media C6 to be disabled in BIOS\n");
+ return -EINVAL;
+ }
+
+
if (!engine_supports_oa(props->engine)) {
drm_dbg(&perf->i915->drm,
"Engine not supported by OA %d:%d\n",
@@ -4897,6 +4912,15 @@ static u32 num_perf_groups_per_gt(struct intel_gt *gt)
static u32 __oam_engine_group(struct intel_engine_cs *engine)
{
+ /*
+* Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
+* C6 disable in BIOS. To disable use of OAM with media engines, set the
+* oa_group to PERF_GROUP_INVALID.
+*/
+ if (IS_MTL_MEDIA_STEP(engine->i915, STEP_A0, STEP_C0) &&
+ intel_check_bios_c6_setup(&engine->gt->rc6))
+ return PERF_GROUP_INVALID;
+
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70)) {
/*
* There's 1 SAMEDIA gt and 1 OAM per SAMEDIA gt. All media
slices
@@ -5316,6 +5340,23 @@ int i915_perf_ioctl_version(struct drm_i915_private
*i915)
*
* 7: Add support for video decode and enhancement classes.
*/
+
+ /*
+* Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
+* C6 disable in BIOS. If Media C6 is enabled in BIOS, return version 6
+* to indicate that OA media is not supported.
+*/
+ if (IS_MTL_MEDIA_STEP(i915, STEP_A0, STEP_C0)) {
+ struct intel_gt *gt;
+ int i;
+
+ for_each_gt(gt, i915, i) {
+ if (gt->type == GT_MEDIA &&
+ intel_check_bios_c6_setup(>->rc6))
+ return 6;
+ }
+ }
+
return 7;
}
--
2.36.1
[Intel-gfx] [PATCH v7 03/11] drm/i915/perf: Validate OA sseu config outside switch
Once OA supports media engine class:instance, the engine can only be
validated outside the switch since class and instance parameters are
separate entities. Since OA sseu config depends on engine
class:instance, validate OA sseu config outside the switch.
v2: (Ashutosh)
- Clarify commit message
- Use drm_dbg instead of DRM_DEBUG
- Reorder stack variables
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 283a4a3c6862..ebd76b5c9712 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3940,7 +3940,9 @@ static int read_properties_unlocked(struct i915_perf
*perf,
u32 n_props,
struct perf_open_properties *props)
{
+ struct drm_i915_gem_context_param_sseu user_sseu;
u64 __user *uprop = uprops;
+ bool config_sseu = false;
u32 i;
int ret;
@@ -4069,8 +4071,6 @@ static int read_properties_unlocked(struct i915_perf
*perf,
props->hold_preemption = !!value;
break;
case DRM_I915_PERF_PROP_GLOBAL_SSEU: {
- struct drm_i915_gem_context_param_sseu user_sseu;
-
if (GRAPHICS_VER_FULL(perf->i915) >= IP_VER(12, 50)) {
drm_dbg(&perf->i915->drm,
"SSEU config not supported on gfx %x\n",
@@ -4085,14 +4085,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
"Unable to copy global sseu
parameter\n");
return -EFAULT;
}
-
- ret = get_sseu_config(&props->sseu, props->engine,
&user_sseu);
- if (ret) {
- drm_dbg(&perf->i915->drm,
- "Invalid SSEU configuration\n");
- return ret;
- }
- props->has_sseu = true;
+ config_sseu = true;
break;
}
case DRM_I915_PERF_PROP_POLL_OA_PERIOD:
@@ -4112,6 +4105,16 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ if (config_sseu) {
+ ret = get_sseu_config(&props->sseu, props->engine, &user_sseu);
+ if (ret) {
+ drm_dbg(&perf->i915->drm,
+ "Invalid SSEU configuration\n");
+ return ret;
+ }
+ props->has_sseu = true;
+ }
+
return 0;
}
--
2.36.1
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Allow for very slow GuC loading
On Thu, 16 Mar 2023 15:06:32 -0700, john.c.harri...@intel.com wrote: > > From: John Harrison > > A failure to load the GuC is occasionally observed where the GuC log > actually showed that the GuC had loaded just fine. The implication > being that the load just took ever so slightly longer than the 200ms > timeout. Given that the actual time should be tens of milliseconds at > the slowest, this should never happen. So far the issue has generally > been caused by a bad IFWI resulting in low frequencies during boot > (depsite the KMD requesting max frequency). However, the issue seems > to happen more often than one would like. > > So a) increase the timeout so that the user still gets a working > system even in the case of slow load. And b) report the frequency > during the load to see if that is the case of the slow down. > > v2: Reduce timeout in non-debug builds, add references (Daniele) > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/7931 > References: https://gitlab.freedesktop.org/drm/intel/-/issues/8060 > References: https://gitlab.freedesktop.org/drm/intel/-/issues/8083 > References: https://gitlab.freedesktop.org/drm/intel/-/issues/8136 > References: https://gitlab.freedesktop.org/drm/intel/-/issues/8137 > Signed-off-by: John Harrison Tested this on ATSM and saw the interrmittent GuC FW load timeouts disappear: Tested-by: Ashutosh Dixit
[Intel-gfx] Reminder: Only 2 days left to nominate candidates for the 2023 X.Org Board of Directors Elections
Further reminder that the nomination period for the X.Org Board of Director elections finishes in only 2 days, on March 19th. Please send your nominations or self-nominations as soon as possible following the instructions below. Thanks again for your attention. On Mon, 2023-03-13 at 16:27 +0100, Ricardo Garcia wrote: > This is a reminder that the nomination period for the X.Org Board of > Director elections finishes in a week, on March 19th. > > If you would like to nominate yourself please send email to the election > committee electi...@x.org, giving your > > name > current professional affiliation > a statement of contribution to X.Org or related technologies > a personal statement. > > To vote or to be elected to the Board you needed to be a Member of the > X.Org Foundation. To be a Member of the X.Org Foundation you need to > apply or renew your membership until the end of the nomination period. > > Original email follows below. Thanks for your attention. > > On Wed, 2023-02-15 at 21:53 +0100, Ricardo Garcia wrote: > > We are seeking nominations for candidates for election to the X.Org > > Foundation Board of Directors. All X.Org Foundation members are eligible > > for election to the board. > > > > Nominations for the 2023 election are now open and will remain open > > until 23:59 UTC on 19 March 2023. > > > > The Board consists of directors elected from the membership. Each year, > > an election is held to bring the total number of directors to eight. The > > four members receiving the highest vote totals will serve as directors > > for two year terms. > > > > The directors who received two year terms starting in 2022 were Emma > > Anholt, Mark Filion, Alyssa Rosenzweig and Ricardo Garcia. They will > > continue to serve until their term ends in 2024. Current directors whose > > term expires in 2023 are Samuel Iglesias Gonsálvez, Manasi D Navare, > > Lyude Paul and Daniel Vetter. > > > > A director is expected to participate in the fortnightly IRC meeting to > > discuss current business and to attend the annual meeting of the X.Org > > Foundation, which will be held at a location determined in advance by > > the Board of Directors. > > > > A member may nominate themselves or any other member they feel is > > qualified. Nominations should be sent to the Election Committee at > > elections at x.org. > > > > Nominees shall be required to be current members of the X.Org > > Foundation, and submit a personal statement of up to 200 words that will > > be provided to prospective voters. The collected statements, along with > > the statement of contribution to the X.Org Foundation in the member's > > account page on http://members.x.org, will be made available to all > > voters to help them make their voting decisions. > > > > Nominations, membership applications or renewals and completed personal > > statements must be received no later than 23:59 UTC on 19 March 2023. > > > > The slate of candidates will be published 26 March 2023 and candidate > > Q&A will begin then. The deadline for Xorg membership applications and > > renewals is 26 March 2023. > > > > Cheers, > > Ricardo Garcia, on behalf of the X.Org BoD > > >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uapi: Replace fake flex-array with flexible-array member
== Series Details ==
Series: drm/i915/uapi: Replace fake flex-array with flexible-array member
URL : https://patchwork.freedesktop.org/series/115326/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12873_full -> Patchwork_115326v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_115326v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl: [PASS][1] -> [ABORT][2] ([i915#180])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-apl3/igt@gem_ctx_isolation@preservation...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-apl4/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-glk3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2122])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a1.html
Possible fixes
* igt@fbdev@info:
- {shard-tglu}: [SKIP][13] ([i915#2582]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-tglu-9/igt@fb...@info.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-tglu-8/igt@fb...@info.html
* igt@fbdev@read:
- {shard-rkl}:[SKIP][15] ([i915#2582]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-3/igt@fb...@read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-rkl-6/igt@fb...@read.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][17] ([fdo#103375]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-rkl-1/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-tglu}: [FAIL][19] ([i915#2842]) -> [PASS][20] +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-tglu-7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-tglu-4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-2/igt@gem_exec_fair@basic-none-...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-rkl-5/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [FAIL][23] ([i915#2842]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk1/igt@gem_exec_fair@basic-n...@rcs0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
== Series Details ==
Series: series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
URL : https://patchwork.freedesktop.org/series/115315/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12873_full -> Patchwork_115315v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_115315v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-glk9/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk4/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-glk9/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html
* igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-glk1/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
* igt@perf@stress-open-close:
- shard-glk: [PASS][11] -> [ABORT][12] ([i915#5213])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk5/igt@p...@stress-open-close.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-glk3/igt@p...@stress-open-close.html
Possible fixes
* igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][13] ([i915#3281]) -> [PASS][14] +9 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-4/igt@api_intel...@object-reloc-keep-cache.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [FAIL][15] ([i915#2842]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi@lmem0:
- {shard-dg1}:[DMESG-WARN][17] ([i915#4391]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-dg1-13/igt@gem_lmem_swapping@heavy-verify-mu...@lmem0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-dg1-14/igt@gem_lmem_swapping@heavy-verify-mu...@lmem0.html
* igt@gem_lmem_swapping@verify@lmem0:
- {shard-dg1}:[DMESG-WARN][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-dg1-13/igt@gem_lmem_swapping@ver...@lmem0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-dg1-14/igt@gem_lmem_swapping@ver...@lmem0.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][21] ([fdo#111656]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-2/igt@gem_mmap_...@coherency.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-rkl-5/igt@gem_mmap_...@coherency.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- {shard-rkl}:[SKIP][23] ([i915#3282]) -> [PASS][24] +6 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-4/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/shard-rkl-5/igt@gem_partial_pwrite_pr..
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Communicate display power demands to pcode more accurately (rev3)
== Series Details ==
Series: drm/i915/display: Communicate display power demands to pcode more
accurately (rev3)
URL : https://patchwork.freedesktop.org/series/114401/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12873_full -> Patchwork_114401v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_114401v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-apl6/igt@gen9_exec_pa...@allowed-single.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-glk1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2346]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
Possible fixes
* igt@fbdev@eof:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-2/igt@fb...@eof.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-rkl-6/igt@fb...@eof.html
* igt@fbdev@info:
- {shard-tglu}: [SKIP][13] ([i915#2582]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-tglu-9/igt@fb...@info.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-tglu-2/igt@fb...@info.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][15] ([fdo#103375]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-rkl-2/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][17] ([i915#2846]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk4/igt@gem_exec_f...@basic-deadline.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-3/igt@gem_exec_fair@basic-none-r...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [FAIL][21] ([i915#2842]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_reloc@basic-concurrent16:
- {shard-rkl}:[SKIP][23] ([i915#3281]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/shard-rkl-3/igt@gem_exec_re...@basic-concurrent16.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/shard-rkl-5/igt@gem_exec_re...@basic-concurrent16.html
* igt@gem_lmem_swapping@heavy-verify-multi@lmem0:
- {shard-dg1}:[DMESG
Re: [Intel-gfx] [PATCH v10 09/15] drm/syncobj: Add deadline support for syncobj waits
On Fri, Mar 17, 2023 at 12:08 PM Faith Ekstrand wrote:
>
>
> On Wed, Mar 8, 2023 at 9:54 AM Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Add a new flag to let userspace provide a deadline as a hint for syncobj
>> and timeline waits. This gives a hint to the driver signaling the
>> backing fences about how soon userspace needs it to compete work, so it
>> can addjust GPU frequency accordingly. An immediate deadline can be
>> given to provide something equivalent to i915 "wait boost".
>>
>> v2: Use absolute u64 ns value for deadline hint, drop cap and driver
>> feature flag in favor of allowing count_handles==0 as a way for
>> userspace to probe kernel for support of new flag
>> v3: More verbose comments about UAPI
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 64 ---
>> include/uapi/drm/drm.h| 17 ++
>> 2 files changed, 68 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index 0c2be8360525..a85e9464f07b 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -126,6 +126,11 @@
>> * synchronize between the two.
>> * This requirement is inherited from the Vulkan fence API.
>> *
>> + * If &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also set
>> + * a fence deadline hint on the backing fences before waiting, to provide
>> the
>> + * fence signaler with an appropriate sense of urgency. The deadline is
>> + * specified as an absolute &CLOCK_MONOTONIC value in units of ns.
>> + *
>> * Similarly, &DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
>> * handles as well as an array of u64 points and does a host-side wait on
>> all
>> * of syncobj fences at the given points simultaneously.
>> @@ -973,7 +978,8 @@ static signed long drm_syncobj_array_wait_timeout(struct
>> drm_syncobj **syncobjs,
>> uint32_t count,
>> uint32_t flags,
>> signed long timeout,
>> - uint32_t *idx)
>> + uint32_t *idx,
>> + ktime_t *deadline)
>> {
>> struct syncobj_wait_entry *entries;
>> struct dma_fence *fence;
>> @@ -1053,6 +1059,15 @@ static signed long
>> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
>> drm_syncobj_fence_add_wait(syncobjs[i], &entries[i]);
>> }
>>
>> + if (deadline) {
>> + for (i = 0; i < count; ++i) {
>> + fence = entries[i].fence;
>> + if (!fence)
>> + continue;
>> + dma_fence_set_deadline(fence, *deadline);
>> + }
>> + }
>> +
>> do {
>> set_current_state(TASK_INTERRUPTIBLE);
>>
>> @@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device
>> *dev,
>> struct drm_file *file_private,
>> struct drm_syncobj_wait *wait,
>> struct drm_syncobj_timeline_wait
>> *timeline_wait,
>> - struct drm_syncobj **syncobjs, bool
>> timeline)
>> + struct drm_syncobj **syncobjs, bool
>> timeline,
>> + ktime_t *deadline)
>> {
>> signed long timeout = 0;
>> uint32_t first = ~0;
>> @@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device
>> *dev,
>> NULL,
>> wait->count_handles,
>> wait->flags,
>> -timeout, &first);
>> +timeout, &first,
>> +deadline);
>> if (timeout < 0)
>> return timeout;
>> wait->first_signaled = first;
>> @@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device
>> *dev,
>>
>> u64_to_user_ptr(timeline_wait->points),
>>
>> timeline_wait->count_handles,
>>
>> timeline_wait->flags,
>> -timeout, &first);
>> +timeout, &first,
>> +deadline);
>> if (timeout < 0)
>> retur
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uapi: Replace fake flex-array with flexible-array member
== Series Details == Series: drm/i915/uapi: Replace fake flex-array with flexible-array member URL : https://patchwork.freedesktop.org/series/115326/ State : success == Summary == CI Bug Log - changes from CI_DRM_12873 -> Patchwork_115326v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/index.html Participating hosts (35 -> 35) -- Additional (2): bat-atsm-1 bat-dg1-6 Missing(2): bat-adlm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_115326v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-atsm-1/igt@fb...@eof.html * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][2] ([i915#6687] / [i915#7978]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#4083]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-atsm-1/igt@gem_m...@basic.html - bat-dg1-6: NOTRUN -> [SKIP][4] ([i915#4083]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@gem_m...@basic.html * igt@gem_render_tiled_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][6] ([i915#8062]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#4077]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#4079]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][10] ([i915#8060]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#7561]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-6: NOTRUN -> [SKIP][12] ([i915#6621]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_lrc: - bat-adlp-9: [PASS][13] -> [INCOMPLETE][14] ([i915#4983]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][15] ([i915#6367] / [i915#7996]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_selftest@live@workarounds: - bat-rpls-1: [PASS][16] -> [DMESG-FAIL][17] ([i915#7102]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/bat-rpls-1/igt@i915_selftest@l...@workarounds.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-rpls-1/igt@i915_selftest@l...@workarounds.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-6: NOTRUN -> [SKIP][18] ([i915#4215]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-6: NOTRUN -> [SKIP][19] ([i915#4212]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-6: NOTRUN -> [SKIP][20] ([i915#7828]) +8 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115326v1/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-nick:NOTRUN -> [SKIP][21] ([fdo#109271
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/uapi: Replace fake flex-array with flexible-array member
== Series Details == Series: drm/i915/uapi: Replace fake flex-array with flexible-array member URL : https://patchwork.freedesktop.org/series/115326/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115326/revisions/1/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uapi: Replace fake flex-array with flexible-array member
== Series Details == Series: drm/i915/uapi: Replace fake flex-array with flexible-array member URL : https://patchwork.freedesktop.org/series/115326/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115326/revisions/1/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/uapi: Replace fake flex-array with flexible-array member
== Series Details == Series: drm/i915/uapi: Replace fake flex-array with flexible-array member URL : https://patchwork.freedesktop.org/series/115326/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115326/revisions/1/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
Re: [Intel-gfx] [PATCH v6 02/12] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling
On 3/16/2023 8:43 PM, Dixit, Ashutosh wrote: On Wed, 15 Mar 2023 18:00:51 -0700, Umesh Nerlige Ramappa wrote: From: Vinay Belgaumkar Hi Vinay, If BIOS enables/disables C6, i915 should do the same. So MTL bios has a control for enabling/disabling C6? Both RC6 and MC6 individually or collectively? Yes, we can toggle both independently in BIOS. What happens if bios has disabled RC6 and i915 enables it: just that it will bust OA? Yes, since OA init will rely on this information. Thanks, Vinay. The patch itself LGTM if the above is true, I can R-b it after I hear about the above. Thanks. -- Ashutosh Also, retain this value across driver reloads. This is needed only for MTL as of now due to an existing bug in OA which needs C6 disabled for it to function. BIOS behavior is also different across platforms in terms of how C6 is enabled. Signed-off-by: Vinay Belgaumkar
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
== Series Details == Series: series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c URL : https://patchwork.freedesktop.org/series/115315/ State : success == Summary == CI Bug Log - changes from CI_DRM_12873 -> Patchwork_115315v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/index.html Participating hosts (35 -> 34) -- Additional (1): bat-dg1-6 Missing(2): bat-adlm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_115315v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap@basic: - bat-dg1-6: NOTRUN -> [SKIP][1] ([i915#4083]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@gem_m...@basic.html * igt@gem_render_tiled_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][2] ([i915#4079]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-6: NOTRUN -> [SKIP][4] ([i915#7561]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#6621]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][6] -> [ABORT][7] ([i915#4983] / [i915#7911] / [i915#7981]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12873/bat-rpls-1/igt@i915_selftest@l...@requests.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#4215]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4212]) +7 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-6: NOTRUN -> [SKIP][10] ([i915#7828]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-nick:NOTRUN -> [SKIP][11] ([fdo#109271]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-jsl-3: NOTRUN -> [SKIP][12] ([i915#7828]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-n3050: NOTRUN -> [SKIP][13] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#4103] / [i915#4213]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-6: NOTRUN -> [SKIP][15] ([fdo#109285]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - bat-dg1-6: NOTRUN -> [SKIP][16] ([i915#1072] / [i915#4078]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - bat-dg1-6: NOTRUN -> [SKIP][17] ([i915#3555]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-gtt: - bat-dg1-6: NOTRUN -> [SKIP][18] ([i915#3708] / [i915#4077]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@prime_v...@basic-gtt.html * igt@prime_vgem@basic-read: - bat-dg1-6: NOTRUN -> [SKIP][19] ([i915#3708]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115315v1/bat-dg1-6/igt@prime_v...@b
[Intel-gfx] [PATCH][next] drm/i915/uapi: Replace fake flex-array with flexible-array member
Zero-length arrays as fake flexible arrays are deprecated and we are
moving towards adopting C99 flexible-array members instead.
Address the following warning found with GCC-13 and
-fstrict-flex-arrays=3 enabled:
drivers/gpu/drm/i915/gem/i915_gem_context.c: In function
‘set_proto_ctx_engines.isra’:
drivers/gpu/drm/i915/gem/i915_gem_context.c:769:41: warning: array subscript n
is outside array bounds of ‘struct i915_engine_class_instance[0]’
[-Warray-bounds=]
769 | if (copy_from_user(&ci, &user->engines[n], sizeof(ci)))
{
| ^
./include/uapi/drm/i915_drm.h:2494:43: note: while referencing ‘engines’
2494 | struct i915_engine_class_instance engines[0];
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
Link: https://github.com/KSPP/linux/issues/21
Link: https://github.com/KSPP/linux/issues/271
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva
---
include/uapi/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8df261c5ab9b..5e458d6f2895 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2491,7 +2491,7 @@ struct i915_context_param_engines {
#define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0 /* see
i915_context_engines_load_balance */
#define I915_CONTEXT_ENGINES_EXT_BOND 1 /* see i915_context_engines_bond */
#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
i915_context_engines_parallel_submit */
- struct i915_engine_class_instance engines[0];
+ struct i915_engine_class_instance engines[];
} __attribute__((packed));
#define I915_DEFINE_CONTEXT_PARAM_ENGINES(name__, N__) struct { \
--
2.34.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev2)
== Series Details == Series: series starting with [v2,1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev2) URL : https://patchwork.freedesktop.org/series/114999/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114999/revisions/2/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)') Build failed, no error log produced
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
== Series Details == Series: series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c URL : https://patchwork.freedesktop.org/series/115315/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115315/revisions/1/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
== Series Details == Series: series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c URL : https://patchwork.freedesktop.org/series/115315/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115315/revisions/1/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
== Series Details == Series: series starting with [1/3] drm/i915/psr: move PSR debugfs to intel_psr.c URL : https://patchwork.freedesktop.org/series/115315/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115315/revisions/1/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()
On Wed, Mar 15, 2023 at 5:22 PM Steven Rostedt wrote:
>
> I hope that this gets in by -rc3, as I want to start basing my next branch
> on that tag.
My tree should have it now as commit c00133a9e87e ("drm/ttm: drop
extra ttm_bo_put in ttm_bo_cleanup_refs").
Linus
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use separate "DC off" power well for ADL-P and DG2
On Thu, Mar 16, 2023 at 01:25:45PM -0700, Radhakrishna Sripada wrote:
> From: Matt Roper
>
> Although ADL-P and DG2 both use the same general power well setup, the
> DC5/DC6 requirements are slightly different which means each platform
> should have its own "DC off" power well.
>
> DG2 (i.e., Xe_HPD IP) requires that DC5 be disabled whenever PG2 is
> active. However ADL-P (i.e., Xe_LPD IP) only requires DC5/DC6 to be
> disabled when the PGC or PGD subwells are active; we should be able to
> remain in these DC states when PGB and general PG2 functionality is in
> use.
>
> Bspec: 49193
> Signed-off-by: Matt Roper
> Signed-off-by: Radhakrishna Sripada
> ---
> .../i915/display/intel_display_power_map.c| 41 +--
> 1 file changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> index 6645eb1911d8..d9e02cc9cf3c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> @@ -1301,7 +1301,8 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
> */
>
> I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
> - XELPD_PW_2_POWER_DOMAINS,
> + XELPD_PW_C_POWER_DOMAINS,
> + XELPD_PW_D_POWER_DOMAINS,
> POWER_DOMAIN_PORT_DSI,
> POWER_DOMAIN_AUDIO_MMIO,
> POWER_DOMAIN_AUX_A,
> @@ -1310,14 +1311,38 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
> POWER_DOMAIN_DC_OFF,
> POWER_DOMAIN_INIT);
>
> -static const struct i915_power_well_desc xelpd_power_wells_main[] = {
> +static const struct i915_power_well_desc xelpd_power_wells_dcoff[] = {
Nit: Here and in the xehpd defintion, s/dcoff/dc_off/ to match other platforms.
> {
> .instances = &I915_PW_INSTANCES(
> I915_PW("DC_off", &xelpd_pwdoms_dc_off,
> .id = SKL_DISP_DC_OFF),
> ),
> .ops = &gen9_dc_off_power_well_ops,
> - }, {
> + }
> +};
> +
> +I915_DECL_PW_DOMAINS(xehpd_pwdoms_dc_off,
> + XELPD_PW_2_POWER_DOMAINS,
> + POWER_DOMAIN_PORT_DSI,
> + POWER_DOMAIN_AUDIO_MMIO,
> + POWER_DOMAIN_AUX_A,
> + POWER_DOMAIN_AUX_B,
> + POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_DC_OFF,
> + POWER_DOMAIN_INIT);
> +
> +static const struct i915_power_well_desc xehpd_power_wells_dcoff[] = {
> + {
> + .instances = &I915_PW_INSTANCES(
> + I915_PW("DC_off", &xehpd_pwdoms_dc_off,
> + .id = SKL_DISP_DC_OFF),
> + ),
> + .ops = &gen9_dc_off_power_well_ops,
> + }
> +};
Could you move the xehpd definitions to precede xehpd_power_wells[]?
Patches 1, 2 look ok to me:
Reviewed-by: Imre Deak
> +
> +static const struct i915_power_well_desc xelpd_power_wells_main[] = {
> + {
> .instances = &I915_PW_INSTANCES(
> I915_PW("PW_2", &xelpd_pwdoms_pw_2,
> .hsw.idx = ICL_PW_CTL_IDX_PW_2,
> @@ -1400,6 +1425,14 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> static const struct i915_power_well_desc_list xelpd_power_wells[] = {
> I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
> I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
> + I915_PW_DESCRIPTORS(xelpd_power_wells_dcoff),
> + I915_PW_DESCRIPTORS(xelpd_power_wells_main),
> +};
> +
> +static const struct i915_power_well_desc_list xehpd_power_wells[] = {
> + I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
> + I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
> + I915_PW_DESCRIPTORS(xehpd_power_wells_dcoff),
> I915_PW_DESCRIPTORS(xelpd_power_wells_main),
> };
>
> @@ -1624,6 +1657,8 @@ int intel_display_power_map_init(struct
> i915_power_domains *power_domains)
>
> if (DISPLAY_VER(i915) >= 14)
> return set_power_wells(power_domains, xelpdp_power_wells);
> + else if (IS_DG2(i915))
> + return set_power_wells(power_domains, xehpd_power_wells);
> else if (DISPLAY_VER(i915) >= 13)
> return set_power_wells(power_domains, xelpd_power_wells);
> else if (IS_DG1(i915))
> --
> 2.34.1
>
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/debugfs: switch crtc debugfs to struct intel_crtc
== Series Details ==
Series: series starting with [1/2] drm/i915/debugfs: switch crtc debugfs to
struct intel_crtc
URL : https://patchwork.freedesktop.org/series/115314/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/gpu/drm/i915/display/intel_display_debugfs.o
drivers/gpu/drm/i915/display/intel_display_debugfs.c: In function
‘crtc_updates_add’:
drivers/gpu/drm/i915/display/intel_display_debugfs.c:810:52: error: ‘struct
intel_crtc’ has no member named ‘debugfs_entry’
810 | debugfs_create_file("i915_update_info", 0644, crtc->debugfs_entry,
|^~
make[5]: *** [scripts/Makefile.build:252:
drivers/gpu/drm/i915/display/intel_display_debugfs.o] Error 1
make[4]: *** [scripts/Makefile.build:494: drivers/gpu/drm/i915] Error 2
make[3]: *** [scripts/Makefile.build:494: drivers/gpu/drm] Error 2
make[2]: *** [scripts/Makefile.build:494: drivers/gpu] Error 2
make[1]: *** [scripts/Makefile.build:494: drivers] Error 2
make: *** [Makefile:2028: .] Error 2
Build failed, no error log produced
[Intel-gfx] ✗ Fi.CI.BUILD: failure for High refresh rate PSR fixes (rev2)
== Series Details == Series: High refresh rate PSR fixes (rev2) URL : https://patchwork.freedesktop.org/series/115109/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115109/revisions/2/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)') Build failed, no error log produced
[Intel-gfx] PR for ADLP DMC v2.19 and MTL DMC v2.12
The following changes since commit c761dbe804f903cc2df81f251d367cca285eca06: Merge tag 'iwlwifi-fw-2023-03-13' of http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware (2023-03-13 09:20:47 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware dmc-adlp_2.19-mtl_2.12 for you to fetch changes up to a18a444bfbd6097515272f587b86856a6de15218: i915: Update MTL DMC to v2.12 (2023-03-17 14:06:32 -0300) Gustavo Sousa (2): i915: Update ADLP DMC to v2.19 i915: Update MTL DMC to v2.12 WHENCE| 4 ++-- i915/adlp_dmc.bin | Bin 78500 -> 79044 bytes i915/mtl_dmc.bin | Bin 48512 -> 49104 bytes 3 files changed, 2 insertions(+), 2 deletions(-)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Communicate display power demands to pcode more accurately (rev3)
== Series Details == Series: drm/i915/display: Communicate display power demands to pcode more accurately (rev3) URL : https://patchwork.freedesktop.org/series/114401/ State : success == Summary == CI Bug Log - changes from CI_DRM_12873 -> Patchwork_114401v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/index.html Participating hosts (35 -> 35) -- Additional (2): bat-atsm-1 bat-dg1-6 Missing(2): bat-adlm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_114401v3 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-atsm-1/igt@gem_m...@basic.html - bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#4083]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@gem_m...@basic.html * igt@gem_render_tiled_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][5] ([i915#8062]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html - bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][9] ([i915#8060]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-6: NOTRUN -> [SKIP][10] ([i915#7561]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#6621]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-6: NOTRUN -> [SKIP][12] ([i915#4215]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#4212]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#7828]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html - fi-bsw-nick:NOTRUN -> [SKIP][15] ([fdo#109271]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-jsl-3: NOTRUN -> [SKIP][16] ([i915#7828]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rpls-1: NOTRUN -> [SKIP][17] ([i915#7828]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - bat-dg1-6: NOTRUN -> [SKIP][18] ([i915#4103] / [i915#4213]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-6: NOTRUN -> [SKIP][19] ([fdo#109285]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v3/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@suspend-r
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
On Fri, Mar 17, 2023 at 06:00:23PM +0200, Jani Nikula wrote:
> On Fri, 17 Mar 2023, Ville Syrjälä wrote:
> > On Fri, Mar 17, 2023 at 04:30:37PM +0200, Ville Syrjälä wrote:
> >> On Fri, Mar 17, 2023 at 03:37:09PM +0200, Jani Nikula wrote:
> >> > On Fri, 17 Mar 2023, Ville Syrjälä wrote:
> >> > > On Fri, Mar 17, 2023 at 02:53:52PM +0200, Jani Nikula wrote:
> >> > >> The pipe may differ from crtc index if pipes are fused off. For
> >> > >> testing
> >> > >> purposes, IGT needs to know the pipe.
> >> > >>
> >> > >> There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
> >> > >> the upcoming Xe driver won't have that IOCTL, and going forward, we'll
> >> > >> want a unified interface for testing i915 and Xe, as they share the
> >> > >> display code. Thus add the debugfs for i915 display.
> >> > >>
> >> > >> Signed-off-by: Jani Nikula
> >> > >> ---
> >> > >> .../gpu/drm/i915/display/intel_display_debugfs.c| 13
> >> > >> +
> >> > >> 1 file changed, 13 insertions(+)
> >> > >>
> >> > >> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> > >> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> > >> index faa44fb80aac..e85270adca95 100644
> >> > >> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> > >> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> > >> @@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct
> >> > >> seq_file *m, void *data)
> >> > >> }
> >> > >> DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
> >> > >>
> >> > >> +/* Pipe may differ from crtc index if pipes are fused off */
> >> > >> +static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
> >> > >> +{
> >> > >> + struct intel_crtc *crtc = m->private;
> >> > >> +
> >> > >> + seq_printf(m, "%d\n", crtc->pipe);
> >> > >
> >> > > Are we happy with an integer or should we use the actual alphabetic
> >> > > name here?
> >> >
> >> > Primarily I considered the programmatic use case, and the ease of
> >> > switching over from the ioctl. What do we gain by making IGT parse this?
> >>
> >> Well even the integer is represented in ascii so parsing
> >> needs to happen anyway. But I was mainly thinking if any
> >> human looks at it they may be confused as to what the
> >> raw integer even means.
> >
> > Eg. if I just jump on some random machine an do
> >
> > # grep . crtc-1/*
> > ...
> > i915_pipe: 3
> > ...
> >
> > Now I need to most likely count with my fingers
> > to figure out I'm actually looking at pipe D :P
>
> Fair enough, not unreasonable.
>
> Is it enough to have just A, B, ... or do we go with explanatory text
> like i915_current_bpc has "Current: %u\n"?
Think just the value should be sufficient for single value files.
I've occasionally pondered if everything in debugfs should be
single value only, but then we'd end up with tons of files for
certain things...
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Communicate display power demands to pcode more accurately (rev3)
== Series Details == Series: drm/i915/display: Communicate display power demands to pcode more accurately (rev3) URL : https://patchwork.freedesktop.org/series/114401/ State : warning == Summary == Error: dim checkpatch failed da82682afba7 drm/i915/display: Communicate display power demands to pcode more accurately -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: Adding new sequence with current cdclk associate with voltage value masking. -:83: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #83: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:2273: + drm_err(&i915->drm, + "Failed to inform PCU about display config (err %d)\n", -:104: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'new_cdclk_state->active_pipes == old_cdclk_state->active_pipes' #104: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:2356: + if (!intel_cdclk_changed(&old_cdclk_state->actual, +&new_cdclk_state->actual) && +(new_cdclk_state->active_pipes == +old_cdclk_state->active_pipes)) -:279: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #279: FILE: drivers/gpu/drm/i915/i915_reg.h:6424: +#define DISPLAY_TO_PCODE_PIPE_COUNT(x) REG_FIELD_PREP(DISPLAY_TO_PCODE_PIPE_COUNT_MASK, (x)) -:281: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #281: FILE: drivers/gpu/drm/i915/i915_reg.h:6426: +#define DISPLAY_TO_PCODE_UPDATE_MASK(cdclk, num_pipes, voltage_level) \ + (DISPLAY_TO_PCODE_CDCLK(cdclk)) | \ + (DISPLAY_TO_PCODE_PIPE_COUNT(num_pipes)) | \ + (DISPLAY_TO_PCODE_VOLTAGE(voltage_level)) total: 1 errors, 2 warnings, 2 checks, 244 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Communicate display power demands to pcode more accurately (rev3)
== Series Details == Series: drm/i915/display: Communicate display power demands to pcode more accurately (rev3) URL : https://patchwork.freedesktop.org/series/114401/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114401/revisions/3/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/display: Communicate display power demands to pcode more accurately (rev3)
== Series Details == Series: drm/i915/display: Communicate display power demands to pcode more accurately (rev3) URL : https://patchwork.freedesktop.org/series/114401/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114401/revisions/3/mbox/ not applied Committer identity unknown *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'kbuild2@gfx-ci.(none)')
Re: [Intel-gfx] [PATCH] drm/i915/selftests: keep same cache settings as timeline
On Thu, Mar 16, 2023 at 08:43:46PM -0700, Yang, Fei wrote:
> >> From: Fei Yang
> >>
> >> On MTL, objects allocated through i915_gem_object_create_internal() are
> >> mapped as uncached in GPU by default because HAS_LLC is false. However
> >> in the live_hwsp_read selftest these watcher objects are mapped as WB
> >> on CPU side. The conseqence is that the updates done by the GPU are not
> >> immediately visible to CPU, thus the selftest is randomly failing due to
> >> the stale data in CPU cache. Solution can be either setting WC for CPU +
> >> UC for GPU, or WB for CPU + 1-way coherent WB for GPU.
> >> To keep the consistency, let's simply inherit the same cache settings
> >> from the timeline, which is WB for CPU + 1-way coherent WB for GPU,
> >> because this test is supposed to emulate the behavior of the timeline
> >> anyway.
> >>
> >> Signed-off-by: Fei Yang
> >
> > It looks like there might be an indentation mistake on the second line
> > of the i915_gem_object_pin_map_unlocked() call, but we can fix that up
> > while applying; no need to re-send.
> >
> > Reviewed-by: Matt Roper
>
> Thanks for reviewing.
>
> > Is there an FDO issue # for the random failures thar were being seen?
> > If so, we should add a Closes: or References: tag here.
>
> I'm not aware of a FDO filed for this failure. That might be because the
> issue is reproduced on MTL which might not be widely available to the
> community yet.
Yeah, I was thinking CI would have filed some, but I just remembered we
don't have public CI setup yet for MTL, so no automated bugs are coming
in yet.
Applied to drm-intel-gt-next. Thanks for the patch.
Matt
>
> > Matt
> >> ---
> >> drivers/gpu/drm/i915/gt/selftest_timeline.c | 14 +++---
> >> 1 file changed, 11 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
> >> b/drivers/gpu/drm/i915/gt/selftest_timeline.c
> >> index 522d0190509c..631aaed9bc3d 100644
> >> --- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
> >> +++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
> >> @@ -825,7 +825,8 @@ static bool cmp_gte(u32 a, u32 b)
> >>return a >= b;
> >> }
> >>
> >> -static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt)
> >> +static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt,
> >> + struct intel_timeline *tl)
> >> {
> >>struct drm_i915_gem_object *obj;
> >>struct i915_vma *vma;
> >> @@ -834,7 +835,10 @@ static int setup_watcher(struct hwsp_watcher *w,
> >> struct intel_gt *gt)
> >>if (IS_ERR(obj))
> >>return PTR_ERR(obj);
> >>
> >> - w->map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
> >> + /* keep the same cache settings as timeline */
> >> + i915_gem_object_set_cache_coherency(obj,
> >> tl->hwsp_ggtt->obj->cache_level);
> >> + w->map = i915_gem_object_pin_map_unlocked(obj,
> >> + page_unmask_bits(tl->hwsp_ggtt->obj->mm.mapping));
> >>if (IS_ERR(w->map)) {
> >>i915_gem_object_put(obj);
> >>return PTR_ERR(w->map);
> >> @@ -1004,8 +1008,10 @@ static int live_hwsp_read(void *arg)
> >>if (!tl->has_initial_breadcrumb)
> >>goto out_free;
> >>
> >> + selftest_tl_pin(tl);
> >> +
> >>for (i = 0; i < ARRAY_SIZE(watcher); i++) {
> >> - err = setup_watcher(&watcher[i], gt);
> >> + err = setup_watcher(&watcher[i], gt, tl);
> >>if (err)
> >>goto out;
> >>}
> >> @@ -1160,6 +1166,8 @@ static int live_hwsp_read(void *arg)
> >>for (i = 0; i < ARRAY_SIZE(watcher); i++)
> >>cleanup_watcher(&watcher[i]);
> >>
> >> + intel_timeline_unpin(tl);
> >> +
> >>if (igt_flush_test(gt->i915))
> >>err = -EIO;
> >>
> >> --
> >> 2.25.1
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH v6 12/12] drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS
On Thu, Mar 16, 2023 at 11:06:08PM -0700, Dixit, Ashutosh wrote:
On Thu, 16 Mar 2023 22:14:52 -0700, Dixit, Ashutosh wrote:
On Wed, 15 Mar 2023 18:01:01 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
Mostly looks good but one nit below.
> OAM does not work with media C6 enabled on some steppings of MTL.
> Disable OAM if we detect that media C6 was enabled in bios.
>
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/i915_perf.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
> index 77fae3d80128..4ac6535a0356 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -209,6 +209,7 @@
> #include "gt/intel_gt_regs.h"
> #include "gt/intel_lrc.h"
> #include "gt/intel_lrc_reg.h"
> +#include "gt/intel_rc6.h"
> #include "gt/intel_ring.h"
> #include "gt/uc/intel_guc_slpc.h"
>
> @@ -4898,6 +4899,18 @@ static u32 num_perf_groups_per_gt(struct intel_gt *gt)
>
> static u32 __oam_engine_group(struct intel_engine_cs *engine)
> {
> + /*
> + * Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
> + * C6 disable in BIOS. Do not enable OA for media classes if MC6 is
> + * enabled in BIOS.
> + */
> + if (IS_MTL_MEDIA_STEP(engine->i915, STEP_A0, STEP_C0) &&
> + intel_check_bios_c6_setup(&engine->gt->rc6)) {
> + drm_notice_once(&engine->i915->drm,
> + "OAM requires media C6 to be disabled in BIOS\n");
I think the typical mode of working with MTL would be to enable C6 unless OA
is needed. But this will print out this notice on every MTL system. So IMO
we should print this out only when a OAM perf stream is opened and that
fails.
We could do that. I can move this to the open ioctl.
Though not sure if it's ok to add a line to an already cluttered dmesg? The
default console log level is 4 (WARNING) so maybe ok?
https://linuxconfig.org/introduction-to-the-linux-kernel-log-levels
Though if we fail the opening of an OAM stream we could make it a drm_warn?
Hmm, I was thinking of just keeping it in line with the other failures
in open ioctl - a drm_err message, so that it helps debug.
Another idea: there is a drm_notice in Patch 2 when C6 is disabled, maybe
we could just change it to "C6 disabled by BIOS, OAM availbable\n" or
something like that and just remove the notice from here. I think we should
avoid the notice when C6 is enabled since that is likely to be the default
mode.
Ideally patch 2 is required irrespective of the OA issue, since i915
should make sure it honors the bios setting. With that in mind, I would
leave the drm message in OA code.
> + return PERF_GROUP_INVALID;
> + }
> +
>if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70)) {
>/*
> * There's 1 SAMEDIA gt and 1 OAM per SAMEDIA gt. All media slices
> @@ -5317,6 +5330,23 @@ int i915_perf_ioctl_version(struct drm_i915_private
*i915)
> *
> * 7: Add support for video decode and enhancement classes.
> */
> +
> + /*
> + * Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
> + * C6 disable in BIOS. Do not enable OA for media classes if MC6 is
> + * enabled in BIOS.
Maybe add something like "Return version 6 to indicate non-support for OAM."
just to make clear.
will do
Thanks,
Umesh
> + */
> + if (IS_MTL_MEDIA_STEP(i915, STEP_A0, STEP_C0)) {
> + struct intel_gt *gt;
> + int i;
> +
> + for_each_gt(gt, i915, i) {
> + if (gt->type == GT_MEDIA &&
> + intel_check_bios_c6_setup(>->rc6))
> + return 6;
> + }
> + }
> +
>return 7;
> }
>
> --
> 2.36.1
>
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC
On Fri, Mar 17, 2023 at 8:58 AM Greg KH wrote:
>
> On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> > On 3/15/2023 10:57, Greg KH wrote:
> > > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > > On 3/15/2023 00:51, Greg KH wrote:
> > > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, john.c.harri...@intel.com
> > > > > wrote:
> > > > > > From: John Harrison
> > > > > >
> > > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > > use it.
> > > > > >
> > > > > > Signed-off-by: John Harrison
> > > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound
> > > > > > anywhere")
> > > > > > Cc: Chris Wilson
> > > > > > Cc: Joonas Lahtinen
> > > > > > Cc: Jani Nikula
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > > Cc: # v4.9+
> > > > > > Tested-by: Jouni Högander
> > > > > > Reviewed-by: Daniele Ceraolo Spurio
> > > > > >
> > > > > > Link:
> > > > > > https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
> > > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > > Signed-off-by: Jani Nikula
> > > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > > Signed-off-by: John Harrison
> > > > > > ---
> > > > > >drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > > >1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > Also queued up for 5.10.y, you forgot that one :)
> > > > I'm still working through the backlog of them.
> > > >
> > > > Note that these patches must all be applied as a pair. The 'don't use
> > > > stolen' can be applied in isolation but won't totally fix the problem.
> > > > However, applying 'don't use BAR mappings' without applying the stolen
> > > > patch
> > > > first will results in problems such as the failure to boot that was
> > > > recently
> > > > reported and resulted in a revert in one of the trees.
> > > I do not understand, you only submitted 1 patch here, what is the
> > > "pair"?
> > The original patch series was two patches -
> > https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> > memory and the other to not use BAR mappings. If the anti-BAR patch is
> > applied without the anti-stolen patch then the i915 driver will attempt to
> > access stolen memory directly which will fail. So both patches must be
> > applied and in the correct order to fix the problem of cache aliasing when
> > using BAR accesses on LLC systems.
> >
> > As above, I am working my way through the bunch of 'FAILED patch' emails.
> > The what-to-do instructions in those emails explicitly say to send the patch
> > individually in reply to the 'FAILED' message rather than as part of any
> > original series.
>
> So what commits exactly in Linus's tree should be in these stable
> branches? Sorry, I still do not understand if we are missing one or if
> we need to revert something.
Hi, Greg,
5.4.237 fails to boot as a Xen PV Dom0. It hangs after modprobe
i915.ko with no further output, though it seems to response to magic
sysrq.
Reverting 5.4.y commit 1aed78cfda7f17f3cc71cb127a85a188eafc679a
("drm/i915: Don't use BAR mappings for ring buffers with LLC") lets it
boot properly.
Thanks,
Jason
Re: [Intel-gfx] [PATCH v2 16/27] KVM: x86: Add a new page-track hook to handle memslot deletion
On Fri, Mar 17, 2023, Yan Zhao wrote:
> On Fri, Mar 10, 2023 at 04:22:47PM -0800, Sean Christopherson wrote:
> > From: Yan Zhao
> >
> > Add a new page-track hook, track_remove_region(), that is called when a
> > memslot DELETE operation is about to be committed. The "remove" hook
> > will be used by KVMGT and will effectively replace the existing
> > track_flush_slot() altogether now that KVM itself doesn't rely on the
> > "flush" hook either.
> >
> > The "flush" hook is flawed as it's invoked before the memslot operation
> > is guaranteed to succeed, i.e. KVM might ultimately keep the existing
> > memslot without notifying external page track users, a.k.a. KVMGT. In
> > practice, this can't currently happen on x86, but there are no guarantees
> > that won't change in the future, not to mention that "flush" does a very
> > poor job of describing what is happening.
> >
> > Pass in the gfn+nr_pages instead of the slot itself so external users,
> > i.e. KVMGT, don't need to exposed to KVM internals (memslots). This will
> > help set the stage for additional cleanups to the page-track APIs.
> >
> > Cc: Zhenyu Wang
> > Signed-off-by: Yan Zhao
> > Co-developed-by: Sean Christopherson
> > Signed-off-by: Sean Christopherson
> ...
>
> > +void kvm_page_track_delete_slot(struct kvm *kvm, struct kvm_memory_slot
> > *slot)
> > +{
> > + struct kvm_page_track_notifier_head *head;
> > + struct kvm_page_track_notifier_node *n;
> > + int idx;
> > +
> > + head = &kvm->arch.track_notifier_head;
> > +
> > + if (hlist_empty(&head->track_notifier_list))
> > + return;
> > +
> > + idx = srcu_read_lock(&head->track_srcu);
> > + hlist_for_each_entry_srcu(n, &head->track_notifier_list, node,
> > + srcu_read_lock_held(&head->track_srcu))
> Sorry, not sure why the alignment here is not right.
> Patchwork just sent me a mail to complain about it.
> Would you mind helping fix it in the next version?
Ah, it's off by two spaces, should be
hlist_for_each_entry_srcu(n, &head->track_notifier_list, node,
srcu_read_lock_held(&head->track_srcu))
I'll get it fixed in the next version.
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
On Fri, 17 Mar 2023, Ville Syrjälä wrote:
> On Fri, Mar 17, 2023 at 04:30:37PM +0200, Ville Syrjälä wrote:
>> On Fri, Mar 17, 2023 at 03:37:09PM +0200, Jani Nikula wrote:
>> > On Fri, 17 Mar 2023, Ville Syrjälä wrote:
>> > > On Fri, Mar 17, 2023 at 02:53:52PM +0200, Jani Nikula wrote:
>> > >> The pipe may differ from crtc index if pipes are fused off. For testing
>> > >> purposes, IGT needs to know the pipe.
>> > >>
>> > >> There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
>> > >> the upcoming Xe driver won't have that IOCTL, and going forward, we'll
>> > >> want a unified interface for testing i915 and Xe, as they share the
>> > >> display code. Thus add the debugfs for i915 display.
>> > >>
>> > >> Signed-off-by: Jani Nikula
>> > >> ---
>> > >> .../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
>> > >> 1 file changed, 13 insertions(+)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> > >> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> > >> index faa44fb80aac..e85270adca95 100644
>> > >> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> > >> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> > >> @@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file
>> > >> *m, void *data)
>> > >> }
>> > >> DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
>> > >>
>> > >> +/* Pipe may differ from crtc index if pipes are fused off */
>> > >> +static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
>> > >> +{
>> > >> + struct intel_crtc *crtc = m->private;
>> > >> +
>> > >> + seq_printf(m, "%d\n", crtc->pipe);
>> > >
>> > > Are we happy with an integer or should we use the actual alphabetic
>> > > name here?
>> >
>> > Primarily I considered the programmatic use case, and the ease of
>> > switching over from the ioctl. What do we gain by making IGT parse this?
>>
>> Well even the integer is represented in ascii so parsing
>> needs to happen anyway. But I was mainly thinking if any
>> human looks at it they may be confused as to what the
>> raw integer even means.
>
> Eg. if I just jump on some random machine an do
>
> # grep . crtc-1/*
> ...
> i915_pipe: 3
> ...
>
> Now I need to most likely count with my fingers
> to figure out I'm actually looking at pipe D :P
Fair enough, not unreasonable.
Is it enough to have just A, B, ... or do we go with explanatory text
like i915_current_bpc has "Current: %u\n"?
BR,
Jani.
>
>>
>> >
>> > > Either way, the series is:
>> > > Reviewed-by: Ville Syrjälä
>> >
>> > Thanks,
>> > Jani.
>> >
>> > >
>> > >> +
>> > >> + return 0;
>> > >> +}
>> > >> +DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
>> > >> +
>> > >> /**
>> > >> * intel_connector_debugfs_add - add i915 specific connector debugfs
>> > >> files
>> > >> * @connector: pointer to a registered drm_connector
>> > >> @@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc
>> > >> *crtc)
>> > >>
>> > >> debugfs_create_file("i915_current_bpc", 0444, root, crtc,
>> > >> &i915_current_bpc_fops);
>> > >> + debugfs_create_file("i915_pipe", 0444, root, crtc,
>> > >> + &intel_crtc_pipe_fops);
>> > >> }
>> > >> --
>> > >> 2.39.2
>> >
>> > --
>> > Jani Nikula, Intel Open Source Graphics Center
>>
>> --
>> Ville Syrjälä
>> Intel
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Fri, Mar 17, 2023 at 3:23 AM Jonas Ådahl wrote: > > On Thu, Mar 16, 2023 at 09:28:55AM -0700, Rob Clark wrote: > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming > > > > > > > > deadline, such as > > > > > > > > vblank, which the fence waiter would prefer not to miss. This > > > > > > > > is to aid > > > > > > > > the fence signaler in making power management decisions, like > > > > > > > > boosting > > > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > > > deadlines > > > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter > > > > > > > > duplicate > > > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > > > fence-context > > > > > > > > implementation will need similar logic to track deadlines > > > > > > > > of all > > > > > > > > the fences on the same timeline. [ckoenig] > > > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > > > v6: More docs > > > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > > Reviewed-by: Christian König > > > > > > > > Acked-by: Pekka Paalanen > > > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > > > --- > > > > > > > > > > > > > > Hi Rob! > > > > > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > > > + > > > > > > > > + > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > + :doc: deadline hints > > > > > > > > + > > > > > > > > DMA Fences Functions Reference > > > > > > > > ~~ > > > > > > > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c > > > > > > > > b/drivers/dma-buf/dma-fence.c > > > > > > > > index 0de0482cd36e..f177c56269bb 100644 > > > > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct > > > > > > > > dma_fence **fences, uint32_t count, > > > > > > > > } > > > > > > > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > > > > > > > > > > > > > +/** > > > > > > > > + * DOC: deadline hints > > > > > > > > + * > > > > > > > > + * In an ideal world, it would be possible to pipeline a > > > > > > > > workload sufficiently > > > > > > > > + * that a utilization based device frequency governor could > > > > > > > > arrive at a minimum > > > > > > > > + * frequency that meets the requirements of the use-case, in > > > > > > > > order to minimize > > > > > > > > + * power consumption. But in the real world there are many > > > > > > > > workloads which > > > > > > > > + * defy this ideal. For example, but not limited to: > > > > > > > > + * > > > > > > > > + * * Workloads that ping-pong between device and CPU, with > > > > > > > > alternating periods > > > > > > > > + * of CPU waiting for device, and device waiting on CPU. > > > > > > > > This can result in > > > > > > > > + * devfreq and cpufreq seeing idle time in their respective > > > > > > > > domains and in > > > > > > > > + * result reduce frequency. > > > > > > > > + * > > > > > > > > + * * Workloads that interact with a periodic time based > > > > > > > > deadline, such as double > > > > > > > > + * buffered GPU rendering vs vblank sync'd page flipping. > > > > > > > > In this scenario, > > > > > > > > + * missing a vblank deadline results in an *increase* in > > > > > > > > idle time on the GPU > > > > > > > > +
Re: [Intel-gfx] [PATCH 1/2] drm/i915/debugfs: switch crtc debugfs to struct intel_crtc
Hi Jani,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Jani-Nikula/drm-i915-debugfs-add-crtc-i915_pipe-debugfs-file/20230317-205512
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230317125352.198042-1-jani.nikula%40intel.com
patch subject: [Intel-gfx] [PATCH 1/2] drm/i915/debugfs: switch crtc debugfs to
struct intel_crtc
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20230317/202303172307.kabtchfp-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/506415b57ce52f43962e9e766ff8dd5410fe3051
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jani-Nikula/drm-i915-debugfs-add-crtc-i915_pipe-debugfs-file/20230317-205512
git checkout 506415b57ce52f43962e9e766ff8dd5410fe3051
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303172307.kabtchfp-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/display/intel_display_debugfs.c: In function
'crtc_updates_add':
>> drivers/gpu/drm/i915/display/intel_display_debugfs.c:810:59: error: 'struct
>> intel_crtc' has no member named 'debugfs_entry'
810 | debugfs_create_file("i915_update_info", 0644,
crtc->debugfs_entry,
| ^~
vim +810 drivers/gpu/drm/i915/display/intel_display_debugfs.c
829270e4552e9e Chris Wilson 2020-12-02 807
506415b57ce52f Jani Nikula 2023-03-17 808 static void
crtc_updates_add(struct intel_crtc *crtc)
829270e4552e9e Chris Wilson 2020-12-02 809 {
829270e4552e9e Chris Wilson 2020-12-02 @810
debugfs_create_file("i915_update_info", 0644, crtc->debugfs_entry,
506415b57ce52f Jani Nikula 2023-03-17 811 crtc,
&crtc_updates_fops);
829270e4552e9e Chris Wilson 2020-12-02 812 }
829270e4552e9e Chris Wilson 2020-12-02 813
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Fri, 17 Mar 2023 00:57:23 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Friday, March 17, 2023 8:23 AM > > > > On Thu, 16 Mar 2023 23:29:21 + > > "Tian, Kevin" wrote: > > > > > > From: Alex Williamson > > > > Sent: Friday, March 17, 2023 2:46 AM > > > > > > > > On Wed, 15 Mar 2023 23:31:23 + > > > > "Tian, Kevin" wrote: > > > > > > > > > > From: Alex Williamson > > > > > > Sent: Thursday, March 16, 2023 6:53 AM > > > > > > I'm afraid this proposal reduces or eliminates the handshake we have > > > > > > with userspace between VFIO_DEVICE_GET_PCI_HOT_RESET_INFO > > and > > > > > > VFIO_DEVICE_PCI_HOT_RESET, which could promote userspace to > > ignore > > > > the > > > > > > _INFO ioctl altogether, resulting in drivers that don't understand > > > > > > the > > > > > > scope of the reset. Is it worth it? What do we really gain? > > > > > > > > > > Jason raised the concern whether GET_PCI_HOT_RESET_INFO is actually > > > > > useful today. > > > > > > > > > > It's an interface on opened device. So the tiny difference is whether > > > > > the > > > > > user knows the device is resettable when calling GET_INFO or later > > when > > > > > actually calling PCI_HOT_RESET. > > > > > > > > No, GET_PCI_HOT_RESET_INFO conveys not only whether a > > PCI_HOT_RESET > > > > can > > > > be performed, but equally important the scope of the reset, ie. which > > > > devices are affected by the reset. If we de-emphasize the INFO > > > > portion, then this easily gets confused as just a variant of > > > > VFIO_DEVICE_RESET, which is explicitly a device-level cscope reset. In > > > > fact, I'd say the interface is not only trying to validate that the > > > > user has sufficient privileges for the reset, but that they explicitly > > > > acknowledge the scope of the reset. > > > > > > > > > > IMHO the usefulness of scope is if it's discoverable by the management > > > stack which then can try to assign devices with affected reset to a same > > > user. > > > > Disagree, the user needs to know the scope of reset. Take for instance > > two function of a device configured onto separate buses within a VM. > > The VMM needs to know that a hot-reset of one will reset the other. > > That's not obvious to the VMM without some understanding of PCI/e > > topology and analysis of the host system. The info ioctl simplifies > > that discovery for the VMM and the handshake of passing the affected > > groups makes sure that the info ioctl remains relevant. > > If that is the intended usage then I don't see why this proposal will > promote userspace to ignore the _INFO ioctl. It should be always > queried no matter how the reset ioctl itself is designed. The motivation > of calling _INFO is not from the reset ioctl asking for an array of fds. The VFIO_DEVICE_PCI_HOT_RESET ioctl requires a set of group (or cdev) fds that encompass the set of affected devices reported by the VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl, so I don't agree with the last sentence above. This proposal seems to be based on some confusion about the difference between VFIO_DEVICE_RESET and VFIO_DEVICE_PCI_HOT_RESET, and therefore IMO, proliferates that confusion by making the scope argument optional, which I see as a key difference. This therefore makes the behavior of the ioctl less intuitive, easier to get wrong, and I expect we'll see users unitentionally resetting devices beyond the desired scope if the group/device fd array is allowed to be empty. Thanks, Alex
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Thu, Mar 16, 2023 at 11:59 PM Rob Clark wrote: > > On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick > wrote: > > > > On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote: > > > > > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > > > > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming > > > > > > > > > deadline, such as > > > > > > > > > vblank, which the fence waiter would prefer not to miss. > > > > > > > > > This is to aid > > > > > > > > > the fence signaler in making power management decisions, like > > > > > > > > > boosting > > > > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > > > > deadlines > > > > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter > > > > > > > > > duplicate > > > > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > > > > fence-context > > > > > > > > > implementation will need similar logic to track deadlines > > > > > > > > > of all > > > > > > > > > the fences on the same timeline. [ckoenig] > > > > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > > > > v6: More docs > > > > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > > > Reviewed-by: Christian König > > > > > > > > > Acked-by: Pekka Paalanen > > > > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > > > > --- > > > > > > > > > > > > > > > > Hi Rob! > > > > > > > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > > > > + > > > > > > > > > + > > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > > + :doc: deadline hints > > > > > > > > > + > > > > > > > > > DMA Fences Functions Reference > > > > > > > > > ~~ > > > > > > > > > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c > > > > > > > > > b/drivers/dma-buf/dma-fence.c > > > > > > > > > index 0de0482cd36e..f177c56269bb 100644 > > > > > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct > > > > > > > > > dma_fence **fences, uint32_t count, > > > > > > > > > } > > > > > > > > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > > > > > > > > > > > > > > > +/** > > > > > > > > > + * DOC: deadline hints > > > > > > > > > + * > > > > > > > > > + * In an ideal world, it would be possible to pipeline a > > > > > > > > > workload sufficiently > > > > > > > > > + * that a utilization based device frequency governor could > > > > > > > > > arrive at a minimum > > > > > > > > > + * frequency that meets the requirements of the use-case, in > > > > > > > > > order to minimize > > > > > > > > > + * power consumption. But in the real world there are many > > > > > > > > > workloads which > > > > > > > > > + * defy this ideal. For example, but not limited to: > > > > > > > > > + * > > > > > > > > > + * * Workloads that ping-pong between device and CPU, with > > > > > > > > > alternating periods > > > > > > > > > + * of CPU waiting for device, and device waiting on CPU. > > > > > > > > > This can result in > > > > > > > > > + * devfreq and cpufreq seeing idle time in their > > > > > > > > > respective domains and in > > > > > > > > > + * result reduce frequency. > > > > > > > > > + * > > > > > > > > > + * * Workloads that interact with a periodic time based > > > > > > > > > deadline,
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/psr: Implement Wa_1136
On Fri, Mar 17, 2023 at 01:04:37PM +0200, Jouni Högander wrote:
> Implement Wa_1136 for SKL/BXT/ICL.
>
> Bspec: 21664
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 15 +++
> drivers/gpu/drm/i915/display/skl_watermark.c | 5 -
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a385cb8dbf13..e6bd46441392 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1049,6 +1049,13 @@ void intel_psr_compute_config(struct intel_dp
> *intel_dp,
> return;
> }
>
> + /* Wa_1136 */
The syntax we've used for the old w/as is different.
> + if (DISPLAY_VER(dev_priv) < 12 && crtc_state->wm_level_disabled) {
This won't have been calculated yet.
As for the platform check. I think the one hsd we still have left
indicates that icl already got some kind of full fix. So probably
that should at least be safe. And I do think the KBL+ should also
work fine.
But we could do that as followups:
1. do this
2. switch to the chicken bit approach for icl
3. switch to the chicken bit approach for kbl+
Then of any issue later come up that point to a problem
with the chicken bits we could more easily revert to full
psr disable.
> + drm_dbg_kms(&dev_priv->drm,
> + "PSR condition failed: WM level disabled and no HW
> WA available\n");
> + return;
> + }
> +
> crtc_state->has_psr = true;
> crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
>
> @@ -1260,6 +1267,10 @@ static void intel_psr_enable_locked(struct intel_dp
> *intel_dp,
>
> drm_WARN_ON(&dev_priv->drm, intel_dp->psr.enabled);
>
> + /* Wa_1136 */
> + if (DISPLAY_VER(dev_priv) < 12 && crtc_state->wm_level_disabled)
It's a bit weird to handle this differently than the active_planes case.
Though the fact that the pre and post updatre hooks also do things
in different ways is also confusing. Seems to me some general cleanup
in this area could be worthwile.
> + return;
> +
> intel_dp->psr.psr2_enabled = crtc_state->has_psr2;
> intel_dp->psr.busy_frontbuffer_bits = 0;
> intel_dp->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
> @@ -1940,6 +1951,10 @@ void intel_psr_pre_plane_update(struct
> intel_atomic_state *state,
> needs_to_disable |= !new_crtc_state->active_planes;
> needs_to_disable |= new_crtc_state->has_psr2 !=
> psr->psr2_enabled;
>
> + /* Wa_1136 */
> + needs_to_disable |= DISPLAY_VER(i915) < 12 &&
> + new_crtc_state->wm_level_disabled;
> +
> if (psr->enabled && needs_to_disable)
> intel_psr_disable_locked(intel_dp);
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index afb751c024ba..ced61da8b496 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -2278,11 +2278,6 @@ static int skl_wm_check_vblank(struct intel_crtc_state
> *crtc_state)
>*/
> crtc_state->wm_level_disabled = level < i915->display.wm.num_levels - 1;
>
> - /*
> - * FIXME also related to skl+ w/a 1136 (also unimplemented as of
> - * now) perhaps?
> - */
> -
> for (level++; level < i915->display.wm.num_levels; level++) {
> enum plane_id plane_id;
>
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
On Fri, Mar 17, 2023 at 04:30:37PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 17, 2023 at 03:37:09PM +0200, Jani Nikula wrote:
> > On Fri, 17 Mar 2023, Ville Syrjälä wrote:
> > > On Fri, Mar 17, 2023 at 02:53:52PM +0200, Jani Nikula wrote:
> > >> The pipe may differ from crtc index if pipes are fused off. For testing
> > >> purposes, IGT needs to know the pipe.
> > >>
> > >> There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
> > >> the upcoming Xe driver won't have that IOCTL, and going forward, we'll
> > >> want a unified interface for testing i915 and Xe, as they share the
> > >> display code. Thus add the debugfs for i915 display.
> > >>
> > >> Signed-off-by: Jani Nikula
> > >> ---
> > >> .../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
> > >> 1 file changed, 13 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > >> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > >> index faa44fb80aac..e85270adca95 100644
> > >> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > >> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > >> @@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file
> > >> *m, void *data)
> > >> }
> > >> DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
> > >>
> > >> +/* Pipe may differ from crtc index if pipes are fused off */
> > >> +static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
> > >> +{
> > >> +struct intel_crtc *crtc = m->private;
> > >> +
> > >> +seq_printf(m, "%d\n", crtc->pipe);
> > >
> > > Are we happy with an integer or should we use the actual alphabetic
> > > name here?
> >
> > Primarily I considered the programmatic use case, and the ease of
> > switching over from the ioctl. What do we gain by making IGT parse this?
>
> Well even the integer is represented in ascii so parsing
> needs to happen anyway. But I was mainly thinking if any
> human looks at it they may be confused as to what the
> raw integer even means.
Eg. if I just jump on some random machine an do
# grep . crtc-1/*
...
i915_pipe: 3
...
Now I need to most likely count with my fingers
to figure out I'm actually looking at pipe D :P
>
> >
> > > Either way, the series is:
> > > Reviewed-by: Ville Syrjälä
> >
> > Thanks,
> > Jani.
> >
> > >
> > >> +
> > >> +return 0;
> > >> +}
> > >> +DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
> > >> +
> > >> /**
> > >> * intel_connector_debugfs_add - add i915 specific connector debugfs
> > >> files
> > >> * @connector: pointer to a registered drm_connector
> > >> @@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc
> > >> *crtc)
> > >>
> > >> debugfs_create_file("i915_current_bpc", 0444, root, crtc,
> > >> &i915_current_bpc_fops);
> > >> +debugfs_create_file("i915_pipe", 0444, root, crtc,
> > >> +&intel_crtc_pipe_fops);
> > >> }
> > >> --
> > >> 2.39.2
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
On Fri, Mar 17, 2023 at 03:37:09PM +0200, Jani Nikula wrote:
> On Fri, 17 Mar 2023, Ville Syrjälä wrote:
> > On Fri, Mar 17, 2023 at 02:53:52PM +0200, Jani Nikula wrote:
> >> The pipe may differ from crtc index if pipes are fused off. For testing
> >> purposes, IGT needs to know the pipe.
> >>
> >> There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
> >> the upcoming Xe driver won't have that IOCTL, and going forward, we'll
> >> want a unified interface for testing i915 and Xe, as they share the
> >> display code. Thus add the debugfs for i915 display.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> .../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> index faa44fb80aac..e85270adca95 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >> @@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file
> >> *m, void *data)
> >> }
> >> DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
> >>
> >> +/* Pipe may differ from crtc index if pipes are fused off */
> >> +static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
> >> +{
> >> + struct intel_crtc *crtc = m->private;
> >> +
> >> + seq_printf(m, "%d\n", crtc->pipe);
> >
> > Are we happy with an integer or should we use the actual alphabetic
> > name here?
>
> Primarily I considered the programmatic use case, and the ease of
> switching over from the ioctl. What do we gain by making IGT parse this?
Well even the integer is represented in ascii so parsing
needs to happen anyway. But I was mainly thinking if any
human looks at it they may be confused as to what the
raw integer even means.
>
> > Either way, the series is:
> > Reviewed-by: Ville Syrjälä
>
> Thanks,
> Jani.
>
> >
> >> +
> >> + return 0;
> >> +}
> >> +DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
> >> +
> >> /**
> >> * intel_connector_debugfs_add - add i915 specific connector debugfs files
> >> * @connector: pointer to a registered drm_connector
> >> @@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
> >>
> >>debugfs_create_file("i915_current_bpc", 0444, root, crtc,
> >>&i915_current_bpc_fops);
> >> + debugfs_create_file("i915_pipe", 0444, root, crtc,
> >> + &intel_crtc_pipe_fops);
> >> }
> >> --
> >> 2.39.2
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH 3/3] drm/i915/psr: clean up PSR debugfs sink status error handling
Handle errors first and return early, and reduce indentation on the
happy day code path.
Cc: Jouni Högander
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_psr.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index bd1a1a2524b5..31084d95711d 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2891,6 +2891,7 @@ static int i915_psr_sink_status_show(struct seq_file *m,
void *data)
"reserved",
"sink internal error",
};
+ const char *str;
int ret;
u8 val;
@@ -2903,17 +2904,16 @@ static int i915_psr_sink_status_show(struct seq_file
*m, void *data)
return -ENODEV;
ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val);
+ if (ret != 1)
+ return ret < 0 ? ret : -EIO;
- if (ret == 1) {
- const char *str = "unknown";
+ val &= DP_PSR_SINK_STATE_MASK;
+ if (val < ARRAY_SIZE(sink_status))
+ str = sink_status[val];
+ else
+ str = "unknown";
- val &= DP_PSR_SINK_STATE_MASK;
- if (val < ARRAY_SIZE(sink_status))
- str = sink_status[val];
- seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val, str);
- } else {
- return ret;
- }
+ seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val, str);
return 0;
}
--
2.39.2
[Intel-gfx] [PATCH 2/3] drm/i915/psr: switch PSR debugfs to struct intel_connector
Prefer struct intel_connector over struct drm_connector.
Cc: Jouni Högander
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_psr.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9d3205d99b54..bd1a1a2524b5 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2879,7 +2879,8 @@ void intel_psr_debugfs_register(struct drm_i915_private
*i915)
static int i915_psr_sink_status_show(struct seq_file *m, void *data)
{
- u8 val;
+ struct intel_connector *connector = m->private;
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
static const char * const sink_status[] = {
"inactive",
"transition to active, capture and display",
@@ -2890,17 +2891,15 @@ static int i915_psr_sink_status_show(struct seq_file
*m, void *data)
"reserved",
"sink internal error",
};
- struct drm_connector *connector = m->private;
- struct intel_dp *intel_dp =
- intel_attached_dp(to_intel_connector(connector));
int ret;
+ u8 val;
if (!CAN_PSR(intel_dp)) {
seq_puts(m, "PSR Unsupported\n");
return -ENODEV;
}
- if (connector->status != connector_status_connected)
+ if (connector->base.status != connector_status_connected)
return -ENODEV;
ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val);
@@ -2922,21 +2921,19 @@ DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
static int i915_psr_status_show(struct seq_file *m, void *data)
{
- struct drm_connector *connector = m->private;
- struct intel_dp *intel_dp =
- intel_attached_dp(to_intel_connector(connector));
+ struct intel_connector *connector = m->private;
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
return intel_psr_status(m, intel_dp);
}
DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
-void intel_psr_connector_debugfs_add(struct intel_connector *intel_connector)
+void intel_psr_connector_debugfs_add(struct intel_connector *connector)
{
- struct drm_connector *connector = &intel_connector->base;
- struct drm_i915_private *i915 = to_i915(connector->dev);
- struct dentry *root = connector->debugfs_entry;
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct dentry *root = connector->base.debugfs_entry;
- if (connector->connector_type != DRM_MODE_CONNECTOR_eDP)
+ if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
return;
debugfs_create_file("i915_psr_sink_status", 0444, root,
--
2.39.2
[Intel-gfx] [PATCH 1/3] drm/i915/psr: move PSR debugfs to intel_psr.c
Move the debugfs next to the implementation.
Cc: Jouni Högander
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 288 +
drivers/gpu/drm/i915/display/intel_psr.c | 302 ++
drivers/gpu/drm/i915/display/intel_psr.h | 3 +
3 files changed, 308 insertions(+), 285 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 65585f19c6c8..4d8ebf3fed11 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -142,269 +142,6 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
return 0;
}
-static int i915_psr_sink_status_show(struct seq_file *m, void *data)
-{
- u8 val;
- static const char * const sink_status[] = {
- "inactive",
- "transition to active, capture and display",
- "active, display from RFB",
- "active, capture and display on sink device timings",
- "transition to inactive, capture and display, timing re-sync",
- "reserved",
- "reserved",
- "sink internal error",
- };
- struct drm_connector *connector = m->private;
- struct intel_dp *intel_dp =
- intel_attached_dp(to_intel_connector(connector));
- int ret;
-
- if (!CAN_PSR(intel_dp)) {
- seq_puts(m, "PSR Unsupported\n");
- return -ENODEV;
- }
-
- if (connector->status != connector_status_connected)
- return -ENODEV;
-
- ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val);
-
- if (ret == 1) {
- const char *str = "unknown";
-
- val &= DP_PSR_SINK_STATE_MASK;
- if (val < ARRAY_SIZE(sink_status))
- str = sink_status[val];
- seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val, str);
- } else {
- return ret;
- }
-
- return 0;
-}
-DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
-
-static void
-psr_source_status(struct intel_dp *intel_dp, struct seq_file *m)
-{
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- const char *status = "unknown";
- u32 val, status_val;
-
- if (intel_dp->psr.psr2_enabled) {
- static const char * const live_status[] = {
- "IDLE",
- "CAPTURE",
- "CAPTURE_FS",
- "SLEEP",
- "BUFON_FW",
- "ML_UP",
- "SU_STANDBY",
- "FAST_SLEEP",
- "DEEP_SLEEP",
- "BUF_ON",
- "TG_ON"
- };
- val = intel_de_read(dev_priv,
- EDP_PSR2_STATUS(intel_dp->psr.transcoder));
- status_val = REG_FIELD_GET(EDP_PSR2_STATUS_STATE_MASK, val);
- if (status_val < ARRAY_SIZE(live_status))
- status = live_status[status_val];
- } else {
- static const char * const live_status[] = {
- "IDLE",
- "SRDONACK",
- "SRDENT",
- "BUFOFF",
- "BUFON",
- "AUXACK",
- "SRDOFFACK",
- "SRDENT_ON",
- };
- val = intel_de_read(dev_priv,
- EDP_PSR_STATUS(intel_dp->psr.transcoder));
- status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
- EDP_PSR_STATUS_STATE_SHIFT;
- if (status_val < ARRAY_SIZE(live_status))
- status = live_status[status_val];
- }
-
- seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
-}
-
-static int intel_psr_status(struct seq_file *m, struct intel_dp *intel_dp)
-{
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- struct intel_psr *psr = &intel_dp->psr;
- intel_wakeref_t wakeref;
- const char *status;
- bool enabled;
- u32 val;
-
- seq_printf(m, "Sink support: %s", str_yes_no(psr->sink_support));
- if (psr->sink_support)
- seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
- seq_puts(m, "\n");
-
- if (!psr->sink_support)
- return 0;
-
- wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
- mutex_lock(&psr->lock);
-
- if (psr->enabled)
- status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1 enabled";
- else
- status = "disabled";
- seq_printf(m, "PSR mode: %s\n", status);
-
- if (!psr->enabled) {
- seq_printf(m, "PSR sink not reliable: %s\n",
-
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
On Fri, 17 Mar 2023, Ville Syrjälä wrote:
> On Fri, Mar 17, 2023 at 02:53:52PM +0200, Jani Nikula wrote:
>> The pipe may differ from crtc index if pipes are fused off. For testing
>> purposes, IGT needs to know the pipe.
>>
>> There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
>> the upcoming Xe driver won't have that IOCTL, and going forward, we'll
>> want a unified interface for testing i915 and Xe, as they share the
>> display code. Thus add the debugfs for i915 display.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> .../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> index faa44fb80aac..e85270adca95 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> @@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file *m,
>> void *data)
>> }
>> DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
>>
>> +/* Pipe may differ from crtc index if pipes are fused off */
>> +static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
>> +{
>> +struct intel_crtc *crtc = m->private;
>> +
>> +seq_printf(m, "%d\n", crtc->pipe);
>
> Are we happy with an integer or should we use the actual alphabetic
> name here?
Primarily I considered the programmatic use case, and the ease of
switching over from the ioctl. What do we gain by making IGT parse this?
> Either way, the series is:
> Reviewed-by: Ville Syrjälä
Thanks,
Jani.
>
>> +
>> +return 0;
>> +}
>> +DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
>> +
>> /**
>> * intel_connector_debugfs_add - add i915 specific connector debugfs files
>> * @connector: pointer to a registered drm_connector
>> @@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
>>
>> debugfs_create_file("i915_current_bpc", 0444, root, crtc,
>> &i915_current_bpc_fops);
>> +debugfs_create_file("i915_pipe", 0444, root, crtc,
>> +&intel_crtc_pipe_fops);
>> }
>> --
>> 2.39.2
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
On Fri, Mar 17, 2023 at 02:53:52PM +0200, Jani Nikula wrote:
> The pipe may differ from crtc index if pipes are fused off. For testing
> purposes, IGT needs to know the pipe.
>
> There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
> the upcoming Xe driver won't have that IOCTL, and going forward, we'll
> want a unified interface for testing i915 and Xe, as they share the
> display code. Thus add the debugfs for i915 display.
>
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index faa44fb80aac..e85270adca95 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file *m,
> void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
>
> +/* Pipe may differ from crtc index if pipes are fused off */
> +static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
> +{
> + struct intel_crtc *crtc = m->private;
> +
> + seq_printf(m, "%d\n", crtc->pipe);
Are we happy with an integer or should we use the actual alphabetic
name here?
Either way, the series is:
Reviewed-by: Ville Syrjälä
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
> +
> /**
> * intel_connector_debugfs_add - add i915 specific connector debugfs files
> * @connector: pointer to a registered drm_connector
> @@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
>
> debugfs_create_file("i915_current_bpc", 0444, root, crtc,
> &i915_current_bpc_fops);
> + debugfs_create_file("i915_pipe", 0444, root, crtc,
> + &intel_crtc_pipe_fops);
> }
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v3 1/2] drm: Introduce plane SIZE_HINTS property
On Fri, Mar 17, 2023 at 03:15:56PM +0200, Ville Syrjälä wrote: > On Fri, Mar 17, 2023 at 01:29:13PM +0100, Jonas Ådahl wrote: > > On Fri, Mar 17, 2023 at 01:21:43PM +0100, Jonas Ådahl wrote: > > > On Fri, Mar 17, 2023 at 01:33:25PM +0200, Ville Syrjälä wrote: > > > > On Fri, Mar 17, 2023 at 11:34:16AM +0100, Jonas Ådahl wrote: > > > > > On Mon, Mar 13, 2023 at 06:33:11PM +0200, Ville Syrjala wrote: > > > > > > From: Ville Syrjälä > > > > > > > > > > > > Add a new immutable plane property by which a plane can advertise > > > > > > a handful of recommended plane sizes. This would be mostly exposed > > > > > > by cursor planes as a slightly more capable replacement for > > > > > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > > > > > a one size fits all limit for the whole device. > > > > > > > > > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > > > > > size via the cursor size caps. But always using the max sized > > > > > > cursor can waste a surprising amount of power, so a better > > > > > > stragey is desirable. > > > > > > > > > > > > Most other drivers don't specify any cursor size at all, in > > > > > > which case the ioctl code just claims that 64x64 is a great > > > > > > choice. Whether that is actually true is debatable. > > > > > > > > > > > > A poll of various compositor developers informs us that > > > > > > blindly probing with setcursor/atomic ioctl to determine > > > > > > suitable cursor sizes is not acceptable, thus the > > > > > > introduction of the new property to supplant the cursor > > > > > > size caps. The compositor will now be free to select a > > > > > > more optimal cursor size from the short list of options. > > > > > > > > > > > > Note that the reported sizes (either via the property or the > > > > > > caps) make no claims about things such as plane scaling. So > > > > > > these things should only really be consulted for simple > > > > > > "cursor like" use cases. > > > > > > > > > > > > v2: Try to add some docs > > > > > > v3: Specify that value 0 is reserved for future use (basic idea > > > > > > from Jonas) > > > > > > Drop the note about typical hardware (Pekka) > > > > > > > > > > > > Cc: Simon Ser > > > > > > Cc: Jonas Ådahl > > > > > > Cc: Daniel Stone > > > > > > Cc: Pekka Paalanen > > > > > > Acked-by: Harry Wentland > > > > > > Acked-by: Pekka Paalanen > > > > > > Signed-off-by: Ville Syrjälä > > > > > > --- > > > > > > drivers/gpu/drm/drm_mode_config.c | 7 > > > > > > drivers/gpu/drm/drm_plane.c | 53 > > > > > > +++ > > > > > > include/drm/drm_mode_config.h | 5 +++ > > > > > > include/drm/drm_plane.h | 4 +++ > > > > > > include/uapi/drm/drm_mode.h | 11 +++ > > > > > > 5 files changed, 80 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > > > > > b/drivers/gpu/drm/drm_mode_config.c > > > > > > index 87eb591fe9b5..21860f94a18c 100644 > > > > > > --- a/drivers/gpu/drm/drm_mode_config.c > > > > > > +++ b/drivers/gpu/drm/drm_mode_config.c > > > > > > @@ -374,6 +374,13 @@ static int > > > > > > drm_mode_create_standard_properties(struct drm_device *dev) > > > > > > return -ENOMEM; > > > > > > dev->mode_config.modifiers_property = prop; > > > > > > > > > > > > + prop = drm_property_create(dev, > > > > > > + DRM_MODE_PROP_IMMUTABLE | > > > > > > DRM_MODE_PROP_BLOB, > > > > > > + "SIZE_HINTS", 0); > > > > > > + if (!prop) > > > > > > + return -ENOMEM; > > > > > > + dev->mode_config.size_hints_property = prop; > > > > > > + > > > > > > return 0; > > > > > > } > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c > > > > > > b/drivers/gpu/drm/drm_plane.c > > > > > > index 24e7998d1731..d2a6fdff1a57 100644 > > > > > > --- a/drivers/gpu/drm/drm_plane.c > > > > > > +++ b/drivers/gpu/drm/drm_plane.c > > > > > > @@ -140,6 +140,26 @@ > > > > > > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 > > > > > > there have been > > > > > > * various bugs in this area with inconsistencies between the > > > > > > capability > > > > > > * flag and per-plane properties. > > > > > > + * > > > > > > + * SIZE_HINTS: > > > > > > + * Blob property which contains the set of recommended plane > > > > > > size > > > > > > + * which can used for simple "cursor like" use cases (eg. no > > > > > > scaling). > > > > > > + * Using these hints frees userspace from extensive probing of > > > > > > + * supported plane sizes through atomic/setcursor ioctls. > > > > > > + * > > > > > > + * For optimal usage userspace should pick the smallest size > > > > > > + * that satisfies its own requirements. > > > > > > + * > > > > > > + * The blob contains an array of struct drm_plane_size_hint. > > > > > > + * > > > > > > + * Drivers should only attach this property to pl
Re: [Intel-gfx] [PATCH v3 1/2] drm: Introduce plane SIZE_HINTS property
On Fri, Mar 17, 2023 at 01:29:13PM +0100, Jonas Ådahl wrote: > On Fri, Mar 17, 2023 at 01:21:43PM +0100, Jonas Ådahl wrote: > > On Fri, Mar 17, 2023 at 01:33:25PM +0200, Ville Syrjälä wrote: > > > On Fri, Mar 17, 2023 at 11:34:16AM +0100, Jonas Ådahl wrote: > > > > On Mon, Mar 13, 2023 at 06:33:11PM +0200, Ville Syrjala wrote: > > > > > From: Ville Syrjälä > > > > > > > > > > Add a new immutable plane property by which a plane can advertise > > > > > a handful of recommended plane sizes. This would be mostly exposed > > > > > by cursor planes as a slightly more capable replacement for > > > > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > > > > a one size fits all limit for the whole device. > > > > > > > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > > > > size via the cursor size caps. But always using the max sized > > > > > cursor can waste a surprising amount of power, so a better > > > > > stragey is desirable. > > > > > > > > > > Most other drivers don't specify any cursor size at all, in > > > > > which case the ioctl code just claims that 64x64 is a great > > > > > choice. Whether that is actually true is debatable. > > > > > > > > > > A poll of various compositor developers informs us that > > > > > blindly probing with setcursor/atomic ioctl to determine > > > > > suitable cursor sizes is not acceptable, thus the > > > > > introduction of the new property to supplant the cursor > > > > > size caps. The compositor will now be free to select a > > > > > more optimal cursor size from the short list of options. > > > > > > > > > > Note that the reported sizes (either via the property or the > > > > > caps) make no claims about things such as plane scaling. So > > > > > these things should only really be consulted for simple > > > > > "cursor like" use cases. > > > > > > > > > > v2: Try to add some docs > > > > > v3: Specify that value 0 is reserved for future use (basic idea from > > > > > Jonas) > > > > > Drop the note about typical hardware (Pekka) > > > > > > > > > > Cc: Simon Ser > > > > > Cc: Jonas Ådahl > > > > > Cc: Daniel Stone > > > > > Cc: Pekka Paalanen > > > > > Acked-by: Harry Wentland > > > > > Acked-by: Pekka Paalanen > > > > > Signed-off-by: Ville Syrjälä > > > > > --- > > > > > drivers/gpu/drm/drm_mode_config.c | 7 > > > > > drivers/gpu/drm/drm_plane.c | 53 > > > > > +++ > > > > > include/drm/drm_mode_config.h | 5 +++ > > > > > include/drm/drm_plane.h | 4 +++ > > > > > include/uapi/drm/drm_mode.h | 11 +++ > > > > > 5 files changed, 80 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > > > > b/drivers/gpu/drm/drm_mode_config.c > > > > > index 87eb591fe9b5..21860f94a18c 100644 > > > > > --- a/drivers/gpu/drm/drm_mode_config.c > > > > > +++ b/drivers/gpu/drm/drm_mode_config.c > > > > > @@ -374,6 +374,13 @@ static int > > > > > drm_mode_create_standard_properties(struct drm_device *dev) > > > > > return -ENOMEM; > > > > > dev->mode_config.modifiers_property = prop; > > > > > > > > > > + prop = drm_property_create(dev, > > > > > +DRM_MODE_PROP_IMMUTABLE | > > > > > DRM_MODE_PROP_BLOB, > > > > > +"SIZE_HINTS", 0); > > > > > + if (!prop) > > > > > + return -ENOMEM; > > > > > + dev->mode_config.size_hints_property = prop; > > > > > + > > > > > return 0; > > > > > } > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > > > > index 24e7998d1731..d2a6fdff1a57 100644 > > > > > --- a/drivers/gpu/drm/drm_plane.c > > > > > +++ b/drivers/gpu/drm/drm_plane.c > > > > > @@ -140,6 +140,26 @@ > > > > > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there > > > > > have been > > > > > * various bugs in this area with inconsistencies between the > > > > > capability > > > > > * flag and per-plane properties. > > > > > + * > > > > > + * SIZE_HINTS: > > > > > + * Blob property which contains the set of recommended plane size > > > > > + * which can used for simple "cursor like" use cases (eg. no > > > > > scaling). > > > > > + * Using these hints frees userspace from extensive probing of > > > > > + * supported plane sizes through atomic/setcursor ioctls. > > > > > + * > > > > > + * For optimal usage userspace should pick the smallest size > > > > > + * that satisfies its own requirements. > > > > > + * > > > > > + * The blob contains an array of struct drm_plane_size_hint. > > > > > + * > > > > > + * Drivers should only attach this property to planes that > > > > > + * support a very limited set of sizes. > > > > > + * > > > > > + * Note that property value 0 (ie. no blob) is reserved for > > > > > potential > > > > > + * future use. Current userspace is expected to ignore the > > > > > property >
Re: [Intel-gfx] [PATCH v3 1/2] drm: Introduce plane SIZE_HINTS property
On Fri, Mar 17, 2023 at 01:21:40PM +0100, Jonas Ådahl wrote: > On Fri, Mar 17, 2023 at 01:33:25PM +0200, Ville Syrjälä wrote: > > On Fri, Mar 17, 2023 at 11:34:16AM +0100, Jonas Ådahl wrote: > > > On Mon, Mar 13, 2023 at 06:33:11PM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > Add a new immutable plane property by which a plane can advertise > > > > a handful of recommended plane sizes. This would be mostly exposed > > > > by cursor planes as a slightly more capable replacement for > > > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > > > a one size fits all limit for the whole device. > > > > > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > > > size via the cursor size caps. But always using the max sized > > > > cursor can waste a surprising amount of power, so a better > > > > stragey is desirable. > > > > > > > > Most other drivers don't specify any cursor size at all, in > > > > which case the ioctl code just claims that 64x64 is a great > > > > choice. Whether that is actually true is debatable. > > > > > > > > A poll of various compositor developers informs us that > > > > blindly probing with setcursor/atomic ioctl to determine > > > > suitable cursor sizes is not acceptable, thus the > > > > introduction of the new property to supplant the cursor > > > > size caps. The compositor will now be free to select a > > > > more optimal cursor size from the short list of options. > > > > > > > > Note that the reported sizes (either via the property or the > > > > caps) make no claims about things such as plane scaling. So > > > > these things should only really be consulted for simple > > > > "cursor like" use cases. > > > > > > > > v2: Try to add some docs > > > > v3: Specify that value 0 is reserved for future use (basic idea from > > > > Jonas) > > > > Drop the note about typical hardware (Pekka) > > > > > > > > Cc: Simon Ser > > > > Cc: Jonas Ådahl > > > > Cc: Daniel Stone > > > > Cc: Pekka Paalanen > > > > Acked-by: Harry Wentland > > > > Acked-by: Pekka Paalanen > > > > Signed-off-by: Ville Syrjälä > > > > --- > > > > drivers/gpu/drm/drm_mode_config.c | 7 > > > > drivers/gpu/drm/drm_plane.c | 53 +++ > > > > include/drm/drm_mode_config.h | 5 +++ > > > > include/drm/drm_plane.h | 4 +++ > > > > include/uapi/drm/drm_mode.h | 11 +++ > > > > 5 files changed, 80 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > > > b/drivers/gpu/drm/drm_mode_config.c > > > > index 87eb591fe9b5..21860f94a18c 100644 > > > > --- a/drivers/gpu/drm/drm_mode_config.c > > > > +++ b/drivers/gpu/drm/drm_mode_config.c > > > > @@ -374,6 +374,13 @@ static int > > > > drm_mode_create_standard_properties(struct drm_device *dev) > > > > return -ENOMEM; > > > > dev->mode_config.modifiers_property = prop; > > > > > > > > + prop = drm_property_create(dev, > > > > + DRM_MODE_PROP_IMMUTABLE | > > > > DRM_MODE_PROP_BLOB, > > > > + "SIZE_HINTS", 0); > > > > + if (!prop) > > > > + return -ENOMEM; > > > > + dev->mode_config.size_hints_property = prop; > > > > + > > > > return 0; > > > > } > > > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > > > index 24e7998d1731..d2a6fdff1a57 100644 > > > > --- a/drivers/gpu/drm/drm_plane.c > > > > +++ b/drivers/gpu/drm/drm_plane.c > > > > @@ -140,6 +140,26 @@ > > > > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there > > > > have been > > > > * various bugs in this area with inconsistencies between the > > > > capability > > > > * flag and per-plane properties. > > > > + * > > > > + * SIZE_HINTS: > > > > + * Blob property which contains the set of recommended plane size > > > > + * which can used for simple "cursor like" use cases (eg. no > > > > scaling). > > > > + * Using these hints frees userspace from extensive probing of > > > > + * supported plane sizes through atomic/setcursor ioctls. > > > > + * > > > > + * For optimal usage userspace should pick the smallest size > > > > + * that satisfies its own requirements. > > > > + * > > > > + * The blob contains an array of struct drm_plane_size_hint. > > > > + * > > > > + * Drivers should only attach this property to planes that > > > > + * support a very limited set of sizes. > > > > + * > > > > + * Note that property value 0 (ie. no blob) is reserved for > > > > potential > > > > + * future use. Current userspace is expected to ignore the property > > > > + * if the value is 0, and fall back to some other means (eg. > > > > + * &DRM_CAP_CURSOR_WIDTH and &DRM_CAP_CURSOR_HEIGHT) to determine > > > > + * the appropriate plane size to use. > > > > > > Does this intend to mean userspace has the kernel's bles
Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC
On Thu, Mar 16, 2023 at 01:58:35PM -0700, John Harrison wrote:
> On 3/15/2023 10:57, Greg KH wrote:
> > On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
> > > On 3/15/2023 00:51, Greg KH wrote:
> > > > On Mon, Mar 13, 2023 at 07:22:11PM -0700, john.c.harri...@intel.com
> > > > wrote:
> > > > > From: John Harrison
> > > > >
> > > > > Direction from hardware is that ring buffers should never be mapped
> > > > > via the BAR on systems with LLC. There are too many caching pitfalls
> > > > > due to the way BAR accesses are routed. So it is safest to just not
> > > > > use it.
> > > > >
> > > > > Signed-off-by: John Harrison
> > > > > Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound
> > > > > anywhere")
> > > > > Cc: Chris Wilson
> > > > > Cc: Joonas Lahtinen
> > > > > Cc: Jani Nikula
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Tvrtko Ursulin
> > > > > Cc: intel-gfx@lists.freedesktop.org
> > > > > Cc: # v4.9+
> > > > > Tested-by: Jouni Högander
> > > > > Reviewed-by: Daniele Ceraolo Spurio
> > > > > Link:
> > > > > https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
> > > > > (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> > > > > Signed-off-by: Jani Nikula
> > > > > (cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
> > > > > Signed-off-by: John Harrison
> > > > > ---
> > > > >drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
> > > > >1 file changed, 2 insertions(+), 2 deletions(-)
> > > > Also queued up for 5.10.y, you forgot that one :)
> > > I'm still working through the backlog of them.
> > >
> > > Note that these patches must all be applied as a pair. The 'don't use
> > > stolen' can be applied in isolation but won't totally fix the problem.
> > > However, applying 'don't use BAR mappings' without applying the stolen
> > > patch
> > > first will results in problems such as the failure to boot that was
> > > recently
> > > reported and resulted in a revert in one of the trees.
> > I do not understand, you only submitted 1 patch here, what is the
> > "pair"?
> The original patch series was two patches -
> https://patchwork.freedesktop.org/series/114080/. One to not use stolen
> memory and the other to not use BAR mappings. If the anti-BAR patch is
> applied without the anti-stolen patch then the i915 driver will attempt to
> access stolen memory directly which will fail. So both patches must be
> applied and in the correct order to fix the problem of cache aliasing when
> using BAR accesses on LLC systems.
>
> As above, I am working my way through the bunch of 'FAILED patch' emails.
> The what-to-do instructions in those emails explicitly say to send the patch
> individually in reply to the 'FAILED' message rather than as part of any
> original series.
So what commits exactly in Linus's tree should be in these stable
branches? Sorry, I still do not understand if we are missing one or if
we need to revert something.
confused,
greg k-h
Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Fix Wa_16013835468 and Wa_14015648006
On Fri, 2023-03-17 at 14:33 +0200, Ville Syrjälä wrote:
> On Fri, Mar 17, 2023 at 06:54:02AM +, Hogander, Jouni wrote:
> > On Thu, 2023-03-16 at 20:21 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 14, 2023 at 11:01:41AM +0200, Jouni Högander wrote:
> > > > PSR WM optimization should be disabled based on any wm level
> > > > being
> > > > disabled. Currently it's disabled always when using delayed
> > > > vblank.
> > > >
> > > > Bspec: 71580
> > > >
> > > > Signed-off-by: Jouni Högander
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> > > > drivers/gpu/drm/i915/display/intel_psr.c | 12 +-
> > > >
> > > > --
> > > > drivers/gpu/drm/i915/display/skl_watermark.c | 7 +-
> > > > -
> > > > 3 files changed, 11 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > index c32bfba06ca1..60504c390408 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > @@ -1152,6 +1152,7 @@ struct intel_crtc_state {
> > > > bool has_psr2;
> > > > bool enable_psr2_sel_fetch;
> > > > bool req_psr2_sdp_prior_scanline;
> > > > + bool wm_level_disabled;
> > > > u32 dc3co_exitline;
> > > > u16 su_y_granularity;
> > > > struct drm_dp_vsc_sdp psr_vsc;
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 44610b20cd29..a6edd65b8edb 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -1177,13 +1177,11 @@ static void
> > > > intel_psr_enable_source(struct
> > > > intel_dp *intel_dp,
> > > > * Wa_16013835468
> > > > * Wa_14015648006
> > > > */
> > > > - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > > - IS_DISPLAY_VER(dev_priv, 12, 13)) {
> > > > - if (crtc_state-
> > > > >hw.adjusted_mode.crtc_vblank_start
> > > > !=
> > > > - crtc_state->hw.adjusted_mode.crtc_vdisplay)
> > >
> > > That looks like something we want to keep. The delayed vblank w/a
> > > is
> > > still supposedly necessary.
> >
> > 16013835468 and 14015648006 are specifically mentioning "low power
> > watermark (level 1 and up) is disabled" I haven't seen or couldn't
> > find
> > any older Wa speaking generally about delayed vblank.
>
> 14015648006:
> "High refresh rate panels with small vblank size (either because of
> the
> panel vblank size or the internal delayed vblank) must have some
> watermark levels disabled..."
> -> that's the w/a you're now implementing, so the comment is
> lying to us by claiming it was already implemented
>
> 16013835468:
> "Display underrun when using delayed vblank with PSR2..."
> -> that's the one we actually already had implemented
>
> >
> > >
> > > > - intel_de_rmw(dev_priv,
> > > > GEN8_CHICKEN_DCPR_1,
> > > > 0,
> > > > -
> > > > wa_16013835468_bit_get(intel_dp));
> > > > - }
> > > > + if ((IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > > + IS_DISPLAY_VER(dev_priv, 12, 13)) &&
> > >
> > > I think we need this for all KBL+.
> >
> > Do you have Wa lineage for a reference?
>
> I think it was part of the w/a 1136. You see it only lists
> skl/bxt/kbl a-b to need the full psr disable, leaving kbl c+
> to do something different. And the latency reporting chicken
> bits were added exactly for kbl c+.
>
> But yeah, the way this is now documented in bpsec is very poor.
> And sadly the older hsds have now disappread into bit heaven
> so we can't double check the full details there. But I'm 99%
> sure I read through those hsds in the past and came to this
> same conclusion back then.
I just sent new version of the set. I.e. disabling PSR for < 12 and
using chicken bit for >= 12 if any wm level is disabled. That is at
least safe bet... Can you please check the set if that is ok to you? :
https://patchwork.freedesktop.org/series/115109/
>
> >
> > >
> > > > + crtc_state->wm_level_disabled)
> > > > + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> > > > + wa_16013835468_bit_get(intel_dp));
> > > >
> > > > if (intel_dp->psr.psr2_enabled) {
> > > > if (DISPLAY_VER(dev_priv) == 9)
> > > > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > index 50a9a6adbe32..afb751c024ba 100644
> > > > --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > @@ -2273,9 +2273,12 @@ static int skl_wm_check_vblank(struct
> > > > intel_crtc_state *crtc_state)
> > > > return level;
>
[Intel-gfx] [PATCH 1/2] drm/i915/debugfs: switch crtc debugfs to struct intel_crtc
Convert the crtc debugfs code to use struct intel_crtc instead of struct
drm_crtc.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
.../drm/i915/display/intel_display_debugfs.c | 20 ++-
.../drm/i915/display/intel_display_debugfs.h | 6 +++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index b79a8834559f..60e52c5abd82 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -212,7 +212,7 @@ static void intel_crtc_destroy(struct drm_crtc *_crtc)
static int intel_crtc_late_register(struct drm_crtc *crtc)
{
- intel_crtc_debugfs_add(crtc);
+ intel_crtc_debugfs_add(to_intel_crtc(crtc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 65585f19c6c8..faa44fb80aac 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -805,10 +805,10 @@ static const struct file_operations crtc_updates_fops = {
.write = crtc_updates_write
};
-static void crtc_updates_add(struct drm_crtc *crtc)
+static void crtc_updates_add(struct intel_crtc *crtc)
{
debugfs_create_file("i915_update_info", 0644, crtc->debugfs_entry,
- to_intel_crtc(crtc), &crtc_updates_fops);
+ crtc, &crtc_updates_fops);
}
#else
@@ -818,7 +818,7 @@ static void crtc_updates_info(struct seq_file *m,
{
}
-static void crtc_updates_add(struct drm_crtc *crtc)
+static void crtc_updates_add(struct intel_crtc *crtc)
{
}
#endif
@@ -1640,7 +1640,7 @@ static const struct file_operations i915_dsc_bpc_fops = {
*/
static int i915_current_bpc_show(struct seq_file *m, void *data)
{
- struct intel_crtc *crtc = to_intel_crtc(m->private);
+ struct intel_crtc *crtc = m->private;
struct intel_crtc_state *crtc_state;
int ret;
@@ -1722,15 +1722,17 @@ void intel_connector_debugfs_add(struct intel_connector
*intel_connector)
*
* Failure to add debugfs entries should generally be ignored.
*/
-void intel_crtc_debugfs_add(struct drm_crtc *crtc)
+void intel_crtc_debugfs_add(struct intel_crtc *crtc)
{
- if (!crtc->debugfs_entry)
+ struct dentry *root = crtc->base.debugfs_entry;
+
+ if (!root)
return;
crtc_updates_add(crtc);
- intel_drrs_crtc_debugfs_add(to_intel_crtc(crtc));
- intel_fbc_crtc_debugfs_add(to_intel_crtc(crtc));
+ intel_drrs_crtc_debugfs_add(crtc);
+ intel_fbc_crtc_debugfs_add(crtc);
- debugfs_create_file("i915_current_bpc", 0444, crtc->debugfs_entry, crtc,
+ debugfs_create_file("i915_current_bpc", 0444, root, crtc,
&i915_current_bpc_fops);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
index d3a79c07c384..e1f479b7acd1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.h
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.h
@@ -6,18 +6,18 @@
#ifndef __INTEL_DISPLAY_DEBUGFS_H__
#define __INTEL_DISPLAY_DEBUGFS_H__
-struct drm_crtc;
struct drm_i915_private;
struct intel_connector;
+struct intel_crtc;
#ifdef CONFIG_DEBUG_FS
void intel_display_debugfs_register(struct drm_i915_private *i915);
void intel_connector_debugfs_add(struct intel_connector *connector);
-void intel_crtc_debugfs_add(struct drm_crtc *crtc);
+void intel_crtc_debugfs_add(struct intel_crtc *crtc);
#else
static inline void intel_display_debugfs_register(struct drm_i915_private
*i915) {}
static inline void intel_connector_debugfs_add(struct intel_connector
*connector) {}
-static inline void intel_crtc_debugfs_add(struct drm_crtc *crtc) {}
+static inline void intel_crtc_debugfs_add(struct intel_crtc *crtc) {}
#endif
#endif /* __INTEL_DISPLAY_DEBUGFS_H__ */
--
2.39.2
[Intel-gfx] [PATCH 2/2] drm/i915/debugfs: add crtc i915_pipe debugfs file
The pipe may differ from crtc index if pipes are fused off. For testing
purposes, IGT needs to know the pipe.
There's already a I915_GET_PIPE_FROM_CRTC_ID IOCTL for this. However,
the upcoming Xe driver won't have that IOCTL, and going forward, we'll
want a unified interface for testing i915 and Xe, as they share the
display code. Thus add the debugfs for i915 display.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_debugfs.c| 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index faa44fb80aac..e85270adca95 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1657,6 +1657,17 @@ static int i915_current_bpc_show(struct seq_file *m,
void *data)
}
DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
+/* Pipe may differ from crtc index if pipes are fused off */
+static int intel_crtc_pipe_show(struct seq_file *m, void *unused)
+{
+ struct intel_crtc *crtc = m->private;
+
+ seq_printf(m, "%d\n", crtc->pipe);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe);
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -1735,4 +1746,6 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
debugfs_create_file("i915_current_bpc", 0444, root, crtc,
&i915_current_bpc_fops);
+ debugfs_create_file("i915_pipe", 0444, root, crtc,
+ &intel_crtc_pipe_fops);
}
--
2.39.2
Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Fix Wa_16013835468 and Wa_14015648006
On Fri, Mar 17, 2023 at 06:54:02AM +, Hogander, Jouni wrote:
> On Thu, 2023-03-16 at 20:21 +0200, Ville Syrjälä wrote:
> > On Tue, Mar 14, 2023 at 11:01:41AM +0200, Jouni Högander wrote:
> > > PSR WM optimization should be disabled based on any wm level being
> > > disabled. Currently it's disabled always when using delayed vblank.
> > >
> > > Bspec: 71580
> > >
> > > Signed-off-by: Jouni Högander
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> > > drivers/gpu/drm/i915/display/intel_psr.c | 12 +-
> > > --
> > > drivers/gpu/drm/i915/display/skl_watermark.c | 7 +--
> > > 3 files changed, 11 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index c32bfba06ca1..60504c390408 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1152,6 +1152,7 @@ struct intel_crtc_state {
> > > bool has_psr2;
> > > bool enable_psr2_sel_fetch;
> > > bool req_psr2_sdp_prior_scanline;
> > > + bool wm_level_disabled;
> > > u32 dc3co_exitline;
> > > u16 su_y_granularity;
> > > struct drm_dp_vsc_sdp psr_vsc;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 44610b20cd29..a6edd65b8edb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1177,13 +1177,11 @@ static void intel_psr_enable_source(struct
> > > intel_dp *intel_dp,
> > > * Wa_16013835468
> > > * Wa_14015648006
> > > */
> > > - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > - IS_DISPLAY_VER(dev_priv, 12, 13)) {
> > > - if (crtc_state->hw.adjusted_mode.crtc_vblank_start
> > > !=
> > > - crtc_state->hw.adjusted_mode.crtc_vdisplay)
> >
> > That looks like something we want to keep. The delayed vblank w/a is
> > still supposedly necessary.
>
> 16013835468 and 14015648006 are specifically mentioning "low power
> watermark (level 1 and up) is disabled" I haven't seen or couldn't find
> any older Wa speaking generally about delayed vblank.
14015648006:
"High refresh rate panels with small vblank size (either because of the
panel vblank size or the internal delayed vblank) must have some
watermark levels disabled..."
-> that's the w/a you're now implementing, so the comment is
lying to us by claiming it was already implemented
16013835468:
"Display underrun when using delayed vblank with PSR2..."
-> that's the one we actually already had implemented
>
> >
> > > - intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> > > 0,
> > > -
> > > wa_16013835468_bit_get(intel_dp));
> > > - }
> > > + if ((IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > + IS_DISPLAY_VER(dev_priv, 12, 13)) &&
> >
> > I think we need this for all KBL+.
>
> Do you have Wa lineage for a reference?
I think it was part of the w/a 1136. You see it only lists
skl/bxt/kbl a-b to need the full psr disable, leaving kbl c+
to do something different. And the latency reporting chicken
bits were added exactly for kbl c+.
But yeah, the way this is now documented in bpsec is very poor.
And sadly the older hsds have now disappread into bit heaven
so we can't double check the full details there. But I'm 99%
sure I read through those hsds in the past and came to this
same conclusion back then.
>
> >
> > > + crtc_state->wm_level_disabled)
> > > + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> > > + wa_16013835468_bit_get(intel_dp));
> > >
> > > if (intel_dp->psr.psr2_enabled) {
> > > if (DISPLAY_VER(dev_priv) == 9)
> > > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> > > b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > index 50a9a6adbe32..afb751c024ba 100644
> > > --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> > > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > @@ -2273,9 +2273,12 @@ static int skl_wm_check_vblank(struct
> > > intel_crtc_state *crtc_state)
> > > return level;
> > >
> > > /*
> > > - * FIXME PSR needs to toggle
> > > LATENCY_REPORTING_REMOVED_PIPE_*
> > > + * PSR needs to toggle LATENCY_REPORTING_REMOVED_PIPE_*
> > > * based on whether we're limited by the vblank duration.
> > > - *
> > > + */
> > > + crtc_state->wm_level_disabled = level < i915-
> > > >display.wm.num_levels - 1;
> > > +
> > > + /*
> > > * FIXME also related to skl+ w/a 1136 (also unimplemented
> > > as of
> > > * now) perhaps?
> > > */
> >
> > And that is more or less corresponding w/a for SKL
