[Intel-gfx] [drm-tip:drm-tip 3/8] drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:512:28: error: passing argument 1 of 'mutex_lock' from incompatible pointer type
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36d2ac0e15af4dfb942279e8097ab831661859e6
commit: cf07f850c0483b3314eb69fd8c810e461cef4035 [3/8] Merge remote-tracking
branch 'drm/drm-next' into drm-tip
config: ia64-allmodconfig
(https://download.01.org/0day-ci/archive/20220709/202207091259.wyfc1mp6-...@intel.com/config)
compiler: ia64-linux-gcc (GCC) 11.3.0
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
git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip
git fetch --no-tags drm-tip drm-tip
git checkout cf07f850c0483b3314eb69fd8c810e461cef4035
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/gpu/drm/amd/amdgpu/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
| ^~
include/linux/container_of.h:22:28: note: in expansion of macro 'offsetof'
22 | ((type *)(__mptr - offsetof(type, member))); })
|^~~~
include/linux/list.h:520:9: note: in expansion of macro 'container_of'
520 | container_of(ptr, type, member)
| ^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:70:25: note: in expansion of
macro 'list_entry'
70 | block = list_entry(block->link.next, struct
drm_buddy_block, link);
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c: In function
'amdgpu_vram_mgr_new':
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:488:13: error: 'cur_size'
undeclared (first use in this function)
488 | if (cur_size != size) {
| ^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:488:13: note: each undeclared
identifier is reported only once for each function it appears in
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:488:25: error: 'size'
undeclared (first use in this function); did you mean 'ksize'?
488 | if (cur_size != size) {
| ^~~~
| ksize
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:494:30: error: 'vres'
undeclared (first use in this function); did you mean 'res'?
494 | trim_list = &vres->blocks;
| ^~~~
| res
In file included from include/linux/bits.h:22,
from include/linux/ratelimit_types.h:5,
from include/linux/ratelimit.h:5,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/dma-mapping.h:7,
from drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:25:
include/linux/container_of.h:19:54: error: invalid use of undefined type
'struct drm_buddy_block'
19 | static_assert(__same_type(*(ptr), ((type *)0)->member) ||
\
| ^~
include/linux/build_bug.h:78:56: note: in definition of macro
'__static_assert'
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
|^~~~
include/linux/container_of.h:19:9: note: in expansion of macro
'static_assert'
19 | static_assert(__same_type(*(ptr), ((type *)0)->member) ||
\
| ^
include/linux/container_of.h:19:23: note: in expansion of macro '__same_type'
19 | static_assert(__same_type(*(ptr), ((type *)0)->member) ||
\
| ^~~
include/linux/list.h:520:9: note: in expansion of macro 'container_of'
520 | container_of(ptr, type, member)
| ^~~~
include/linux/list.h:542:9: note: in expansion of macro 'list_entry'
542 | list_entry((ptr)->prev, type, member)
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:502:33: note: in expansion of
macro 'list_last_entry'
502 | block = list_last_entry(&vres->blocks,
typeof(*block), link);
| ^~~
include/linux/compiler_types.h:293:27: error: expression in static assertion
is not an integer
293 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a),
typeof(b))
| ^~~~
include/linux/build_bug.h:78:56: note: in definition of macro
'__static_assert'
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist() (rev2)
== Series Details ==
Series: drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
(rev2)
URL : https://patchwork.freedesktop.org/series/106095/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862_full -> Patchwork_106095v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106095v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_invalid_mode@clock-too-high@edp-1-pipe-d}:
- shard-tglb: NOTRUN -> [SKIP][1] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-tglb1/igt@kms_invalid_mode@clock-too-h...@edp-1-pipe-d.html
* {igt@kms_invalid_mode@zero-vdisplay@hdmi-a-1-pipe-a}:
- {shard-dg1}:NOTRUN -> [WARN][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-dg1-13/igt@kms_invalid_mode@zero-vdisp...@hdmi-a-1-pipe-a.html
* {igt@kms_rmfb@rmfb-ioctl@pipe-d-hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [FAIL][3] +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-dg1-13/igt@kms_rmfb@rmfb-io...@pipe-d-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_106095v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][4] ([i915#4991])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-apl1/igt@gem_cre...@create-massive.html
* igt@gem_ctx_persistence@engines-hostile-preempt:
- shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-snb5/igt@gem_ctx_persiste...@engines-hostile-preempt.html
* igt@gem_ctx_persistence@hostile:
- shard-tglb: NOTRUN -> [FAIL][6] ([i915#2410])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-tglb1/igt@gem_ctx_persiste...@hostile.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271]) +26 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-snb5/igt@gem_exec_balan...@parallel-balancer.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-iclb4/igt@gem_exec_balan...@parallel-contexts.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-iclb3/igt@gem_exec_balan...@parallel-contexts.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][10] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-glk6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-iclb1/igt@gem_exec_fair@basic-p...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-iclb7/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk9/igt@gem_exec_fair@basic-p...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-glk1/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_lmem_swapping@verify:
- shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/shard-kbl7/igt@gem_lmem_swapp...@verify.html
* igt@gem_lmem_swapping@verify-ccs:
- shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Apply waitboosting before fence wait (rev2)
== Series Details ==
Series: drm/i915: Apply waitboosting before fence wait (rev2)
URL : https://patchwork.freedesktop.org/series/105925/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11862_full -> Patchwork_105925v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_105925v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_105925v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_105925v2_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- shard-apl: [PASS][1] -> [WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
* igt@kms_vblank@pipe-d-wait-forked-busy-hang:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-tglb8/igt@kms_vbl...@pipe-d-wait-forked-busy-hang.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/shard-tglb8/igt@kms_vbl...@pipe-d-wait-forked-busy-hang.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_cursor_crc@cursor-offscreen:
- {shard-rkl}:NOTRUN -> [SKIP][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/shard-rkl-5/igt@kms_cursor_...@cursor-offscreen.html
* {igt@kms_invalid_mode@clock-too-high@edp-1-pipe-d}:
- shard-tglb: NOTRUN -> [SKIP][6] +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/shard-tglb2/igt@kms_invalid_mode@clock-too-h...@edp-1-pipe-d.html
New tests
-
New tests have been introduced between CI_DRM_11862_full and
Patchwork_105925v2_full:
### New IGT tests (1) ###
* igt@kms_legacy_colorkey@basic:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_105925v2_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][7], [PASS][8], [PASS][9], [PASS][10],
[PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16],
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22],
[PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28],
[PASS][29], [PASS][30], [PASS][31]) -> ([PASS][32], [PASS][33], [PASS][34],
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40],
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46],
[FAIL][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
[PASS][53], [PASS][54], [PASS][55]) ([i915#4392])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk5/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk5/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk1/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk1/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk2/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk2/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk2/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk3/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk3/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk9/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk9/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk9/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk9/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk8/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk8/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk8/boot.html
[26]:
https://intel-gfx-ci.01.
[Intel-gfx] [drm-tip:drm-tip 3/8] include/linux/container_of.h:19:54: error: invalid use of undefined type 'struct drm_buddy_block'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 36d2ac0e15af4dfb942279e8097ab831661859e6 commit: cf07f850c0483b3314eb69fd8c810e461cef4035 [3/8] Merge remote-tracking branch 'drm/drm-next' into drm-tip config: microblaze-randconfig-r011-20220707 (https://download.01.org/0day-ci/archive/20220709/202207090946.xujb0gpo-...@intel.com/config) compiler: microblaze-linux-gcc (GCC) 11.3.0 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 git remote add drm-tip git://anongit.freedesktop.org/drm/drm-tip git fetch --no-tags drm-tip drm-tip git checkout cf07f850c0483b3314eb69fd8c810e461cef4035 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=microblaze SHELL=/bin/bash drivers/gpu/drm/amd/amdgpu/ If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from include/linux/bits.h:22, from include/linux/ratelimit_types.h:5, from include/linux/ratelimit.h:5, from include/linux/dev_printk.h:16, from include/linux/device.h:15, from include/linux/dma-mapping.h:7, from drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:25: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c: In function 'amdgpu_vram_mgr_first_block': >> include/linux/container_of.h:19:54: error: invalid use of undefined type >> 'struct drm_buddy_block' 19 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \ | ^~ include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert' 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) |^~~~ include/linux/container_of.h:19:9: note: in expansion of macro 'static_assert' 19 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \ | ^ include/linux/container_of.h:19:23: note: in expansion of macro '__same_type' 19 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \ | ^~~ include/linux/list.h:520:9: note: in expansion of macro 'container_of' 520 | container_of(ptr, type, member) | ^~~~ include/linux/list.h:555:27: note: in expansion of macro 'list_entry' 555 | pos__ != head__ ? list_entry(pos__, type, member) : NULL; \ | ^~ drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:54:16: note: in expansion of macro 'list_first_entry_or_null' 54 | return list_first_entry_or_null(list, struct drm_buddy_block, link); |^~~~ include/linux/compiler_types.h:293:27: error: expression in static assertion is not an integer 293 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b)) | ^~~~ include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert' 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) |^~~~ include/linux/container_of.h:19:9: note: in expansion of macro 'static_assert' 19 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \ | ^ include/linux/container_of.h:19:23: note: in expansion of macro '__same_type' 19 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \ | ^~~ include/linux/list.h:520:9: note: in expansion of macro 'container_of' 520 | container_of(ptr, type, member) | ^~~~ include/linux/list.h:555:27: note: in expansion of macro 'list_entry' 555 | pos__ != head__ ? list_entry(pos__, type, member) : NULL; \ | ^~ drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:54:16: note: in expansion of macro 'list_first_entry_or_null' 54 | return list_first_entry_or_null(list, struct drm_buddy_block, link); |^~~~ In file included from include/uapi/linux/posix_types.h:5, from include/uapi/linux/types.h:14, from include/linux/types.h:6, from include/linux/kasan-checks.h:5, from include/asm-generic/rwonce.h:26, from ./arch/microblaze/include/generated/asm/rwonce.h
Re: [Intel-gfx] [RFC] drm/i915/huc: better define HuC status getparam possible return values.
On 7/8/2022 4:48 PM, Daniele Ceraolo Spurio wrote:
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return value documented; these 2 error cases therefore
end up into the catch-all umbrella of the "HuC not loaded" case, with
this case therefore including both some error scenarios and the load
in progress one.
The updates included in this patch change the handling so that all
error cases behave the same way, i.e. return an errno code, and so
that the HuC load in progress case is unambiguous.
The patch also includes a small change to the FW init path to make sure
we always transition to an error state if something goes wrong.
This is an RFC because this is a minor change in behavior for an ioctl.
I'm arguing that this is not an API breakage because the expected return
for the cases I've changed was not well defined, but I want to make sure
no one is in opposition to this. From comments from media driver devs
on a different patch [1], it sounds like the media driver already
expected an errno value for all errors cases and is therefore already
compatible with the proposed changes.
[1] https://lists.freedesktop.org/archives/intel-gfx/2022-July/300990.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Tony Ye
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 14 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 -
include/uapi/drm/i915_drm.h | 16
4 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2706a8c65090..42cb244587f1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -455,6 +455,7 @@ int intel_guc_init(struct intel_guc *guc)
err_fw:
intel_uc_fw_fini(&guc->fw);
out:
+ intel_uc_fw_change_status(&guc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
i915_probe_error(gt->i915, "failed with %d\n", ret);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..bddcd3242ad0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -113,6 +113,7 @@ int intel_huc_init(struct intel_huc *huc)
return 0;
out:
+ intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
drm_info(&i915->drm, "HuC init failed with %d\n", err);
return err;
}
@@ -200,13 +201,8 @@ static bool huc_is_authenticated(struct intel_huc *huc)
* This function reads status register to verify if HuC
* firmware was successfully loaded.
*
- * Returns:
- * * -ENODEV if HuC is not present on this platform,
- * * -EOPNOTSUPP if HuC firmware is disabled,
- * * -ENOPKG if HuC firmware was not installed,
- * * -ENOEXEC if HuC firmware is invalid or mismatched,
- * * 0 if HuC firmware is not running,
- * * 1 if HuC firmware is authenticated and running.
+ * The return values match what is expected for the I915_PARAM_HUC_STATUS
+ * getparam.
*/
int intel_huc_check_status(struct intel_huc *huc)
{
@@ -219,6 +215,10 @@ int intel_huc_check_status(struct intel_huc *huc)
return -ENOPKG;
case INTEL_UC_FIRMWARE_ERROR:
return -ENOEXEC;
+ case INTEL_UC_FIRMWARE_INIT_FAIL:
+ return -ENOMEM;
+ case INTEL_UC_FIRMWARE_LOAD_FAIL:
+ return -EIO;
default:
break;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 27363091e1af..007401397935 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -707,7 +707,6 @@ int intel_uc_fw_init(struct intel_uc_fw *uc_fw)
out_unpin:
i915_gem_object_unpin_pages(uc_fw->obj);
out:
- intel_uc_fw_change_status(uc_fw, INTEL_UC_FIRMWARE_INIT_FAIL);
return err;
}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 094f6e377793..0950ef0d598c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -645,6 +645,22 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP (1ul << 5)
+/*
+ * Query the status of HuC load.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV if HuC is not present on this platform,
+ * -EOPNOTSUPP if HuC firmware usage is disabled,
+ * -ENOPKG if HuC firmware fetch failed,
+ * -ENOEXEC if HuC firmware is invalid or mismatched,
+ * -ENOMEM if i915 failed to prepare the FW objects for transfer to the uC,
+ * -EIO if the FW transfer or the FW authen
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: fix a couple IS_ERR() vs NULL tests (rev2)
== Series Details ==
Series: drm/i915/selftests: fix a couple IS_ERR() vs NULL tests (rev2)
URL : https://patchwork.freedesktop.org/series/106093/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11862_full -> Patchwork_106093v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106093v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106093v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106093v2_full:
### IGT changes ###
Possible regressions
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-tglb7/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-tglb8/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-iclb: [PASS][3] -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-iclb4/igt@kms_frontbuffer_track...@psr-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-iclb5/igt@kms_frontbuffer_track...@psr-suspend.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_invalid_mode@clock-too-high@edp-1-pipe-d}:
- shard-tglb: NOTRUN -> [SKIP][5] +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-tglb2/igt@kms_invalid_mode@clock-too-h...@edp-1-pipe-d.html
Known issues
Here are the changes found in Patchwork_106093v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-hostile-preempt:
- shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1
similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-snb4/igt@gem_ctx_persiste...@engines-hostile-preempt.html
* igt@gem_ctx_persistence@hostile:
- shard-tglb: NOTRUN -> [FAIL][7] ([i915#2410])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-tglb2/igt@gem_ctx_persiste...@hostile.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +26 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-snb4/igt@gem_exec_balan...@parallel-balancer.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][9] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-iclb1/igt@gem_exec_fair@basic-p...@bcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-iclb2/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-glk9/igt@gem_exec_fair@basic-p...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-glk9/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][17] -> [SKIP][18] ([i915#2190])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/shard-tglb8/igt@gem_huc_c...@huc-copy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@smem-oom:
- shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613])
[19]:
https
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: better define HuC status getparam possible return values.
== Series Details ==
Series: drm/i915/huc: better define HuC status getparam possible return values.
URL : https://patchwork.freedesktop.org/series/106139/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862 -> Patchwork_106139v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/index.html
Participating hosts (45 -> 40)
--
Additional (1): bat-dg2-9
Missing(6): fi-cml-u2 fi-bxt-dsi fi-hsw-4200u bat-dg2-8 fi-icl-u2
fi-ctg-p8600
Known issues
Here are the changes found in Patchwork_106139v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#4785])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u: [PASS][3] -> [DMESG-WARN][4] ([i915#5904]) +11
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
- fi-bdw-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([i915#6217])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-bdw-gvtdvm/igt@i915_selftest@live@late_gt_pm.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-bdw-gvtdvm/igt@i915_selftest@live@late_gt_pm.html
- fi-bsw-n3050: [PASS][7] -> [DMESG-FAIL][8] ([i915#3428])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#5904] /
[i915#62])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][11] -> [DMESG-WARN][12] ([i915#3576])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [PASS][13] -> [DMESG-FAIL][14] ([i915#62]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1:
- fi-cfl-8109u: [PASS][15] -> [DMESG-WARN][16] ([i915#62]) +10
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-cfl-8109u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-cfl-8109u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-hsw-4770/igt@run...@aborted.html
- fi-bsw-n3050: NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#4312])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-bsw-n3050/igt@run...@aborted.html
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][19] ([i915#4312])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/fi-bdw-gvtdvm/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-adln-1}: [DMESG-WARN][20] ([i915#6297]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adln-1/igt@i915_module_l...@reload.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/bat-adln-1/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][22] ([i915#3576]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106139v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/huc: better define HuC status getparam possible return values.
== Series Details == Series: drm/i915/huc: better define HuC status getparam possible return values. URL : https://patchwork.freedesktop.org/series/106139/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [RFC] drm/i915/huc: better define HuC status getparam possible return values.
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return value documented; these 2 error cases therefore
end up into the catch-all umbrella of the "HuC not loaded" case, with
this case therefore including both some error scenarios and the load
in progress one.
The updates included in this patch change the handling so that all
error cases behave the same way, i.e. return an errno code, and so
that the HuC load in progress case is unambiguous.
The patch also includes a small change to the FW init path to make sure
we always transition to an error state if something goes wrong.
This is an RFC because this is a minor change in behavior for an ioctl.
I'm arguing that this is not an API breakage because the expected return
for the cases I've changed was not well defined, but I want to make sure
no one is in opposition to this. From comments from media driver devs
on a different patch [1], it sounds like the media driver already
expected an errno value for all errors cases and is therefore already
compatible with the proposed changes.
[1] https://lists.freedesktop.org/archives/intel-gfx/2022-July/300990.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Tony Ye
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 14 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 -
include/uapi/drm/i915_drm.h | 16
4 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2706a8c65090..42cb244587f1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -455,6 +455,7 @@ int intel_guc_init(struct intel_guc *guc)
err_fw:
intel_uc_fw_fini(&guc->fw);
out:
+ intel_uc_fw_change_status(&guc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
i915_probe_error(gt->i915, "failed with %d\n", ret);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..bddcd3242ad0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -113,6 +113,7 @@ int intel_huc_init(struct intel_huc *huc)
return 0;
out:
+ intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
drm_info(&i915->drm, "HuC init failed with %d\n", err);
return err;
}
@@ -200,13 +201,8 @@ static bool huc_is_authenticated(struct intel_huc *huc)
* This function reads status register to verify if HuC
* firmware was successfully loaded.
*
- * Returns:
- * * -ENODEV if HuC is not present on this platform,
- * * -EOPNOTSUPP if HuC firmware is disabled,
- * * -ENOPKG if HuC firmware was not installed,
- * * -ENOEXEC if HuC firmware is invalid or mismatched,
- * * 0 if HuC firmware is not running,
- * * 1 if HuC firmware is authenticated and running.
+ * The return values match what is expected for the I915_PARAM_HUC_STATUS
+ * getparam.
*/
int intel_huc_check_status(struct intel_huc *huc)
{
@@ -219,6 +215,10 @@ int intel_huc_check_status(struct intel_huc *huc)
return -ENOPKG;
case INTEL_UC_FIRMWARE_ERROR:
return -ENOEXEC;
+ case INTEL_UC_FIRMWARE_INIT_FAIL:
+ return -ENOMEM;
+ case INTEL_UC_FIRMWARE_LOAD_FAIL:
+ return -EIO;
default:
break;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 27363091e1af..007401397935 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -707,7 +707,6 @@ int intel_uc_fw_init(struct intel_uc_fw *uc_fw)
out_unpin:
i915_gem_object_unpin_pages(uc_fw->obj);
out:
- intel_uc_fw_change_status(uc_fw, INTEL_UC_FIRMWARE_INIT_FAIL);
return err;
}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 094f6e377793..0950ef0d598c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -645,6 +645,22 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP (1ul << 5)
+/*
+ * Query the status of HuC load.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV if HuC is not present on this platform,
+ * -EOPNOTSUPP if HuC firmware usage is disabled,
+ * -ENOPKG if HuC firmware fetch failed,
+ * -ENOEXEC if HuC firmware is invalid or mismatched,
+ * -ENOMEM if i915 failed to prepare the FW objects for transfer to the uC,
+ * -EIO if the FW transfer or the FW authentication failed.
+ *
+ * If the IOCTL is successful, the returned parameter will
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: skip scrub_ctbs selftest if reset is disabled
== Series Details ==
Series: drm/i915/guc: skip scrub_ctbs selftest if reset is disabled
URL : https://patchwork.freedesktop.org/series/106133/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862 -> Patchwork_106133v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/index.html
Participating hosts (45 -> 42)
--
Additional (1): bat-dg2-9
Missing(4): fi-ctg-p8600 fi-cml-u2 fi-icl-u2 fi-hsw-4200u
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106133v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_pm:
- {bat-adln-1}: NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/bat-adln-1/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_106133v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][2] ([i915#4528])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][3] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][4] -> [FAIL][5] ([i915#6298])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-adln-1}: [DMESG-WARN][6] ([i915#6297]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adln-1/igt@i915_module_l...@reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/bat-adln-1/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][8] ([i915#4528]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
- fi-blb-e6850: [DMESG-FAIL][10] ([i915#4528]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][12] ([i915#3576]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@vgem_basic@setversion:
- fi-kbl-soraka: [INCOMPLETE][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-kbl-soraka/igt@vgem_ba...@setversion.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106133v1/fi-kbl-soraka/igt@vgem_ba...@setversion.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedeskto
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/dg2: Add Wa_15010599737
== Series Details ==
Series: series starting with [1/2] drm/i915/dg2: Add Wa_15010599737
URL : https://patchwork.freedesktop.org/series/106130/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862 -> Patchwork_106130v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/index.html
Participating hosts (45 -> 40)
--
Additional (1): bat-dg2-9
Missing(6): fi-kbl-soraka fi-cml-u2 fi-hsw-4200u bat-dg2-8 fi-icl-u2
fi-ctg-p8600
Known issues
Here are the changes found in Patchwork_106130v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][1] ([i915#4528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][3] -> [DMESG-WARN][4] ([i915#3576]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@kms_frontbuffer_tracking@basic:
- fi-kbl-guc: NOTRUN -> [SKIP][5] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/fi-kbl-guc/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-adln-1}: [DMESG-WARN][6] ([i915#6297]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adln-1/igt@i915_module_l...@reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/bat-adln-1/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][8] ([i915#3921]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][10] ([i915#4528]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][12] ([i915#3576]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106130v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[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#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[
[Intel-gfx] [PATCH] drm/i915/guc: skip scrub_ctbs selftest if reset is disabled
The test needs GT reset to trigger the scrubbing logic, so we can only run it when reset is enabled. Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c index 1df71d0796ae..5bd804f29b32 100644 --- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c @@ -54,6 +54,9 @@ static int intel_guc_scrub_ctbs(void *arg) struct intel_engine_cs *engine; struct intel_context *ce; + if (!intel_has_gpu_reset(gt)) + return 0; + wakeref = intel_runtime_pm_get(gt->uncore->rpm); engine = intel_selftest_find_any_engine(gt); -- 2.25.1
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/dg2: Add Wa_15010599737
== Series Details == Series: series starting with [1/2] drm/i915/dg2: Add Wa_15010599737 URL : https://patchwork.freedesktop.org/series/106130/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1391:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] [PATCH 2/2] drm/i915: Add Wa_14016291713
We already disable FBC when PSR2 is enabled on display version 12 and
above; this new workaround now requires that we do the same with PSR1 on
display versions 12 and 13.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 16537830ccf0..7436b35f7ea0 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1098,6 +1098,12 @@ static int intel_fbc_check_plane(struct
intel_atomic_state *state,
return 0;
}
+ /* Wa_14016291713 */
+ if (IS_DISPLAY_VER(i915, 12, 13) && crtc_state->has_psr) {
+ plane_state->no_fbc_reason = "PSR1 enabled (Wa_14016291713)";
+ return 0;
+ }
+
if (!pixel_format_is_valid(plane_state)) {
plane_state->no_fbc_reason = "pixel format not supported";
return 0;
--
2.36.1
[Intel-gfx] [PATCH 1/2] drm/i915/dg2: Add Wa_15010599737
This workaround may need to be extended to other platforms soon, but for now it's marked as DG2-specific. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index e6bb24dc7b99..60d6eb5f245b 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -371,6 +371,9 @@ #define GEN9_WM_CHICKEN3 _MMIO(0x5588) #define GEN9_FACTOR_IN_CLR_VAL_HIZ (1 << 9) +#define CHICKEN_RASTER_1 _MMIO(0x6204) +#define DIS_SF_ROUND_NEAREST_EVENREG_BIT(8) + #define VFLSKPD_MMIO(0x62a8) #define DIS_OVER_FETCH_CACHE REG_BIT(1) #define DIS_MULT_MISS_RD_SQUASH REG_BIT(0) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index dcc1ee392c0d..e8111fce56d0 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -689,6 +689,9 @@ static void dg2_ctx_workarounds_init(struct intel_engine_cs *engine, if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_B0, STEP_FOREVER) || IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915)) wa_masked_field_set(wal, VF_PREEMPTION, PREEMPTION_VERTEX_COUNT, 0x4000); + + /* Wa_15010599737:dg2 */ + wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN); } static void fakewa_disable_nestedbb_mode(struct intel_engine_cs *engine, -- 2.36.1
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Introduce Meteorlake
On Fri, Jul 08, 2022 at 04:38:48PM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: Introduce Meteorlake
> URL : https://patchwork.freedesktop.org/series/106075/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11859_full -> Patchwork_106075v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_106075v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_106075v1_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (13 -> 13)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_106075v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_exec_schedule@wide@vcs1:
> - shard-kbl: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-kbl4/igt@gem_exec_schedule@w...@vcs1.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-kbl1/igt@gem_exec_schedule@w...@vcs1.html
Test actually finished executing, but then there were some NVME errors,
followed by
<2>[ 334.527621] softdog: Initiating panic
<0>[ 334.529807] Kernel panic - not syncing: Software Watchdog Timer expired
This looks like general system instability, likely not related to
graphics at all.
Series applied to drm-intel-gt-next (as suggested by Rodrigo, since this
will allow the IS_METEORLAKE definitions to be cross-pollinated across
both drm-intel branches most easily).
Thanks for the patches.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
> - {shard-rkl}:NOTRUN -> [WARN][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-rkl-5/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
>
> * igt@kms_cursor_legacy@cursor-vs-flip@atomic:
> - {shard-dg1}:[PASS][4] -> [FAIL][5] +4 similar issues
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-dg1-12/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-dg1-15/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_106075v1_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-skl: ([PASS][6], [PASS][7], [PASS][8], [PASS][9],
> [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15],
> [PASS][16], [FAIL][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21],
> [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27],
> [PASS][28], [PASS][29], [PASS][30]) ([i915#5032]) -> ([PASS][31], [PASS][32],
> [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
> [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44],
> [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
> [PASS][51], [PASS][52])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
== Series Details == Series: drm/i915/selftests: fix a couple IS_ERR() vs NULL tests URL : https://patchwork.freedesktop.org/series/106093/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11859_full -> Patchwork_106093v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_106093v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_106093v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_106093v1_full: ### IGT changes ### Possible regressions * igt@i915_pm_rc6_residency@rc6-idle@vcs0: - shard-skl: [PASS][1] -> [WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl10/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html Known issues Here are the changes found in Patchwork_106093v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [FAIL][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) ([i915#5032]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl3/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl10/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl10/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl10/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl9/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/shard-skl9/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwor
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: fix sg_table construction (rev2)
== Series Details == Series: drm/i915/ttm: fix sg_table construction (rev2) URL : https://patchwork.freedesktop.org/series/106048/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11859_full -> Patchwork_106048v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_106048v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_106048v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_106048v2_full: ### IGT changes ### Possible regressions * igt@i915_pm_rc6_residency@rc6-idle@vcs0: - shard-glk: [PASS][1] -> [WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-glk9/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-glk7/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html * igt@i915_selftest@live@slpc: - shard-skl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-skl4/igt@i915_selftest@l...@slpc.html Known issues Here are the changes found in Patchwork_106048v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ccs@ctrl-surf-copy: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-tglb2/igt@gem_...@ctrl-surf-copy.html * igt@gem_create@create-massive: - shard-skl: NOTRUN -> [DMESG-WARN][5] ([i915#4991]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-skl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][6] ([i915#280]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-tglb2/igt@gem_ctx_s...@engines.html * igt@gem_eio@in-flight-10ms: - shard-tglb: [PASS][7] -> [TIMEOUT][8] ([i915#3063]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-tglb5/igt@gem_...@in-flight-10ms.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-tglb5/igt@gem_...@in-flight-10ms.html * igt@gem_exec_balancer@parallel-ordering: - shard-kbl: NOTRUN -> [FAIL][9] ([i915#6117]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-kbl1/igt@gem_exec_balan...@parallel-ordering.html * igt@gem_exec_balancer@parallel-out-fence: - shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-iclb4/igt@gem_exec_balan...@parallel-out-fence.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-iclb6/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-apl: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-apl2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][16] -> [FAIL][17] ([i915#2851]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_params@rsvd2-dirt: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109283]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/shard-tglb2/igt@gem_exec_par...@rsvd2-dirt.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613]) +1 similar issu
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr (rev2)
Filed a new issue for the mismatch.
https://gitlab.freedesktop.org/drm/intel/-/issues/6400
igt@kms_pipe_crc_basic@.* - fail - Failed assertion: !mismatch ||
igt_skip_crc_compare
Thanks,
Lakshmi.
-Original Message-
From: Roper, Matthew D
Sent: Friday, July 8, 2022 9:35 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/gt: Add general DSS steering
iterator to intel_gt_mcr (rev2)
On Sat, Jul 02, 2022 at 06:25:09PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr (rev2)
> URL : https://patchwork.freedesktop.org/series/105883/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11842_full -> Patchwork_105883v2_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_105883v2_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_105883v2_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (10 -> 13)
> --
>
> Additional (3): shard-rkl shard-dg1 shard-tglu
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_105883v2_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> *
> igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscaling@pipe-a-valid-mode:
> - shard-iclb: NOTRUN -> [SKIP][1] +3 similar issues
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-iclb1/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscal...@pipe-a-valid-mode.html
Seems to be new tests that match
https://gitlab.freedesktop.org/drm/intel/-/issues/2672 .
New tests were likely introduced by
commit 01f75333df0d27768ef987653ab49c3a1223ce3d
Author: Swati Sharma
AuthorDate: Thu Jun 30 13:15:11 2022 +0300
Commit: Juha-Pekka Heikkila
CommitDate: Fri Jul 1 12:41:09 2022 +0300
tests/i915/kms_flip_scaled_crc: Add new tests covering modifiers and
pixel-formats
>
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-b-hdmi-a-2:
> - shard-glk: [PASS][2] -> [FAIL][3]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/shard-glk7/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-hdmi-a-2.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-glk1/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-hdmi-a-2.html
CRC mismatch. Display CRCs would not be impacted by this patch which
just adds a new GT loop interface
Patch applied to drm-intel-gt-next. Thanks Matt Atwood for the review.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@gem_exec_capture@pi@rcs0:
> - {shard-dg1}:NOTRUN -> [INCOMPLETE][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-dg1-15/igt@gem_exec_capture@p...@rcs0.html
>
> *
> igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling@pipe-a-valid-mode:
> - {shard-tglu}: NOTRUN -> [SKIP][5] +14 similar issues
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-tglu-6/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscal...@pipe-a-valid-mode.html
>
> *
> igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscaling@pipe-a-valid-mode:
> - {shard-dg1}:NOTRUN -> [SKIP][6] +13 similar issues
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-dg1-12/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscal...@pipe-a-valid-mode.html
>
> * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling:
> - {shard-rkl}:NOTRUN -> [SKIP][7] +31 similar issues
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-rkl-5/igt@kms_flip_scaled_...@flip-64bpp-linear-to-16bpp-linear-downscaling.html
>
> *
> {igt@kms_flip_scaled_crc@flip-64bpp-linear-to-32bpp-linear-downscaling@pipe-a-default-mode}:
> - shard-iclb: NOTRUN -> [SKIP][8] +2 similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-32bpp-linear-downscal...@pipe-a-default-mode.html
>
>
>
> ### Piglit changes ###
>
> Possible regressions
>
> * spec@arb_gpu_shader5@texturegatheroffsets@fs-rgba-0-unorm-2d:
> - pig-glk-j5005: NOTRUN -> [INCOMPLETE][9]
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/pig-glk-j5005/spec@arb_gpu_shader5
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Introduce Meteorlake
== Series Details ==
Series: i915: Introduce Meteorlake
URL : https://patchwork.freedesktop.org/series/106075/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11859_full -> Patchwork_106075v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106075v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106075v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106075v1_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_schedule@wide@vcs1:
- shard-kbl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-kbl4/igt@gem_exec_schedule@w...@vcs1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-kbl1/igt@gem_exec_schedule@w...@vcs1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- {shard-rkl}:NOTRUN -> [WARN][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-rkl-5/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
* igt@kms_cursor_legacy@cursor-vs-flip@atomic:
- {shard-dg1}:[PASS][4] -> [FAIL][5] +4 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-dg1-12/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-dg1-15/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
Known issues
Here are the changes found in Patchwork_106075v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-skl: ([PASS][6], [PASS][7], [PASS][8], [PASS][9],
[PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15],
[PASS][16], [FAIL][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21],
[PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27],
[PASS][28], [PASS][29], [PASS][30]) ([i915#5032]) -> ([PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44],
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
[PASS][51], [PASS][52])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106075v1/shard-skl9/boot.html
[32]:
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr (rev2)
On Sat, Jul 02, 2022 at 06:25:09PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr (rev2)
> URL : https://patchwork.freedesktop.org/series/105883/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11842_full -> Patchwork_105883v2_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_105883v2_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_105883v2_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (10 -> 13)
> --
>
> Additional (3): shard-rkl shard-dg1 shard-tglu
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_105883v2_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> *
> igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscaling@pipe-a-valid-mode:
> - shard-iclb: NOTRUN -> [SKIP][1] +3 similar issues
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-iclb1/igt@kms_flip_scaled_crc@flip-32bpp-yftileccs-to-64bpp-yftile-downscal...@pipe-a-valid-mode.html
Seems to be new tests that match
https://gitlab.freedesktop.org/drm/intel/-/issues/2672 .
New tests were likely introduced by
commit 01f75333df0d27768ef987653ab49c3a1223ce3d
Author: Swati Sharma
AuthorDate: Thu Jun 30 13:15:11 2022 +0300
Commit: Juha-Pekka Heikkila
CommitDate: Fri Jul 1 12:41:09 2022 +0300
tests/i915/kms_flip_scaled_crc: Add new tests covering modifiers and
pixel-formats
>
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-b-hdmi-a-2:
> - shard-glk: [PASS][2] -> [FAIL][3]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11842/shard-glk7/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-hdmi-a-2.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-glk1/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-hdmi-a-2.html
CRC mismatch. Display CRCs would not be impacted by this patch which
just adds a new GT loop interface
Patch applied to drm-intel-gt-next. Thanks Matt Atwood for the review.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@gem_exec_capture@pi@rcs0:
> - {shard-dg1}:NOTRUN -> [INCOMPLETE][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-dg1-15/igt@gem_exec_capture@p...@rcs0.html
>
> *
> igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling@pipe-a-valid-mode:
> - {shard-tglu}: NOTRUN -> [SKIP][5] +14 similar issues
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-tglu-6/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscal...@pipe-a-valid-mode.html
>
> *
> igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscaling@pipe-a-valid-mode:
> - {shard-dg1}:NOTRUN -> [SKIP][6] +13 similar issues
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-dg1-12/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscal...@pipe-a-valid-mode.html
>
> * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling:
> - {shard-rkl}:NOTRUN -> [SKIP][7] +31 similar issues
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-rkl-5/igt@kms_flip_scaled_...@flip-64bpp-linear-to-16bpp-linear-downscaling.html
>
> *
> {igt@kms_flip_scaled_crc@flip-64bpp-linear-to-32bpp-linear-downscaling@pipe-a-default-mode}:
> - shard-iclb: NOTRUN -> [SKIP][8] +2 similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-32bpp-linear-downscal...@pipe-a-default-mode.html
>
>
>
> ### Piglit changes ###
>
> Possible regressions
>
> * spec@arb_gpu_shader5@texturegatheroffsets@fs-rgba-0-unorm-2d:
> - pig-glk-j5005: NOTRUN -> [INCOMPLETE][9]
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105883v2/pig-glk-j5005/spec@arb_gpu_shader5@texturegatheroffs...@fs-rgba-0-unorm-2d.html
>
> * spec@ext_framebuffer_multisample@sample-coverage 4 non-inverted:
> - pig-skl-6260u: NOTRUN -> [CRASH][10]
>[10]: None
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_105883v2_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_ctx_persistence@legacy-engines-hostile:
> - shard-snb: NOTRU
Re: [Intel-gfx] [PATCH] drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
On Fri, Jul 01, 2022 at 04:20:06PM -0700, Matt Roper wrote:
> Although all DSS belong to a single pool on Xe_HP platforms (i.e.,
> they're not organized into slices from a topology point of view), we do
> still need to pass 'group' and 'instance' targets when steering register
> accesses to a specific instance of a per-DSS multicast register. The
> rules for how to determine group and instance IDs (which previously used
> legacy terms "slice" and "subslice") varies by platform. Some platforms
> determine steering by gslice membership, some platforms by cslice
> membership, and future platforms may have other rules.
>
> Since looping over each DSS and performing steered unicast register
> accesses is a relatively common pattern, let's add a dedicated iteration
> macro to handle this (and replace the platform-specific "instdone" loop
> we were using previously. This will avoid the calling code needing to
> figure out the details about how to obtain steering IDs for a specific
> DSS.
>
> Most of the places where we use this new loop are in the GPU errorstate
> code at the moment, but we do have some additional features coming in
> the future that will also need to loop over each DSS and steer some
> register accesses accordingly.
>
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 34 ++-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 22
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 25 ++
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 24 +
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 13 ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 32 ++---
> 6 files changed, 75 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 283870c65991..37fa813af766 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1517,7 +1517,6 @@ void intel_engine_get_instdone(const struct
> intel_engine_cs *engine,
> struct intel_instdone *instdone)
> {
> struct drm_i915_private *i915 = engine->i915;
> - const struct sseu_dev_info *sseu = &engine->gt->info.sseu;
> struct intel_uncore *uncore = engine->uncore;
> u32 mmio_base = engine->mmio_base;
> int slice;
> @@ -1542,32 +1541,19 @@ void intel_engine_get_instdone(const struct
> intel_engine_cs *engine,
> intel_uncore_read(uncore,
> GEN12_SC_INSTDONE_EXTRA2);
> }
>
> - if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> - for_each_instdone_gslice_dss_xehp(i915, sseu, iter,
> slice, subslice) {
> - instdone->sampler[slice][subslice] =
> - intel_gt_mcr_read(engine->gt,
> - GEN7_SAMPLER_INSTDONE,
> - slice, subslice);
> - instdone->row[slice][subslice] =
> - intel_gt_mcr_read(engine->gt,
> - GEN7_ROW_INSTDONE,
> - slice, subslice);
> - }
> - } else {
> - for_each_instdone_slice_subslice(i915, sseu, slice,
> subslice) {
> - instdone->sampler[slice][subslice] =
> - intel_gt_mcr_read(engine->gt,
> - GEN7_SAMPLER_INSTDONE,
> - slice, subslice);
> - instdone->row[slice][subslice] =
> - intel_gt_mcr_read(engine->gt,
> - GEN7_ROW_INSTDONE,
> - slice, subslice);
> - }
> + for_each_ss_steering(iter, engine->gt, slice, subslice) {
> + instdone->sampler[slice][subslice] =
> + intel_gt_mcr_read(engine->gt,
> + GEN7_SAMPLER_INSTDONE,
> + slice, subslice);
> + instdone->row[slice][subslice] =
> + intel_gt_mcr_read(engine->gt,
> + GEN7_ROW_INSTDONE,
> + slice, subslice);
> }
>
> if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55)) {
> - for_each_instdone_gslice_dss_xehp(i915, sseu, iter,
> slice, subslice)
> + for_each_ss_steering(iter, engine->gt, slice, subslice)
>
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] i915/perf: Replace DRM_DEBUG with driver specific drm_dbg call
On Fri, Jul 08, 2022 at 08:49:33AM -0700, Matt Roper wrote: On Fri, Jul 08, 2022 at 01:44:00PM +, Patchwork wrote: == Series Details == Series: series starting with [1/2] i915/perf: Replace DRM_DEBUG with driver specific drm_dbg call URL : https://patchwork.freedesktop.org/series/106062/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11857_full -> Patchwork_106062v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_106062v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_106062v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_106062v1_full: ### IGT changes ### Possible regressions * igt@i915_pm_rc6_residency@rc6-idle@vcs0: - shard-apl: [PASS][1] -> [WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html Seems to be the same warning seen in https://gitlab.freedesktop.org/drm/intel/-/issues/2684 https://gitlab.freedesktop.org/drm/intel/-/issues/2681 https://gitlab.freedesktop.org/drm/intel/-/issues/1804 but on a different platform. Not caused by these patches. * igt@i915_selftest@live@slpc: - shard-skl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-skl7/igt@i915_selftest@l...@slpc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-skl6/igt@i915_selftest@l...@slpc.html Log cuts off in middle. Likely a sporadic system/network crash; not caused by the changes here. * igt@kms_async_flips@test-time-stamp@pipe-a-edp-1: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglb1/igt@kms_async_flips@test-time-st...@pipe-a-edp-1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-tglb8/igt@kms_async_flips@test-time-st...@pipe-a-edp-1.html Another unexpected incomplete. Not caused by these patches. Series applied to drm-intel-gt-next (with a minor tweak to the author line to make the formatting match the s-o-b line). Thanks for the patches and reviews. Thanks for applying this, Umesh Matt
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] i915/perf: Replace DRM_DEBUG with driver specific drm_dbg call
On Fri, Jul 08, 2022 at 01:44:00PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] i915/perf: Replace DRM_DEBUG with driver
> specific drm_dbg call
> URL : https://patchwork.freedesktop.org/series/106062/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11857_full -> Patchwork_106062v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_106062v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_106062v1_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (13 -> 13)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_106062v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
> - shard-apl: [PASS][1] -> [WARN][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
Seems to be the same warning seen in
https://gitlab.freedesktop.org/drm/intel/-/issues/2684
https://gitlab.freedesktop.org/drm/intel/-/issues/2681
https://gitlab.freedesktop.org/drm/intel/-/issues/1804
but on a different platform. Not caused by these patches.
>
> * igt@i915_selftest@live@slpc:
> - shard-skl: [PASS][3] -> [INCOMPLETE][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-skl7/igt@i915_selftest@l...@slpc.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-skl6/igt@i915_selftest@l...@slpc.html
Log cuts off in middle. Likely a sporadic system/network crash; not
caused by the changes here.
>
> * igt@kms_async_flips@test-time-stamp@pipe-a-edp-1:
> - shard-tglb: [PASS][5] -> [INCOMPLETE][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglb1/igt@kms_async_flips@test-time-st...@pipe-a-edp-1.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-tglb8/igt@kms_async_flips@test-time-st...@pipe-a-edp-1.html
Another unexpected incomplete. Not caused by these patches.
Series applied to drm-intel-gt-next (with a minor tweak to the author
line to make the formatting match the s-o-b line). Thanks for the
patches and reviews.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@gem_busy@close-race:
> - {shard-tglu}: [PASS][7] -> [INCOMPLETE][8]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-2/igt@gem_b...@close-race.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-tglu-4/igt@gem_b...@close-race.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_106062v1_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-snb: ([PASS][9], [PASS][10], [PASS][11], [PASS][12],
> [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
> [PASS][19], [FAIL][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
> [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30],
> [PASS][31], [PASS][32], [PASS][33]) ([i915#4338]) -> ([PASS][34], [PASS][35],
> [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
> [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47],
> [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53],
> [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist() (rev2)
== Series Details ==
Series: drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
(rev2)
URL : https://patchwork.freedesktop.org/series/106095/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862 -> Patchwork_106095v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/index.html
Participating hosts (45 -> 40)
--
Additional (1): bat-dg2-9
Missing(6): fi-cml-u2 fi-rkl-11600 fi-bxt-dsi fi-hsw-4200u fi-ctg-p8600
fi-hsw-4770
Known issues
Here are the changes found in Patchwork_106095v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@load:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-kbl-soraka/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/fi-kbl-soraka/igt@i915_module_l...@load.html
* igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][3] -> [DMESG-WARN][4] ([i915#3576]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/bat-adlp-4/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-adln-1}: [DMESG-WARN][6] ([i915#6297]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adln-1/igt@i915_module_l...@reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/bat-adln-1/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][8] ([i915#4528]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][10] ([i915#3576]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@vgem_basic@setversion:
- fi-kbl-soraka: [INCOMPLETE][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-kbl-soraka/igt@vgem_ba...@setversion.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v2/fi-kbl-soraka/igt@vgem_ba...@setversion.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[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#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
[i915#5174]: https://gitlab.freedesktop.org/drm/intel/issues/5174
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: ttm for stolen (rev8)
== Series Details == Series: drm/i915: ttm for stolen (rev8) URL : https://patchwork.freedesktop.org/series/101396/ State : success == Summary == CI Bug Log - changes from CI_DRM_11859_full -> Patchwork_101396v8_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 13) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_101396v8_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#5032]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl6/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl6/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl4/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl4/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl4/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v8/shard-skl3/boot.html
Re: [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
On Fri, 2022-07-08 at 07:51 -0700, Niranjana Vishwanathapura wrote: > > Since we don't loop over the vm_bound_list, there is a need to > > check > > whether the rebind_list is empty here under the notifier_lock in > > read > > mode, and in that case, restart from eb_lookup_vmas(). That might > > also > > eliminate the need for the __EXEC3_USERPTR_USED flag? > > > > That will also catch any objects that were evicted between > > eb_lookup_vmas() where the rebind_list was last checked, and > > i915_gem_vm_priv_lock(), which prohibits further eviction, but if > > we > > want to catch these earlier (which I think is a good idea), we > > could > > check that the rebind_list is indeed empty just after taking the > > vm_priv_lock(), and if not, restart from eb_lookup_vmas(). > > Yah, right, we need to check rebind_list here and if not empty, > restart > from lookup phase. > It is bit tricky with userptr here as the unbind happens during > submit_init() call after we scoop unbound vmas here, the vmas gets > re-added to rebind_list :(. Ugh. > I think we need a separate 'invalidated_userptr_list' here and we > iterate through it for submit_init() and submit_done() calls (yes, > __EXEC3_USERPTR_USED flag won't be needed then). > And, we call, eb_scoop_unbound_vmas() after calling > eb_lookup_persistent_userptr_vmas(), so that we scoop all unbound > vmas properly. > I'm not sure that will help much, because we'd also need to recheck the rebind_list and possibly restart after taking the vm_priv_lock, since objects can be evicted between the scooping and taking the vm_priv_lock. So then the userptrs will be caught by that check. /Thomas
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply waitboosting before fence wait (rev2)
== Series Details ==
Series: drm/i915: Apply waitboosting before fence wait (rev2)
URL : https://patchwork.freedesktop.org/series/105925/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862 -> Patchwork_105925v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/index.html
Participating hosts (45 -> 41)
--
Missing(4): fi-ctg-p8600 fi-cml-u2 fi-hsw-4200u bat-jsl-3
Known issues
Here are the changes found in Patchwork_105925v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][1] -> [DMESG-FAIL][2] ([i915#62])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][3] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-g3258: [PASS][6] -> [INCOMPLETE][7] ([i915#4785])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@modeset:
- bat-adlp-4: [PASS][8] -> [DMESG-WARN][9] ([i915#3576])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-4/igt@kms_busy@ba...@modeset.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/bat-adlp-4/igt@kms_busy@ba...@modeset.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [PASS][11] -> [DMESG-WARN][12] ([i915#62]) +12
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-hsw-4770/igt@run...@aborted.html
- fi-hsw-g3258: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#4312] /
[i915#6246])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-adln-1}: [DMESG-WARN][15] ([i915#6297]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adln-1/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/bat-adln-1/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][17] ([i915#3921]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [DMESG-FAIL][19] ([i915#4494] / [i915#4957]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][21] ([i915#4528]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][23] ([i915#3576]) -> [PASS][24] +1
similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105925v2/bat-adlp-6/igt@kms_flip@basic-flip
Re: [Intel-gfx] [RFC 05/10] drm/i915/vm_bind: Handle persistent vmas
On Thu, Jul 07, 2022 at 04:27:23AM -0700, Hellstrom, Thomas wrote:
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
Treat VM_BIND vmas as persistent and handle them during the
request submission in the execbuff path.
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 3 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 12 ++-
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 22 ++
drivers/gpu/drm/i915/i915_vma.c | 32 +++-
drivers/gpu/drm/i915/i915_vma.h | 78
+--
drivers/gpu/drm/i915/i915_vma_types.h | 23 ++
9 files changed, 163 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index ccec4055fde3..5121f02ba95c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -38,6 +38,7 @@
#include "i915_gem_mman.h"
#include "i915_gem_object.h"
#include "i915_gem_ttm.h"
+#include "i915_gem_vm_bind.h"
#include "i915_memcpy.h"
#include "i915_trace.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 849bf3c1061e..eaadf5a6ab09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -6,6 +6,7 @@
#ifndef __I915_GEM_VM_BIND_H
#define __I915_GEM_VM_BIND_H
+#include
#include "i915_drv.h"
#define assert_vm_bind_held(vm) lockdep_assert_held(&(vm)-
>vm_bind_lock)
@@ -26,6 +27,8 @@ static inline void i915_gem_vm_bind_unlock(struct
i915_address_space *vm)
mutex_unlock(&vm->vm_bind_lock);
}
+#define assert_vm_priv_held(vm) assert_object_held((vm)->root_obj)
+
static inline int i915_gem_vm_priv_lock(struct i915_address_space
*vm,
struct i915_gem_ww_ctx *ww)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 96f139cc8060..1a8efa83547f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -85,6 +85,13 @@ void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
assert_vm_bind_held(vma->vm);
+ spin_lock(&vma->vm->vm_rebind_lock);
+ if (!list_empty(&vma->vm_rebind_link))
+ list_del_init(&vma->vm_rebind_link);
+ i915_vma_set_purged(vma);
+ i915_vma_set_freed(vma);
Following the vma destruction discussion, can we ditch the freed flag
now?
Yes
+ spin_unlock(&vma->vm->vm_rebind_lock);
+
if (!list_empty(&vma->vm_bind_link)) {
list_del_init(&vma->vm_bind_link);
list_del_init(&vma->non_priv_vm_bind_link);
@@ -220,6 +227,7 @@ static struct i915_vma *vm_bind_get_vma(struct
i915_address_space *vm,
vma->start = va->start;
vma->last = va->start + va->length - 1;
+ i915_vma_set_persistent(vma);
return vma;
}
@@ -304,8 +312,10 @@ int i915_gem_vm_bind_obj(struct
i915_address_space *vm,
i915_vm_bind_put_fence(vma);
put_vma:
- if (ret)
+ if (ret) {
+ i915_vma_set_freed(vma);
i915_vma_destroy(vma);
+ }
i915_gem_ww_ctx_fini(&ww);
unlock_vm:
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index df0a8459c3c6..55d5389b2c6c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -293,6 +293,8 @@ void i915_address_space_init(struct
i915_address_space *vm, int subclass)
INIT_LIST_HEAD(&vm->non_priv_vm_bind_list);
vm->root_obj = i915_gem_object_create_internal(vm->i915,
PAGE_SIZE);
GEM_BUG_ON(IS_ERR(vm->root_obj));
+ INIT_LIST_HEAD(&vm->vm_rebind_list);
+ spin_lock_init(&vm->vm_rebind_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index f538ce9115c9..fe5485c4a1cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -265,6 +265,8 @@ struct i915_address_space {
struct mutex vm_bind_lock; /* Protects vm_bind lists */
struct list_head vm_bind_list;
struct list_head vm_bound_list;
+ struct list_head vm_rebind_list;
+ spinlock_t vm_rebind_lock; /* Protects vm_rebind_list */
/* va tree of persistent vmas */
struct rb_root_cached va;
struct list_head non_priv_vm_bind_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8c2f57eb5dda..09b89d1913fc 100644
--
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Apply waitboosting before fence wait (rev2)
== Series Details ==
Series: drm/i915: Apply waitboosting before fence wait (rev2)
URL : https://patchwork.freedesktop.org/series/105925/
State : warning
== Summary ==
Error: dim checkpatch failed
e35c61e9e46c drm/i915/gem: Look for waitboosting across the whole object prior
to individual waits
85a4558b5d11 drm/i915: Bump GT idling delay to 2 jiffies
0ec610488c77 drm/i915/gt: Only kick the signal worker if there's been an update
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
References: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 047a1b877ed4 ("dma-buf &
drm/amdgpu: remove dma_resv workaround")'
#23:
References: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
Re: [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
On Fri, Jul 08, 2022 at 05:17:53AM -0700, Hellstrom, Thomas wrote: On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote: For persistent (vm_bind) vmas of userptr BOs, handle the user page pinning by using the i915_gem_object_userptr_submit_init() /done() functions Signed-off-by: Niranjana Vishwanathapura --- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 67 +++ .../drm/i915/gem/i915_gem_vm_bind_object.c| 16 + drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + drivers/gpu/drm/i915/gt/intel_gtt.h | 1 + 4 files changed, 85 insertions(+) Hmm. I also miss the code in userptr invalidate that puts invalidated vm-private userptr vmas on the rebind list? Yah, looks like it is lost in rebase. Based on discussion in other thread on this patch, it is going to be bit different here than adding to rebind_list. Niranjana /Thomas
Re: [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
On Thu, Jul 07, 2022 at 06:11:13AM -0700, Hellstrom, Thomas wrote:
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 67
+++
.../drm/i915/gem/i915_gem_vm_bind_object.c| 16 +
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
4 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 2079f5ca9010..bf13dd6d642e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -22,6 +22,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_USERPTR_USED BIT_ULL(34)
#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -147,10 +148,36 @@ static void eb_scoop_unbound_vmas(struct
i915_address_space *vm)
spin_unlock(&vm->vm_rebind_lock);
}
+static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer
*eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *last_vma = NULL;
+ struct i915_vma *vma;
+ int err;
+
+ assert_vm_bind_held(vm);
+
+ list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
+ if (i915_gem_object_is_userptr(vma->obj)) {
+ err =
i915_gem_object_userptr_submit_init(vma->obj);
+ if (err)
+ return err;
+
+ last_vma = vma;
+ }
+ }
+
Don't we need to loop also over non-private userptr objects?
No, as explained in other thread, non-private BOs will also be
there in vm_bind/bound_list.
+ if (last_vma)
+ eb->args->flags |= __EXEC3_USERPTR_USED;
+
+ return 0;
+}
+
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
unsigned int i, current_batch = 0;
struct i915_vma *vma;
+ int err = 0;
for (i = 0; i < eb->num_batches; i++) {
vma = eb_find_vma(eb->context->vm, eb-
>batch_addresses[i]);
@@ -163,6 +190,10 @@ static int eb_lookup_vmas(struct i915_execbuffer
*eb)
eb_scoop_unbound_vmas(eb->context->vm);
+ err = eb_lookup_persistent_userptr_vmas(eb);
+ if (err)
+ return err;
+
return 0;
}
@@ -358,15 +389,51 @@ static void
eb_persistent_vmas_move_to_active(struct i915_execbuffer *eb)
static int eb_move_to_gpu(struct i915_execbuffer *eb)
{
+ int err = 0, j;
+
assert_vm_bind_held(eb->context->vm);
assert_vm_priv_held(eb->context->vm);
eb_persistent_vmas_move_to_active(eb);
+#ifdef CONFIG_MMU_NOTIFIER
+ if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+ struct i915_vma *vma;
+
+ assert_vm_bind_held(eb->context->vm);
+ assert_vm_priv_held(eb->context->vm);
+
+ read_lock(&eb->i915->mm.notifier_lock);
+ list_for_each_entry(vma, &eb->context->vm-
>vm_bind_list,
+ vm_bind_link) {
+ if (!i915_gem_object_is_userptr(vma->obj))
+ continue;
+
+ err =
i915_gem_object_userptr_submit_done(vma->obj);
+ if (err)
+ break;
+ }
+
+ read_unlock(&eb->i915->mm.notifier_lock);
+ }
Since we don't loop over the vm_bound_list, there is a need to check
whether the rebind_list is empty here under the notifier_lock in read
mode, and in that case, restart from eb_lookup_vmas(). That might also
eliminate the need for the __EXEC3_USERPTR_USED flag?
That will also catch any objects that were evicted between
eb_lookup_vmas() where the rebind_list was last checked, and
i915_gem_vm_priv_lock(), which prohibits further eviction, but if we
want to catch these earlier (which I think is a good idea), we could
check that the rebind_list is indeed empty just after taking the
vm_priv_lock(), and if not, restart from eb_lookup_vmas().
Yah, right, we need to check rebind_list here and if not empty, restart
from lookup phase.
It is bit tricky with userptr here as the unbind happens during
submit_init() call after we scoop unbound vmas here, the vmas gets
re-added to rebind_list :(.
I think we need a separate 'invalidated_userptr_list' here and we
iterate through it for submit_init() and submit_done() calls (yes,
__EXEC3_USERPTR_USED flag won't be needed then).
And, we call, eb_scoop_unbound_vmas() after calling
eb_lookup_persistent_userptr_vmas(), so that we scoop all unbound
vmas proper
Re: [Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs
On Fri, 2022-07-08 at 15:43 +0200, Thomas Hellström wrote: > > The vm_bind/bound_list and the non_priv_vm_bind_list are there for > > very different reasons. > > > > The reason for having separate vm_bind_list and vm_bound_list is > > that > > during the execbuf path, we can rebind the unbound mappings by > > scooping > > all unbound vmas back from bound list into the bind list and > > binding > > them. In fact, this probably can be done with a single vm_bind_list > > and > > a 'eb.bind_list' (local to execbuf3 ioctl) for rebinding. > > > > The non_priv_vm_bind_list is just an optimization to loop only > > through > > non-priv objects while taking the locks in > > eb_lock_persistent_vmas() > > as only non-priv objects needs that (private objects are locked in > > a > > single shot with vm_priv_lock). A non-priv mapping will also be in > > the > > vm_bind/bound_list. > > > > I think, we need to add this as documentation to be more clear. > > OK, I understood it as private objects were either on the vm_bind > list > or vm_bound_list depending on whether they needed rebinding or not, > and > shared objects only on the non_priv_vm_bind list, and were always > locked, validated and fenced... > > Need to take a deeper look... > > /Thomas > > > > > > > Niranjana > > > > Hmm. Just a quick thought on this, Since the non-private vm-bind objects all need to be iterated through (locked and fenced and userptr valid) on each execbuf, and checking for validation (resident and bound) is a very quick check, then we'd never need to add them to the rebind list at all, right? If so the rebind list would be exclusive to vm-private objects. Also I don't think the vm_bind list can be execbuf-local, since binding may not have completed at vma_release time, at which point the objects need to remain on the vm_bind list until the next execbuf... /Thomas
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
On Fri, Jul 08, 2022 at 04:20:11PM +0200, Karolina Drobnik wrote:
> From: Chris Wilson
>
> We employ a "waitboost" heuristic to detect when userspace is stalled
> waiting for results from earlier execution. Under latency sensitive work
> mixed between the gpu/cpu, the GPU is typically under-utilised and so
> RPS sees that low utilisation as a reason to downclock the frequency,
> causing longer stalls and lower throughput. The user left waiting for
> the results is not impressed.
>
> On applying commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv
> workaround") it was observed that deinterlacing h264 on Haswell
> performance dropped by 2-5x. The reason being that the natural workload
> was not intense enough to trigger RPS (using HW evaluation intervals) to
> upclock, and so it was depending on waitboosting for the throughput.
>
> Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
> changes the composition of dma-resv from keeping a single write fence +
> multiple read fences, to a single array of multiple write and read
> fences (a maximum of one pair of write/read fences per context). The
> iteration order was also changed implicitly from all-read fences then
> the single write fence, to a mix of write fences followed by read
> fences. It is that ordering change that belied the fragility of
> waitboosting.
>
> Currently, a waitboost is inspected at the point of waiting on an
> outstanding fence. If the GPU is backlogged such that we haven't yet
> stated the request we need to wait on, we force the GPU to upclock until
> the completion of that request. By changing the order in which we waited
> upon requests, we ended up waiting on those requests in sequence and as
> such we saw that each request was already started and so not a suitable
> candidate for waitboosting.
>
> Instead of asking whether to boost each fence in turn, we can look at
> whether boosting is required for the dma-resv ensemble prior to waiting
> on any fence, making the heuristic more robust to the order in which
> fences are stored in the dma-resv.
>
> Reported-by: Thomas Voegtle
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6284
> Fixes: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Karolina Drobnik
> Tested-by: Thomas Voegtle
> Reviewed-by: Andi Shyti
Acked-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 34
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> index 319936f91ac5..e6e01c2a74a6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> @@ -9,6 +9,7 @@
> #include
>
> #include "gt/intel_engine.h"
> +#include "gt/intel_rps.h"
>
> #include "i915_gem_ioctls.h"
> #include "i915_gem_object.h"
> @@ -31,6 +32,37 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
> timeout);
> }
>
> +static void
> +i915_gem_object_boost(struct dma_resv *resv, unsigned int flags)
> +{
> + struct dma_resv_iter cursor;
> + struct dma_fence *fence;
> +
> + /*
> + * Prescan all fences for potential boosting before we begin waiting.
> + *
> + * When we wait, we wait on outstanding fences serially. If the
> + * dma-resv contains a sequence such as 1:1, 1:2 instead of a reduced
> + * form 1:2, then as we look at each wait in turn we see that each
> + * request is currently executing and not worthy of boosting. But if
> + * we only happen to look at the final fence in the sequence (because
> + * of request coalescing or splitting between read/write arrays by
> + * the iterator), then we would boost. As such our decision to boost
> + * or not is delicately balanced on the order we wait on fences.
> + *
> + * So instead of looking for boosts sequentially, look for all boosts
> + * upfront and then wait on the outstanding fences.
> + */
> +
> + dma_resv_iter_begin(&cursor, resv,
> + dma_resv_usage_rw(flags & I915_WAIT_ALL));
> + dma_resv_for_each_fence_unlocked(&cursor, fence)
> + if (dma_fence_is_i915(fence) &&
> + !i915_request_started(to_request(fence)))
> + intel_rps_boost(to_request(fence));
> + dma_resv_iter_end(&cursor);
> +}
> +
> static long
> i915_gem_object_wait_reservation(struct dma_resv *resv,
>unsigned int flags,
> @@ -40,6 +72,8 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
> struct dma_fence *fence;
> long ret = timeout ?: 1;
>
> + i915_gem_object_boost(resv, flags);
> +
> dma_resv_iter_begin(&cursor, resv,
> dma_resv_usage_rw(flags & I915_WAIT_ALL));
> dma_resv_for_each_fence_unlocked(&cursor, fence)
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/gt: Only kick the signal worker if there's been an update
On Fri, Jul 08, 2022 at 04:20:13PM +0200, Karolina Drobnik wrote:
> From: Chris Wilson
>
> One impact of commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove
> dma_resv workaround") is that it stores many, many more fences. Whereas
> adding an exclusive fence used to remove the shared fence list, that
> list is now preserved and the write fences included into the list. Not
> just a single write fence, but now a write/read fence per context. That
> causes us to have to track more fences than before (albeit half of those
> are redundant), and we trigger more interrupts for multi-engine
> workloads.
>
> As part of reducing the impact from handling more signaling, we observe
> we only need to kick the signal worker after adding a fence iff we have
s/iff/if
> good cause to believe that there is work to be done in processing the
> fence i.e. we either need to enable the interrupt or the request is
> already complete but we don't know if we saw the interrupt and so need
> to check signaling.
>
> References: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
> Signed-off-by: Chris Wilson
> Signed-off-by: Karolina Drobnik
> ---
> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> index 9dc9dccf7b09..ecc990ec1b95 100644
> --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> @@ -399,7 +399,8 @@ static void insert_breadcrumb(struct i915_request *rq)
>* the request as it may have completed and raised the interrupt as
>* we were attaching it into the lists.
>*/
> - irq_work_queue(&b->irq_work);
> + if (!b->irq_armed || __i915_request_is_complete(rq))
would we need the READ_ONCE(irq_armed) ?
would we need to use the irq_lock?
> + irq_work_queue(&b->irq_work);
> }
>
> bool i915_request_enable_breadcrumb(struct i915_request *rq)
> --
> 2.25.1
>
Re: [Intel-gfx] [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl
Hi,
On Fri, 2022-07-08 at 06:47 -0700, Niranjana Vishwanathapura wrote:
> On Thu, Jul 07, 2022 at 07:41:54AM -0700, Hellstrom, Thomas wrote:
> > On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
> > > works in vm_bind mode. The vm_bind mode only works with
> > > this new execbuf3 ioctl.
> > >
> > > The new execbuf3 ioctl will not have any execlist
> >
> > I understand this that you mean there is no list of objects to
> > validate
> > attached to the drm_i915_gem_execbuffer3 structure rather than that
> > the
> > execlists submission backend is never used. Could we clarify this
> > to
> > avoid confusion.
>
> Yah, side effect of overloading the word 'execlist' for multiple
> things.
> Yah, I meant, no list of objects to validate. I agree, we need to
> clarify
> that here.
>
> >
> >
> > > support
> > > and all the legacy support like relocations etc are removed.
> > >
> > > Signed-off-by: Niranjana Vishwanathapura
> > >
> > > ---
> > > drivers/gpu/drm/i915/Makefile | 1 +
> > > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 5 +
> > > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1029
> > > +
> > > drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 +
> > > drivers/gpu/drm/i915/i915_driver.c | 1 +
> > > include/uapi/drm/i915_drm.h | 67 +-
> > > 6 files changed, 1104 insertions(+), 1 deletion(-)
> > > create mode 100644
> > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > b/drivers/gpu/drm/i915/Makefile
> > > index 4e1627e96c6e..38cd1c5bc1a5 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -148,6 +148,7 @@ gem-y += \
> > > gem/i915_gem_dmabuf.o \
> > > gem/i915_gem_domain.o \
> > > gem/i915_gem_execbuffer.o \
> > > + gem/i915_gem_execbuffer3.o \
> > > gem/i915_gem_internal.o \
> > > gem/i915_gem_object.o \
> > > gem/i915_gem_lmem.o \
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index b7b2c14fd9e1..37bb1383ab8f 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -782,6 +782,11 @@ static int eb_select_context(struct
> > > i915_execbuffer *eb)
> > > if (unlikely(IS_ERR(ctx)))
> > > return PTR_ERR(ctx);
> > >
> > > + if (ctx->vm->vm_bind_mode) {
> > > + i915_gem_context_put(ctx);
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > eb->gem_context = ctx;
> > > if (i915_gem_context_has_full_ppgtt(ctx))
> > > eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > new file mode 100644
> > > index ..13121df72e3d
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > @@ -0,0 +1,1029 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2022 Intel Corporation
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#include "gt/intel_context.h"
> > > +#include "gt/intel_gpu_commands.h"
> > > +#include "gt/intel_gt.h"
> > > +#include "gt/intel_gt_pm.h"
> > > +#include "gt/intel_ring.h"
> > > +
> > > +#include "i915_drv.h"
> > > +#include "i915_file_private.h"
> > > +#include "i915_gem_context.h"
> > > +#include "i915_gem_ioctls.h"
> > > +#include "i915_gem_vm_bind.h"
> > > +#include "i915_trace.h"
> > > +
> > > +#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
> > > +#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
> > > +
> > > +/* Catch emission of unexpected errors for CI! */
> > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
> > > +#undef EINVAL
> > > +#define EINVAL ({ \
> > > + DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__,
> > > __LINE__); \
> > > + 22; \
> > > +})
> > > +#endif
> > > +
> > > +/**
> > > + * DOC: User command execution with execbuf3 ioctl
> > > + *
> > > + * A VM in VM_BIND mode will not support older execbuf mode of
> > > binding.
> > > + * The execbuf ioctl handling in VM_BIND mode differs
> > > significantly
> > > from the
> > > + * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
> > > + * Hence, a new execbuf3 ioctl has been added to support VM_BIND
> > > mode. (See
> > > + * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not
> > > accept any
> > > + * execlist. Hence, no support for implicit sync.
> > > + *
> > > + * The new execbuf3 ioctl only works in VM_BIND mode and the
> > > VM_BIND
> > > mode only
> > > + * works with execbuf3 ioctl for submission.
> > > + *
> > > + * The execbuf3 ioctl directly specifies the batch addresses
> >
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Fix TLB invalidate issues with Broadwell (rev4)
On Fri, Jul 08, 2022 at 06:00:52AM -, Patchwork wrote:
>Patch Details
>
>Series: Fix TLB invalidate issues with Broadwell (rev4)
>URL: [1]https://patchwork.freedesktop.org/series/105167/
>State: failure
>Details:
>[2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105167v4/index.ht
>ml
>
> CI Bug Log - changes from CI_DRM_11857_full -> Patchwork_105167v4_full
>
> Summary
>
>FAILURE
>
>Serious unknown changes coming with Patchwork_105167v4_full absolutely
>need to be
>verified manually.
>
>If you think the reported changes have nothing to do with the changes
>introduced in Patchwork_105167v4_full, please notify your bug team to
>allow them
>to document this new failure mode, which will reduce false positives in
>CI.
>
> Participating hosts (13 -> 13)
>
>No changes in participating hosts
>
> Possible new issues
>
>Here are the unknown changes that may have been introduced in
>Patchwork_105167v4_full:
>
> IGT changes
>
> Possible regressions
>
> * igt@i915_selftest@live@perf:
> + shard-skl: [3]PASS -> [4]INCOMPLETE
probably yet another false positive failure, but since the
authorship-vs-sign-off
needs to be fixed and resent we will end up testing it again.
Sorry for not noticing yesterday before I had triggered the retest.
>
> Suppressed
>
>The following results come from untrusted machines, tests, or statuses.
>They do not affect the overall result.
> * igt@gem_busy@close-race:
> + {shard-tglu}: [5]PASS -> [6]INCOMPLETE
> * igt@i915_module_load@reload-no-display:
> + {shard-rkl}: [7]PASS -> [8]FAIL
> * igt@kms_cursor_legacy@cursor-vs-flip@atomic:
> + {shard-dg1}: [9]PASS -> [10]FAIL +4 similar issues
>
> Known issues
>
>Here are the changes found in Patchwork_105167v4_full that come from
>known issues:
>
> CI changes
>
> Possible fixes
>
> * boot:
> + shard-snb: ([11]PASS, [12]PASS, [13]PASS, [14]PASS, [15]PASS,
> [16]PASS, [17]PASS, [18]PASS, [19]PASS, [20]PASS, [21]PASS,
> [22]FAIL, [23]PASS, [24]PASS, [25]PASS, [26]PASS, [27]PASS,
> [28]PASS, [29]PASS, [30]PASS, [31]PASS, [32]PASS, [33]PASS,
> [34]PASS, [35]PASS) ([36]i915#4338) -> ([37]PASS, [38]PASS,
> [39]PASS, [40]PASS, [41]PASS, [42]PASS, [43]PASS, [44]PASS,
> [45]PASS, [46]PASS, [47]PASS, [48]PASS, [49]PASS, [50]PASS,
> [51]PASS, [52]PASS, [53]PASS, [54]PASS, [55]PASS, [56]PASS,
> [57]PASS, [58]PASS, [59]PASS, [60]PASS, [61]PASS)
>
> IGT changes
>
> Issues hit
>
> * igt@gem_ctx_isolation@preservation-s3@bcs0:
> + shard-skl: [62]PASS -> [63]INCOMPLETE ([64]i915#4793)
> * igt@gem_ctx_persistence@hostile:
> + shard-tglb: [65]PASS -> [66]FAIL ([67]i915#2410)
> * igt@gem_ctx_persistence@legacy-engines-queued:
> + shard-snb: NOTRUN -> [68]SKIP ([69]fdo#109271 / [70]i915#1099)
> * igt@gem_eio@unwedge-stress:
> + shard-iclb: [71]PASS -> [72]TIMEOUT ([73]i915#3070)
> * igt@gem_exec_balancer@parallel-bb-first:
> + shard-iclb: [74]PASS -> [75]SKIP ([76]i915#4525)
> * igt@gem_exec_fair@basic-deadline:
> + shard-skl: NOTRUN -> [77]FAIL ([78]i915#6141)
> * igt@gem_exec_fair@basic-none@vcs1:
> + shard-kbl: [79]PASS -> [80]FAIL ([81]i915#2842) +1 similar
> issue
> * igt@gem_exec_fair@basic-pace@bcs0:
> + shard-iclb: [82]PASS -> [83]FAIL ([84]i915#2842)
> * igt@gem_exec_fair@basic-pace@vecs0:
> + shard-glk: [85]PASS -> [86]FAIL ([87]i915#2842)
> * igt@gem_lmem_swapping@heavy-random:
> + shard-kbl: NOTRUN -> [88]SKIP ([89]fdo#109271 / [90]i915#4613)
> * igt@gem_lmem_swapping@smem-oom:
> + shard-apl: NOTRUN -> [91]SKIP ([92]fdo#109271 / [93]i915#4613)
> * igt@gem_lmem_swapping@verify:
> + shard-skl: NOTRUN -> [94]SKIP ([95]fdo#109271 / [96]i915#4613)
> +1 similar issue
> * igt@gem_lmem_swapping@verify-random:
> + shard-glk: NOTRUN -> [97]SKIP ([98]fdo#109271 / [99]i915#4613)
> * igt@gen9_exec_parse@allowed-single:
> + shard-skl: [100]PASS -> [101]DMESG-WARN ([102]i915#5566 /
> [103]i915#716)
> + shard-glk: [104]PASS -> [105]DMESG-WARN ([106]i915#5566 /
> [107]i915#716)
> * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
> + shard-apl: NOTRUN -> [108]SKIP ([109]fdo#109271) +36 similar
> issues
> * igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
> + shard-kbl: NOTRUN -> [110]SKIP ([111]fdo#109271 /
> [112]i915#3886) +1 similar issue
> * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs:
> + shard-skl: NOTRUN -> [113]SKIP ([114]fdo#109271 /
> [115]i915#3886) +3 similar issu
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix TLB invalidate issues with Broadwell (rev4)
On Thu, Jul 07, 2022 at 02:47:57PM -, Patchwork wrote: > == Series Details == > > Series: Fix TLB invalidate issues with Broadwell (rev4) > URL : https://patchwork.freedesktop.org/series/105167/ > State : warning > > == Summary == > > Error: dim sparse failed > Sparse version: v0.6.2 > Fast mode used, each commit won't be checked separately. > - > +drivers/gpu/drm/i915/gt/intel_reset.c:1410:5: warning: context imbalance in > 'intel_gt_reset_trylock' - different lock contexts for basic block I believe this is a false positive, but worth double checking... > >
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix TLB invalidate issues with Broadwell (rev4)
On Thu, Jul 07, 2022 at 02:47:54PM -, Patchwork wrote: > == Series Details == > > Series: Fix TLB invalidate issues with Broadwell (rev4) > URL : https://patchwork.freedesktop.org/series/105167/ > State : warning > > == Summary == > > Error: dim checkpatch failed > 158bc8b5e012 drm/i915/gt: Serialize GRDOM access between multiple engine > resets > -:109: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address > mismatch: 'From: Chris Wilson ' != 'Signed-off-by: > Chris Wilson ' > > total: 0 errors, 1 warnings, 0 checks, 77 lines checked > fa407659e72d drm/i915/gt: Serialize TLB invalidates with GT resets > -:62: ERROR:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch > author 'Chris Wilson ' These need to be fixed. > > total: 1 errors, 0 warnings, 0 checks, 27 lines checked > >
[Intel-gfx] [PATCH v2 3/3] drm/i915/gt: Only kick the signal worker if there's been an update
From: Chris Wilson
One impact of commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove
dma_resv workaround") is that it stores many, many more fences. Whereas
adding an exclusive fence used to remove the shared fence list, that
list is now preserved and the write fences included into the list. Not
just a single write fence, but now a write/read fence per context. That
causes us to have to track more fences than before (albeit half of those
are redundant), and we trigger more interrupts for multi-engine
workloads.
As part of reducing the impact from handling more signaling, we observe
we only need to kick the signal worker after adding a fence iff we have
good cause to believe that there is work to be done in processing the
fence i.e. we either need to enable the interrupt or the request is
already complete but we don't know if we saw the interrupt and so need
to check signaling.
References: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: Chris Wilson
Signed-off-by: Karolina Drobnik
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 9dc9dccf7b09..ecc990ec1b95 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -399,7 +399,8 @@ static void insert_breadcrumb(struct i915_request *rq)
* the request as it may have completed and raised the interrupt as
* we were attaching it into the lists.
*/
- irq_work_queue(&b->irq_work);
+ if (!b->irq_armed || __i915_request_is_complete(rq))
+ irq_work_queue(&b->irq_work);
}
bool i915_request_enable_breadcrumb(struct i915_request *rq)
--
2.25.1
[Intel-gfx] [PATCH v2 2/3] drm/i915: Bump GT idling delay to 2 jiffies
From: Chris Wilson In monitoring a transcode pipeline that is latency sensitive (it waits between submitting frames, and each frame requires work on rcs/vcs/vecs engines), it is found that it took longer than a single jiffy for it to sustain its workload. Allowing an extra jiffy headroom for the userspace prevents us from prematurely parking and having to exit powersaving immediately. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/6284 Signed-off-by: Chris Wilson Signed-off-by: Karolina Drobnik Reviewed-by: Rodrigo Vivi Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/i915_active.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index ee2b3a375362..7412abf166a8 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -974,7 +974,7 @@ void i915_active_acquire_barrier(struct i915_active *ref) GEM_BUG_ON(!intel_engine_pm_is_awake(engine)); llist_add(barrier_to_ll(node), &engine->barrier_tasks); - intel_engine_pm_put_delay(engine, 1); + intel_engine_pm_put_delay(engine, 2); } } -- 2.25.1
[Intel-gfx] [PATCH v2 0/3] drm/i915: Apply waitboosting before fence wait
Waitboost is a heuristic that detects latency sensitive workloads waiting for
the results from previous execution. The wait can be seen as GPU
under-utilisation by RPS, Render Power State management, which might lower the
GPU frequency to save power. Limiting the frequency means more waiting for
results, which is undesirable for submissions with tight time constraints.
To circumvent this, with waitboost we iteratively check the list of fences
during gem_wait to see if any of them is stalled waiting for GPU. If such is
found, and the request hasn't yet started its execution, we temporarily bump up
the GPU frequency, so we get the required results as soon as possible.
Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround") changes
the fences order and how they are iterated. Under this new scheme, we would wait
on each fence that starts executing, rendering them not suitable for waitboost.
To avoid situation like this, inspect the entire list of fences dma-resv
earlier, before gem_wait, instead of sequentially waiting for each of them,
applying the boost when needed.
v2:
- Fixed a style issue in i915_gem_object_boost
Chris Wilson (3):
drm/i915/gem: Look for waitboosting across the whole object prior to
individual waits
drm/i915: Bump GT idling delay to 2 jiffies
drm/i915/gt: Only kick the signal worker if there's been an update
drivers/gpu/drm/i915/gem/i915_gem_wait.c| 34 +
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 +-
drivers/gpu/drm/i915/i915_active.c | 2 +-
3 files changed, 37 insertions(+), 2 deletions(-)
--
2.25.1
[Intel-gfx] [PATCH v2 1/3] drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
From: Chris Wilson
We employ a "waitboost" heuristic to detect when userspace is stalled
waiting for results from earlier execution. Under latency sensitive work
mixed between the gpu/cpu, the GPU is typically under-utilised and so
RPS sees that low utilisation as a reason to downclock the frequency,
causing longer stalls and lower throughput. The user left waiting for
the results is not impressed.
On applying commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv
workaround") it was observed that deinterlacing h264 on Haswell
performance dropped by 2-5x. The reason being that the natural workload
was not intense enough to trigger RPS (using HW evaluation intervals) to
upclock, and so it was depending on waitboosting for the throughput.
Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
changes the composition of dma-resv from keeping a single write fence +
multiple read fences, to a single array of multiple write and read
fences (a maximum of one pair of write/read fences per context). The
iteration order was also changed implicitly from all-read fences then
the single write fence, to a mix of write fences followed by read
fences. It is that ordering change that belied the fragility of
waitboosting.
Currently, a waitboost is inspected at the point of waiting on an
outstanding fence. If the GPU is backlogged such that we haven't yet
stated the request we need to wait on, we force the GPU to upclock until
the completion of that request. By changing the order in which we waited
upon requests, we ended up waiting on those requests in sequence and as
such we saw that each request was already started and so not a suitable
candidate for waitboosting.
Instead of asking whether to boost each fence in turn, we can look at
whether boosting is required for the dma-resv ensemble prior to waiting
on any fence, making the heuristic more robust to the order in which
fences are stored in the dma-resv.
Reported-by: Thomas Voegtle
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6284
Fixes: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Karolina Drobnik
Tested-by: Thomas Voegtle
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 319936f91ac5..e6e01c2a74a6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -9,6 +9,7 @@
#include
#include "gt/intel_engine.h"
+#include "gt/intel_rps.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
@@ -31,6 +32,37 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
timeout);
}
+static void
+i915_gem_object_boost(struct dma_resv *resv, unsigned int flags)
+{
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
+
+ /*
+* Prescan all fences for potential boosting before we begin waiting.
+*
+* When we wait, we wait on outstanding fences serially. If the
+* dma-resv contains a sequence such as 1:1, 1:2 instead of a reduced
+* form 1:2, then as we look at each wait in turn we see that each
+* request is currently executing and not worthy of boosting. But if
+* we only happen to look at the final fence in the sequence (because
+* of request coalescing or splitting between read/write arrays by
+* the iterator), then we would boost. As such our decision to boost
+* or not is delicately balanced on the order we wait on fences.
+*
+* So instead of looking for boosts sequentially, look for all boosts
+* upfront and then wait on the outstanding fences.
+*/
+
+ dma_resv_iter_begin(&cursor, resv,
+ dma_resv_usage_rw(flags & I915_WAIT_ALL));
+ dma_resv_for_each_fence_unlocked(&cursor, fence)
+ if (dma_fence_is_i915(fence) &&
+ !i915_request_started(to_request(fence)))
+ intel_rps_boost(to_request(fence));
+ dma_resv_iter_end(&cursor);
+}
+
static long
i915_gem_object_wait_reservation(struct dma_resv *resv,
unsigned int flags,
@@ -40,6 +72,8 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
struct dma_fence *fence;
long ret = timeout ?: 1;
+ i915_gem_object_boost(resv, flags);
+
dma_resv_iter_begin(&cursor, resv,
dma_resv_usage_rw(flags & I915_WAIT_ALL));
dma_resv_for_each_fence_unlocked(&cursor, fence) {
--
2.25.1
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
Hi Andi,
On 08.07.2022 13:38, Andi Shyti wrote:
Hi Karolina,
[...]
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ if (dma_fence_is_i915(fence) &&
+ !i915_request_started(to_request(fence)))
+ intel_rps_boost(to_request(fence));
+ }
you can remove the brackets here.
Andi
Would you like me to send v2 for it?
if the committer takes care of removing it, then no need,
otherwise, please yes, resend it. Even if it's a stupid nitpick,
if it gets applied it would be very difficult to get it fixed[*].
Didn't checkpatch.pl complain about it?
Right, thanks for explaining this. checkpatch.pl only complained about
unwrapped References tag (a false positive), but I can delete the braces
and resend the patchset.
If you are going to resend it, you can add my:
Reviewed-by: Andi Shyti
also here.
OK, will so do, thanks
All the best,
Karolina
Thanks,
Andi
[*] Because just minor coding style patches are generally
rejected, the only way for fixing style issues would be if:
1. someone is working in that part of the code
2. someone will sneak in the code fix in some unrelated patch
screwing up git blame
3. someone will send a big series on this file and have some
trivial coding style patches in it.
Amongst the three above, number '2' is the one I dislike the
most, but unfortunately that's also the most used.
Re: [Intel-gfx] [PATCH] drm/i915/ttm: fix sg_table construction
On 7/8/2022 9:41 AM, Matthew Auld wrote:
If we encounter some monster sized local-memory page that exceeds the
maximum sg length (UINT32_MAX), ensure that don't end up with some
misaligned address in the entry that follows, leading to fireworks
later. Also ensure we have some coverage of this in the selftests.
v2(Chris): use round_down consistently to avoid udiv errors
Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +--
drivers/gpu/drm/i915/i915_scatterlist.c | 19 +++
drivers/gpu/drm/i915/i915_scatterlist.h | 6 --
drivers/gpu/drm/i915/intel_region_ttm.c | 10 +++---
drivers/gpu/drm/i915/intel_region_ttm.h | 3 ++-
.../drm/i915/selftests/intel_memory_region.c | 17 -
drivers/gpu/drm/i915/selftests/mock_region.c | 3 ++-
7 files changed, 55 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 7e1f8b83077f..c5c8aa1f8558 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -602,10 +602,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct ttm_resource *res)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ u64 page_alignment;
if (!i915_ttm_gtt_binds_lmem(res))
return i915_ttm_tt_get_st(bo->ttm);
+ page_alignment = bo->page_alignment << PAGE_SHIFT;
+ if (!page_alignment)
+ page_alignment = obj->mm.region->min_page_size;
+
/*
* If CPU mapping differs, we need to add the ttm_tt pages to
* the resulting st. Might make sense for GGTT.
@@ -616,7 +621,8 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct i915_refct_sgt *rsgt;
rsgt = intel_region_ttm_resource_to_rsgt(obj->mm.region,
-res);
+res,
+
page_alignment);
if (IS_ERR(rsgt))
return rsgt;
@@ -625,7 +631,8 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
return i915_refct_sgt_get(obj->ttm.cached_io_rsgt);
}
- return intel_region_ttm_resource_to_rsgt(obj->mm.region, res);
+ return intel_region_ttm_resource_to_rsgt(obj->mm.region, res,
+page_alignment);
}
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 159571b9bd24..f63b50b71e10 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -68,6 +68,7 @@ void i915_refct_sgt_init(struct i915_refct_sgt *rsgt, size_t
size)
* drm_mm_node
* @node: The drm_mm_node.
* @region_start: An offset to add to the dma addresses of the sg list.
+ * @page_alignment: Required page alignment for each sg entry. Power of two.
*
* Create a struct sg_table, initializing it from a struct drm_mm_node,
* taking a maximum segment length into account, splitting into segments
@@ -77,15 +78,18 @@ void i915_refct_sgt_init(struct i915_refct_sgt *rsgt,
size_t size)
* error code cast to an error pointer on failure.
*/
struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct drm_mm_node *node,
- u64 region_start)
+ u64 region_start,
+ u64 page_alignment)
{
- const u64 max_segment = SZ_1G; /* Do we have a limit on this? */
+ const u64 max_segment = round_down(UINT_MAX, page_alignment);
u64 segment_pages = max_segment >> PAGE_SHIFT;
u64 block_size, offset, prev_end;
struct i915_refct_sgt *rsgt;
struct sg_table *st;
struct scatterlist *sg;
+ GEM_BUG_ON(!max_segment);
+
rsgt = kmalloc(sizeof(*rsgt), GFP_KERNEL);
if (!rsgt)
return ERR_PTR(-ENOMEM);
@@ -112,6 +116,8 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
sg = __sg_next(sg);
sg_dma_address(sg) = region_start + offset;
+ GEM_BUG_ON(!IS_ALIGNED(sg_dma_address(sg),
+ page_alignment));
sg_dma_len(sg) = 0;
sg->length = 0;
st->nents++;
@@ -138,6 +144,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
* i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: fix a couple IS_ERR() vs NULL tests (rev2)
== Series Details ==
Series: drm/i915/selftests: fix a couple IS_ERR() vs NULL tests (rev2)
URL : https://patchwork.freedesktop.org/series/106093/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862 -> Patchwork_106093v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/index.html
Participating hosts (45 -> 41)
--
Missing(4): fi-ctg-p8600 fi-rkl-11600 fi-icl-u2 fi-hsw-4200u
Known issues
Here are the changes found in Patchwork_106093v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@load:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-kbl-soraka/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/fi-kbl-soraka/igt@i915_module_l...@load.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][3] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/fi-pnv-d510/igt@i915_selftest@l...@gem.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][4] -> [FAIL][5] ([i915#6298])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-adln-1}: [DMESG-WARN][6] ([i915#6297]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adln-1/igt@i915_module_l...@reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/bat-adln-1/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][8] ([i915#4494] / [i915#4957]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][10] ([i915#4528]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][12] ([i915#3576]) -> [PASS][13] +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@vgem_basic@setversion:
- fi-kbl-soraka: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11862/fi-kbl-soraka/igt@vgem_ba...@setversion.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/fi-kbl-soraka/igt@vgem_ba...@setversion.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
[i915#6297]: https://gitlab.freedesktop.org/drm/intel/issues/6297
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
Build changes
-
* Linux: CI_DRM_11862 -> Patchwork_106093v2
CI-20190529: 20190529
CI_DRM_11862: ffee806d103b9604db7eb9cd689c098aca1ffa96 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6563: 7d43b49bf10788d4870668f93a800888fc8ab339 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_106093v2: ffee806d103b9604db7eb9cd689c098aca1ffa96 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
e6f3f9fc9c2b drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v2/index.html
Re: [Intel-gfx] [PATCH v5 00/14] GSC support for XeHP SDV and DG2 platforms
On Fri, Jul 08, 2022 at 03:34:43PM +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 06, 2022 at 02:43:31PM +0300, Alexander Usyskin wrote: > > Add GSC support for XeHP SDV and DG2 platforms. > > > > The series includes changes for the mei driver: > > - add ability to use polling instead of interrupts > > - add ability to use extended timeouts > > - setup extended operational memory for GSC > > > > The series includes changes for the i915 driver: > > - allocate extended operational memory for GSC > > - GSC on XeHP SDV offsets and definitions > > > > Greg KH, please review and ACK the MEI patches. > > We are pushing these patches through gfx tree as > > the auxiliary device belongs there. > > > > V2: rebase over merged DG1 series and DG2 enablement patch, > > fix commit messages > > > > V3: rebase over latest tip > > > > V4: add missed changelog in pxp dbugfs patch > > > > V5: rebase over latest tip > > fix changelog in pxp dbugfs patch > > put HAX patch last to the ease of merging > > You did more than just this from v4 to v5 :( > > It's as if you want to make it hard to review these... I just checked the code and it looks the same to me. well, yeap, changing the order of other commits during the rebase was not mentioned. So we don't know the reason... But at least now the HAX is the last patch what makes more sense. But I don't believe this should block the review and require a v6 just to add this comment in the cover letter, or it should? Rodrigo. > > greg k-h
Re: [Intel-gfx] [PATCH 6/6] drm/ttm: stop allocating a dummy resource for pipelined gutting
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 6/6] drm/ttm: stop allocating a dummy resource for pipelined
>gutting
>
>That should not be necessary any more when drivers should at least be
>able to handle a move without a resource.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 1530982338e9..1e76149c62ff 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -603,16 +603,10 @@ EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
> */
> int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
> {
>- static const struct ttm_place sys_mem = { .mem_type =
>TTM_PL_SYSTEM };
> struct ttm_buffer_object *ghost;
>- struct ttm_resource *sys_res;
> struct ttm_tt *ttm;
> int ret;
>
>- ret = ttm_resource_alloc(bo, &sys_mem, &sys_res);
>- if (ret)
>- return ret;
>-
> /* If already idle, no need for ghost object dance. */
> ret = ttm_bo_wait(bo, false, true);
> if (ret != -EBUSY) {
>@@ -620,14 +614,13 @@ int ttm_bo_pipeline_gutting(struct
>ttm_buffer_object *bo)
> /* See comment below about clearing. */
> ret = ttm_tt_create(bo, true);
> if (ret)
>- goto error_free_sys_mem;
>+ return ret;
> } else {
> ttm_tt_unpopulate(bo->bdev, bo->ttm);
> if (bo->type == ttm_bo_type_device)
> ttm_tt_mark_for_clear(bo->ttm);
> }
> ttm_resource_free(bo, &bo->resource);
>- ttm_bo_assign_mem(bo, sys_res);
> return 0;
> }
>
>@@ -644,7 +637,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object
>*bo)
> ret = ttm_tt_create(bo, true);
> swap(bo->ttm, ttm);
> if (ret)
>- goto error_free_sys_mem;
>+ return ret;
>
> ret = ttm_buffer_object_transfer(bo, &ghost);
> if (ret)
>@@ -658,13 +651,9 @@ int ttm_bo_pipeline_gutting(struct
>ttm_buffer_object *bo)
> dma_resv_unlock(&ghost->base._resv);
> ttm_bo_put(ghost);
> bo->ttm = ttm;
>- ttm_bo_assign_mem(bo, sys_res);
> return 0;
>
> error_destroy_tt:
> ttm_tt_destroy(bo->bdev, ttm);
>-
>-error_free_sys_mem:
>- ttm_resource_free(bo, &sys_res);
> return ret;
> }
>--
>2.25.1
Re: [Intel-gfx] [PATCH 5/6] drm/ttm: stop allocating dummy resources during BO creation
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 5/6] drm/ttm: stop allocating dummy resources during BO
>creation
>
>That should not be necessary any more when drivers should at least be
>able to handle the move without a resource.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
> 1 file changed, 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index a2f49bdda8a1..f491be751a2f 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -960,7 +960,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>struct ttm_buffer_object *bo,
>struct sg_table *sg, struct dma_resv *resv,
>void (*destroy) (struct ttm_buffer_object *))
> {
>- static const struct ttm_place sys_mem = { .mem_type =
>TTM_PL_SYSTEM };
> int ret;
>
> kref_init(&bo->kref);
>@@ -978,12 +977,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>struct ttm_buffer_object *bo,
> bo->base.resv = &bo->base._resv;
> atomic_inc(&ttm_glob.bo_count);
>
>- ret = ttm_resource_alloc(bo, &sys_mem, &bo->resource);
>- if (unlikely(ret)) {
>- ttm_bo_put(bo);
>- return ret;
>- }
>-
> /*
>* For ttm_bo_type_device buffers, allocate
>* address space from the device.
>--
>2.25.1
Re: [Intel-gfx] [PATCH 4/6] drm/ttm: audit bo->resource usage v2
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 4/6] drm/ttm: audit bo->resource usage v2
>
>Allow BOs to exist without backing store.
>
>v2: handle ttm_bo_move_memcpy as well.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/ttm/ttm_bo.c | 16
> drivers/gpu/drm/ttm/ttm_bo_util.c | 7 +--
> 2 files changed, 13 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index 984535d6a2d0..a2f49bdda8a1 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -117,12 +117,13 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> struct ttm_operation_ctx *ctx,
> struct ttm_place *hop)
> {
>- struct ttm_resource_manager *old_man, *new_man;
> struct ttm_device *bdev = bo->bdev;
>+ bool old_use_tt, new_use_tt;
> int ret;
>
>- old_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- new_man = ttm_manager_type(bdev, mem->mem_type);
>+ old_use_tt = bo->resource &&
>+ ttm_manager_type(bdev, bo->resource->mem_type)-
>>use_tt;
>+ new_use_tt = ttm_manager_type(bdev, mem->mem_type)->use_tt;
>
> ttm_bo_unmap_virtual(bo);
>
>@@ -130,11 +131,11 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
>* Create and bind a ttm if required.
>*/
>
>- if (new_man->use_tt) {
>+ if (new_use_tt) {
> /* Zero init the new TTM structure if the old location should
>* have used one as well.
>*/
>- ret = ttm_tt_create(bo, old_man->use_tt);
>+ ret = ttm_tt_create(bo, old_use_tt);
> if (ret)
> goto out_err;
>
>@@ -160,8 +161,7 @@ static int ttm_bo_handle_move_mem(struct
>ttm_buffer_object *bo,
> return 0;
>
> out_err:
>- new_man = ttm_manager_type(bdev, bo->resource->mem_type);
>- if (!new_man->use_tt)
>+ if (!old_use_tt)
> ttm_bo_tt_destroy(bo);
>
> return ret;
>@@ -904,7 +904,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> /*
>* Check whether we need to move buffer.
>*/
>- if (!ttm_resource_compat(bo->resource, placement)) {
>+ if (!bo->resource || !ttm_resource_compat(bo->resource,
>placement)) {
> ret = ttm_bo_move_buffer(bo, placement, ctx);
> if (ret)
> return ret;
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index 1cbfb00c1d65..1530982338e9 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -137,8 +137,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
>*bo,
> ttm_manager_type(bo->bdev, dst_mem->mem_type);
> struct ttm_tt *ttm = bo->ttm;
> struct ttm_resource *src_mem = bo->resource;
>- struct ttm_resource_manager *src_man =
>- ttm_manager_type(bdev, src_mem->mem_type);
>+ struct ttm_resource_manager *src_man;
> union {
> struct ttm_kmap_iter_tt tt;
> struct ttm_kmap_iter_linear_io io;
>@@ -147,6 +146,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
>*bo,
> bool clear;
> int ret = 0;
>
>+ if (!src_mem)
>+ return 0;
>+
>+ src_man = ttm_manager_type(bdev, src_mem->mem_type);
> if (ttm && ((ttm->page_flags & TTM_TT_FLAG_SWAPPED) ||
> dst_man->use_tt)) {
> ret = ttm_tt_populate(bdev, ttm, ctx);
>--
>2.25.1
Re: [Intel-gfx] [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl
On Thu, Jul 07, 2022 at 07:41:54AM -0700, Hellstrom, Thomas wrote:
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any execlist
I understand this that you mean there is no list of objects to validate
attached to the drm_i915_gem_execbuffer3 structure rather than that the
execlists submission backend is never used. Could we clarify this to
avoid confusion.
Yah, side effect of overloading the word 'execlist' for multiple things.
Yah, I meant, no list of objects to validate. I agree, we need to clarify
that here.
support
and all the legacy support like relocations etc are removed.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile |1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c|5 +
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 1029
+
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|2 +
drivers/gpu/drm/i915/i915_driver.c|1 +
include/uapi/drm/i915_drm.h | 67 +-
6 files changed, 1104 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile
index 4e1627e96c6e..38cd1c5bc1a5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b7b2c14fd9e1..37bb1383ab8f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -782,6 +782,11 @@ static int eb_select_context(struct
i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
+ if (ctx->vm->vm_bind_mode) {
+ i915_gem_context_put(ctx);
+ return -EOPNOTSUPP;
+ }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..13121df72e3d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,1029 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_file_private.h"
+#include "i915_gem_context.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of
binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly
from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND
mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not
accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND
mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead
of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also
not
+ * support many of the older features like in/out/submit fences,
fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user
instead of
+ * the i915 driver. Hence all VA assignment, eviction are not
applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND
mode will not
+ * be using the i915_vma active reference tracking. It will instead
check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA
evictions,
+ * vma lookup table, implicit sync, vma active reference tracking
etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+struct eb_fence {
+ str
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] i915/perf: Replace DRM_DEBUG with driver specific drm_dbg call
== Series Details ==
Series: series starting with [1/2] i915/perf: Replace DRM_DEBUG with driver
specific drm_dbg call
URL : https://patchwork.freedesktop.org/series/106062/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11857_full -> Patchwork_106062v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106062v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106062v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106062v1_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- shard-apl: [PASS][1] -> [WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
* igt@i915_selftest@live@slpc:
- shard-skl: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-skl7/igt@i915_selftest@l...@slpc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-skl6/igt@i915_selftest@l...@slpc.html
* igt@kms_async_flips@test-time-stamp@pipe-a-edp-1:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglb1/igt@kms_async_flips@test-time-st...@pipe-a-edp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-tglb8/igt@kms_async_flips@test-time-st...@pipe-a-edp-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_busy@close-race:
- {shard-tglu}: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-2/igt@gem_b...@close-race.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106062v1/shard-tglu-4/igt@gem_b...@close-race.html
Known issues
Here are the changes found in Patchwork_106062v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-snb: ([PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [FAIL][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33]) ([i915#4338]) -> ([PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47],
[PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53],
[PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[29]:
h
Re: [Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs
On Fri, 2022-07-08 at 06:14 -0700, Niranjana Vishwanathapura wrote:
> On Thu, Jul 07, 2022 at 03:31:42AM -0700, Hellstrom, Thomas wrote:
> > On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > > Add uapi allowing user to specify a BO as private to a specified
> > > VM
> > > during the BO creation.
> > > VM private BOs can only be mapped on the specified VM and can't
> > > be
> > > dma_buf exported. VM private BOs share a single common dma_resv
> > > object,
> > > hence has a performance advantage requiring a single dma_resv
> > > object
> > > update in the execbuf path compared to non-private (shared) BOs.
> > >
> > > Signed-off-by: Niranjana Vishwanathapura
> > >
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_create.c | 41
> > > ++-
> > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +++
> > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ++
> > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++
> > > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 11 +
> > > .../drm/i915/gem/i915_gem_vm_bind_object.c | 9
> > > drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++
> > > drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
> > > drivers/gpu/drm/i915/i915_vma.c | 1 +
> > > drivers/gpu/drm/i915/i915_vma_types.h | 2 +
> > > include/uapi/drm/i915_drm.h | 30
> > > ++
> > > 11 files changed, 110 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > > index 927a87e5ec59..7e264566b51f 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > > @@ -11,6 +11,7 @@
> > > #include "pxp/intel_pxp.h"
> > >
> > > #include "i915_drv.h"
> > > +#include "i915_gem_context.h"
> > > #include "i915_gem_create.h"
> > > #include "i915_trace.h"
> > > #include "i915_user_extensions.h"
> > > @@ -243,6 +244,7 @@ struct create_ext {
> > > unsigned int n_placements;
> > > unsigned int placement_mask;
> > > unsigned long flags;
> > > + u32 vm_id;
> > > };
> > >
> > > static void repr_placements(char *buf, size_t size,
> > > @@ -392,9 +394,24 @@ static int ext_set_protected(struct
> > > i915_user_extension __user *base, void *data
> > > return 0;
> > > }
> > >
> > > +static int ext_set_vm_private(struct i915_user_extension __user
> > > *base,
> > > + void *data)
> > > +{
> > > + struct drm_i915_gem_create_ext_vm_private ext;
> > > + struct create_ext *ext_data = data;
> > > +
> > > + if (copy_from_user(&ext, base, sizeof(ext)))
> > > + return -EFAULT;
> > > +
> > > + ext_data->vm_id = ext.vm_id;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static const i915_user_extension_fn create_extensions[] = {
> > > [I915_GEM_CREATE_EXT_MEMORY_REGIONS] =
> > > ext_set_placements,
> > > [I915_GEM_CREATE_EXT_PROTECTED_CONTENT] =
> > > ext_set_protected,
> > > + [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
> > > };
> > >
> > > /**
> > > @@ -410,6 +427,7 @@ i915_gem_create_ext_ioctl(struct drm_device
> > > *dev,
> > > void *data,
> > > struct drm_i915_private *i915 = to_i915(dev);
> > > struct drm_i915_gem_create_ext *args = data;
> > > struct create_ext ext_data = { .i915 = i915 };
> > > + struct i915_address_space *vm = NULL;
> > > struct drm_i915_gem_object *obj;
> > > int ret;
> > >
> > > @@ -423,6 +441,12 @@ i915_gem_create_ext_ioctl(struct drm_device
> > > *dev, void *data,
> > > if (ret)
> > > return ret;
> > >
> > > + if (ext_data.vm_id) {
> > > + vm = i915_gem_vm_lookup(file->driver_priv,
> > > ext_data.vm_id);
> > > + if (unlikely(!vm))
> > > + return -ENOENT;
> > > + }
> > > +
> > > if (!ext_data.n_placements) {
> > > ext_data.placements[0] =
> > > intel_memory_region_by_type(i915,
> > > INTEL_MEMORY_SYSTEM);
> > > @@ -449,8 +473,21 @@ i915_gem_create_ext_ioctl(struct drm_device
> > > *dev, void *data,
> > >
> > > ext_data.placements,
> > >
> > > ext_data.n_placements
> > > ,
> > > ext_data.flags);
> > > - if (IS_ERR(obj))
> > > - return PTR_ERR(obj);
> > > + if (IS_ERR(obj)) {
> > > + ret = PTR_ERR(obj);
> > > + goto vm_put;
> > > + }
> > > +
> > > + if (vm) {
> > > + obj->base.resv = vm->root_obj->base.resv;
> > > + obj->priv_root = i915_gem_object_get(vm-
> > > >root_obj);
> > > + i915_vm_put(vm);
> > > + }
> > >
> > > return i915_gem_publish(obj,
Re: [Intel-gfx] [PATCH 3/6] drm/nouveau: audit bo->resource usage
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 3/6] drm/nouveau: audit bo->resource usage
>
>Make sure we can at least move and release BOs without backing store.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 92cd19021084..f83fb43b2e44 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1006,7 +1006,8 @@ nouveau_bo_move(struct ttm_buffer_object *bo,
>bool evict,
> }
>
> /* Fake bo copy. */
>- if (old_reg->mem_type == TTM_PL_SYSTEM && !bo->ttm) {
>+ if (!old_reg || (old_reg->mem_type == TTM_PL_SYSTEM &&
>+ !bo->ttm)) {
> ttm_bo_move_null(bo, new_reg);
> goto out;
> }
>--
>2.25.1
Re: [Intel-gfx] [PATCH v5 00/14] GSC support for XeHP SDV and DG2 platforms
On Wed, Jul 06, 2022 at 02:43:31PM +0300, Alexander Usyskin wrote: > Add GSC support for XeHP SDV and DG2 platforms. > > The series includes changes for the mei driver: > - add ability to use polling instead of interrupts > - add ability to use extended timeouts > - setup extended operational memory for GSC > > The series includes changes for the i915 driver: > - allocate extended operational memory for GSC > - GSC on XeHP SDV offsets and definitions > > Greg KH, please review and ACK the MEI patches. > We are pushing these patches through gfx tree as > the auxiliary device belongs there. > > V2: rebase over merged DG1 series and DG2 enablement patch, > fix commit messages > > V3: rebase over latest tip > > V4: add missed changelog in pxp dbugfs patch > > V5: rebase over latest tip > fix changelog in pxp dbugfs patch > put HAX patch last to the ease of merging You did more than just this from v4 to v5 :( It's as if you want to make it hard to review these... greg k-h
Re: [Intel-gfx] [PATCH 2/6] drm/amdgpu: audit bo->resource usage
>-Original Message-
>From: Intel-gfx On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [Intel-gfx] [PATCH 2/6] drm/amdgpu: audit bo->resource usage
>
>Make sure we can at least move and release BOs without backing store.
>
>Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
M
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index d9cfe259f2a9..677d1dfab37f 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -1305,7 +1305,7 @@ void amdgpu_bo_release_notify(struct
>ttm_buffer_object *bo)
> if (bo->base.resv == &bo->base._resv)
> amdgpu_amdkfd_remove_fence_on_pt_pd_bos(abo);
>
>- if (bo->resource->mem_type != TTM_PL_VRAM ||
>+ if (!bo->resource || bo->resource->mem_type != TTM_PL_VRAM ||
> !(abo->flags &
>AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE) ||
> adev->in_suspend || adev->shutdown)
> return;
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index be6f76a30ac6..3bddf266e8b5 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -471,7 +471,8 @@ static int amdgpu_bo_move(struct ttm_buffer_object
>*bo, bool evict,
>
> adev = amdgpu_ttm_adev(bo->bdev);
>
>- if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
>+ if (!old_mem || (old_mem->mem_type == TTM_PL_SYSTEM &&
>+ bo->ttm == NULL)) {
> ttm_bo_move_null(bo, new_mem);
> goto out;
> }
>--
>2.25.1
Re: [Intel-gfx] [PATCH v10 04/11] drm/i915/gem: selftest should not attempt mmap of private regions
On 08/07/2022 14:27, Matthew Auld wrote:
On 08/07/2022 14:22, Robert Beckett wrote:
On 08/07/2022 08:53, Matthew Auld wrote:
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip
the mman tests for stolen") ?
huh, I guess not. That wasn't in my tree. I guess I should rebase.
Looking at it, my patch would have been preferable initially I think.
Each location of the additional checks in that patch first call
cam_mmap(), which I think is the most appropriate place to make the
decision.
It fails at the object_create() I think (on small-BAR I mean), which is
before we can call can_mmap(), passing in the object.
ah, okay. That makes sense to keep as is then.
I'll drop this patch.
Thanks.
I could do a replacement patch that reverts that one if preferred, or
we can leave it as is and I will drop this patch.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..76181e28c75e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object
*obj, enum i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
+ if (obj->mm.region && obj->mm.region->private)
+ return false;
+
if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
Re: [Intel-gfx] [PATCH 1/6] drm/ttm: rename and cleanup ttm_bo_init_reserved
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, July 7, 2022 6:25 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
>Cc: Christian König
>Subject: [PATCH 1/6] drm/ttm: rename and cleanup ttm_bo_init_reserved
>
>Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
>matches what the function is actually doing.
>
>Remove the unused size parameter, move the function's kerneldoc to the
>implementation and cleanup the whole error handling.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/drm_gem_vram_helper.c | 6 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 147 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 +-
> include/drm/ttm/ttm_bo_api.h | 93 ++---
> 9 files changed, 129 insertions(+), 150 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>index 2c82b1d5a0d7..d9cfe259f2a9 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>@@ -591,7 +591,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
> if (!bp->destroy)
> bp->destroy = &amdgpu_bo_destroy;
>
>- r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp-
>>type,
>+ r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, bp->type,
>&bo->placement, page_align, &ctx, NULL,
>bp->resv, bp->destroy);
> if (unlikely(r != 0))
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index d607043716d3..125160b534be 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -226,9 +226,9 @@ struct drm_gem_vram_object
>*drm_gem_vram_create(struct drm_device *dev,
>* A failing ttm_bo_init will call ttm_buffer_object_destroy
>* to release gbo->bo.base and kfree gbo.
>*/
>- ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device,
>-&gbo->placement, pg_align, false, NULL, NULL,
>-ttm_buffer_object_destroy);
>+ ret = ttm_bo_init_validate(bdev, &gbo->bo, ttm_bo_type_device,
>+ &gbo->placement, pg_align, false, NULL,
>NULL,
>+ ttm_buffer_object_destroy);
> if (ret)
> return ERR_PTR(ret);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>index 4c25d9b2f138..70e2ed4e99df 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>@@ -1229,9 +1229,8 @@ int __i915_gem_ttm_object_init(struct
>intel_memory_region *mem,
>* Similarly, in delayed_destroy, we can't call ttm_bo_put()
>* until successful initialization.
>*/
>- ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj),
>size,
>- bo_type, &i915_sys_placement,
>- page_size >> PAGE_SHIFT,
>+ ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj),
>bo_type,
>+ &i915_sys_placement, page_size >>
>PAGE_SHIFT,
> &ctx, NULL, NULL, i915_ttm_bo_destroy);
> if (ret)
> return i915_ttm_err_to_gem(ret);
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 05076e530e7d..92cd19021084 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -307,9 +307,9 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size,
>int align, u32 domain,
> nouveau_bo_placement_set(nvbo, domain, 0);
> INIT_LIST_HEAD(&nvbo->io_reserve_lru);
>
>- ret = ttm_bo_init(nvbo->bo.bdev, &nvbo->bo, size, type,
>-&nvbo->placement, align >> PAGE_SHIFT, false, sg,
>-robj, nouveau_bo_del_ttm);
>+ ret = ttm_bo_init_validate(nvbo->bo.bdev, &nvbo->bo, type,
>+ &nvbo->placement, align >> PAGE_SHIFT,
>false,
>+ sg, robj, nouveau_bo_del_ttm);
> if (ret) {
> /* ttm will call nouveau_bo_del_ttm if it fails.. */
> return ret;
>diff --git a/drivers/gpu/drm/qxl/qxl_object.c
>b/drivers/gpu/drm/qxl/qxl_object.c
>index b42a657e4c2f..695d9308d1f0 100644
>--- a/drivers/gpu/drm/qxl/qxl_object.c
>+++ b/drivers/gpu/drm/qxl/qxl_object.c
>@@ -141,7 +141,7 @@ int qxl_bo_create(struct qxl_device *qdev, unsigned
>long size,
>
Re: [Intel-gfx] [PATCH v10 04/11] drm/i915/gem: selftest should not attempt mmap of private regions
On 08/07/2022 14:22, Robert Beckett wrote:
On 08/07/2022 08:53, Matthew Auld wrote:
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip
the mman tests for stolen") ?
huh, I guess not. That wasn't in my tree. I guess I should rebase.
Looking at it, my patch would have been preferable initially I think.
Each location of the additional checks in that patch first call
cam_mmap(), which I think is the most appropriate place to make the
decision.
It fails at the object_create() I think (on small-BAR I mean), which is
before we can call can_mmap(), passing in the object.
I could do a replacement patch that reverts that one if preferred, or we
can leave it as is and I will drop this patch.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..76181e28c75e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object
*obj, enum i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
+ if (obj->mm.region && obj->mm.region->private)
+ return false;
+
if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
Re: [Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs
On Thu, Jul 07, 2022 at 03:27:43PM +0200, Christian König wrote:
Am 02.07.22 um 00:50 schrieb Niranjana Vishwanathapura:
Add uapi allowing user to specify a BO as private to a specified VM
during the BO creation.
VM private BOs can only be mapped on the specified VM and can't be
dma_buf exported. VM private BOs share a single common dma_resv object,
hence has a performance advantage requiring a single dma_resv object
update in the execbuf path compared to non-private (shared) BOs.
Sounds like you picked up the per VM BO idea from amdgpu here :)
Of hand looks like a good idea, but shouldn't we add a few comments in
the common documentation about that?
E.g. something like "Multiple buffer objects sometimes share the same
dma_resv object." to the dma_resv documentation.
Probably best as a separate patch after this here has landed.
:)
Sounds good. Probably we need to update documentation of
drm_gem_object.resv and drm_gem_object._resv here, right?
Doing it in a separate patch after this series lands sounds good to me.
Thanks,
Niranjana
Regards,
Christian.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_create.c| 41 ++-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 11 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 9
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
include/uapi/drm/i915_drm.h | 30 ++
11 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 927a87e5ec59..7e264566b51f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
@@ -243,6 +244,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+ u32 vm_id;
};
static void repr_placements(char *buf, size_t size,
@@ -392,9 +394,24 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
return 0;
}
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+ struct drm_i915_gem_create_ext_vm_private ext;
+ struct create_ext *ext_data = data;
+
+ if (copy_from_user(&ext, base, sizeof(ext)))
+ return -EFAULT;
+
+ ext_data->vm_id = ext.vm_id;
+
+ return 0;
+}
+
static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+ [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
};
/**
@@ -410,6 +427,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+ struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
@@ -423,6 +441,12 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
if (ret)
return ret;
+ if (ext_data.vm_id) {
+ vm = i915_gem_vm_lookup(file->driver_priv, ext_data.vm_id);
+ if (unlikely(!vm))
+ return -ENOENT;
+ }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915, INTEL_MEMORY_SYSTEM);
@@ -449,8 +473,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
ext_data.placements,
ext_data.n_placements,
ext_data.flags);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ if (IS_ERR(obj)) {
+ ret = PTR_ERR(obj);
+ goto vm_put;
+ }
+
+ if (vm) {
+ obj->base.resv = vm->root_obj->base.resv;
+ obj->priv_root = i915_gem_object_get(vm->root_obj);
+ i915_vm_put(vm);
+ }
return i915_gem_publish(obj, file, &args->size, &args->handle);
+vm_put:
+ if (vm)
+ i915_vm_put(vm);
+
+ return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..6433173c3e84
Re: [Intel-gfx] [PATCH v10 04/11] drm/i915/gem: selftest should not attempt mmap of private regions
On 08/07/2022 08:53, Matthew Auld wrote:
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip the
mman tests for stolen") ?
huh, I guess not. That wasn't in my tree. I guess I should rebase.
Looking at it, my patch would have been preferable initially I think.
Each location of the additional checks in that patch first call
cam_mmap(), which I think is the most appropriate place to make the
decision.
I could do a replacement patch that reverts that one if preferred, or we
can leave it as is and I will drop this patch.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..76181e28c75e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object
*obj, enum i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
+ if (obj->mm.region && obj->mm.region->private)
+ return false;
+
if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
Re: [Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs
On Thu, Jul 07, 2022 at 03:31:42AM -0700, Hellstrom, Thomas wrote:
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
Add uapi allowing user to specify a BO as private to a specified VM
during the BO creation.
VM private BOs can only be mapped on the specified VM and can't be
dma_buf exported. VM private BOs share a single common dma_resv
object,
hence has a performance advantage requiring a single dma_resv object
update in the execbuf path compared to non-private (shared) BOs.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_create.c| 41
++-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 11 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 9
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
include/uapi/drm/i915_drm.h | 30 ++
11 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 927a87e5ec59..7e264566b51f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
@@ -243,6 +244,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+ u32 vm_id;
};
static void repr_placements(char *buf, size_t size,
@@ -392,9 +394,24 @@ static int ext_set_protected(struct
i915_user_extension __user *base, void *data
return 0;
}
+static int ext_set_vm_private(struct i915_user_extension __user
*base,
+ void *data)
+{
+ struct drm_i915_gem_create_ext_vm_private ext;
+ struct create_ext *ext_data = data;
+
+ if (copy_from_user(&ext, base, sizeof(ext)))
+ return -EFAULT;
+
+ ext_data->vm_id = ext.vm_id;
+
+ return 0;
+}
+
static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+ [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
};
/**
@@ -410,6 +427,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev,
void *data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+ struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
@@ -423,6 +441,12 @@ i915_gem_create_ext_ioctl(struct drm_device
*dev, void *data,
if (ret)
return ret;
+ if (ext_data.vm_id) {
+ vm = i915_gem_vm_lookup(file->driver_priv,
ext_data.vm_id);
+ if (unlikely(!vm))
+ return -ENOENT;
+ }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915,
INTEL_MEMORY_SYSTEM);
@@ -449,8 +473,21 @@ i915_gem_create_ext_ioctl(struct drm_device
*dev, void *data,
ext_data.placements,
ext_data.n_placements
,
ext_data.flags);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ if (IS_ERR(obj)) {
+ ret = PTR_ERR(obj);
+ goto vm_put;
+ }
+
+ if (vm) {
+ obj->base.resv = vm->root_obj->base.resv;
+ obj->priv_root = i915_gem_object_get(vm->root_obj);
+ i915_vm_put(vm);
+ }
return i915_gem_publish(obj, file, &args->size, &args-
>handle);
+vm_put:
+ if (vm)
+ i915_vm_put(vm);
+
+ return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..6433173c3e84 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -218,6 +218,12 @@ struct dma_buf *i915_gem_prime_export(struct
drm_gem_object *gem_obj, int flags)
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ if (obj->priv_root) {
+ drm_dbg(obj->base.dev,
+ "Exporting VM private objects is not
allowed\n");
+ return ERR_PTR(-EINVAL);
+ }
+
exp_info.ops = &i915_dmabuf_ops;
exp_info.size = gem_obj
Re: [Intel-gfx] [RFC 07/10] drm/i915/vm_bind: Handle persistent vmas in execbuf3
On Fri, 2022-07-08 at 05:44 -0700, Niranjana Vishwanathapura wrote:
> On Thu, Jul 07, 2022 at 07:54:16AM -0700, Hellstrom, Thomas wrote:
> > On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > > Handle persistent (VM_BIND) mappings during the request
> > > submission
> > > in the execbuf3 path.
> > >
> > > Signed-off-by: Niranjana Vishwanathapura
> > >
> > > ---
> > > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 176
> > > +-
> > > 1 file changed, 175 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > index 13121df72e3d..2079f5ca9010 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> > > @@ -22,6 +22,7 @@
> > > #include "i915_gem_vm_bind.h"
> > > #include "i915_trace.h"
> > >
> > > +#define __EXEC3_HAS_PIN BIT_ULL(33)
> > > #define __EXEC3_ENGINE_PINNED BIT_ULL(32)
> > > #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
> > >
> > > @@ -45,7 +46,9 @@
> > > * execlist. Hence, no support for implicit sync.
> > > *
> > > * The new execbuf3 ioctl only works in VM_BIND mode and the
> > > VM_BIND
> > > mode only
> > > - * works with execbuf3 ioctl for submission.
> > > + * works with execbuf3 ioctl for submission. All BOs mapped on
> > > that
> > > VM (through
> > > + * VM_BIND call) at the time of execbuf3 call are deemed
> > > required
> > > for that
> > > + * submission.
> > > *
> > > * The execbuf3 ioctl directly specifies the batch addresses
> > > instead
> > > of as
> > > * object handles as in execbuf2 ioctl. The execbuf3 ioctl will
> > > also
> > > not
> > > @@ -61,6 +64,13 @@
> > > * So, a lot of code supporting execbuf2 ioctl, like
> > > relocations, VA
> > > evictions,
> > > * vma lookup table, implicit sync, vma active reference
> > > tracking
> > > etc., are not
> > > * applicable for execbuf3 ioctl.
> > > + *
> > > + * During each execbuf submission, request fence is added to all
> > > VM_BIND mapped
> > > + * objects with DMA_RESV_USAGE_BOOKKEEP. The
> > > DMA_RESV_USAGE_BOOKKEEP
> > > usage will
> > > + * prevent over sync (See enum dma_resv_usage). Note that
> > > DRM_I915_GEM_WAIT and
> > > + * DRM_I915_GEM_BUSY ioctls do not check for
> > > DMA_RESV_USAGE_BOOKKEEP
> > > usage and
> > > + * hence should not be used for end of batch check. Instead, the
> > > execbuf3
> > > + * timeline out fence should be used for end of batch check.
> > > */
> > >
> > > struct eb_fence {
> > > @@ -124,6 +134,19 @@ eb_find_vma(struct i915_address_space *vm,
> > > u64
> > > addr)
> > > return i915_gem_vm_bind_lookup_vma(vm, va);
> > > }
> > >
> > > +static void eb_scoop_unbound_vmas(struct i915_address_space *vm)
> > > +{
> > > + struct i915_vma *vma, *vn;
> > > +
> > > + spin_lock(&vm->vm_rebind_lock);
> > > + list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list,
> > > vm_rebind_link) {
> > > + list_del_init(&vma->vm_rebind_link);
> > > + if (!list_empty(&vma->vm_bind_link))
> > > + list_move_tail(&vma->vm_bind_link, &vm-
> > > > vm_bind_list);
> > > + }
> > > + spin_unlock(&vm->vm_rebind_lock);
> > > +}
> > > +
> > > static int eb_lookup_vmas(struct i915_execbuffer *eb)
> > > {
> > > unsigned int i, current_batch = 0;
> > > @@ -138,11 +161,118 @@ static int eb_lookup_vmas(struct
> > > i915_execbuffer *eb)
> > > ++current_batch;
> > > }
> > >
> > > + eb_scoop_unbound_vmas(eb->context->vm);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int eb_lock_vmas(struct i915_execbuffer *eb)
> > > +{
> > > + struct i915_address_space *vm = eb->context->vm;
> > > + struct i915_vma *vma;
> > > + int err;
> > > +
> > > + err = i915_gem_vm_priv_lock(eb->context->vm, &eb->ww);
> > > + if (err)
> > > + return err;
> > > +
> >
> > See comment in review for 08/10 about re-checking the rebind list
> > here.
> >
> >
> >
> > > + list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
> > > + non_priv_vm_bind_link) {
> > > + err = i915_gem_object_lock(vma->obj, &eb->ww);
> > > + if (err)
> > > + return err;
> > > + }
> > > +
> > > return 0;
> > > }
> > >
> > > +static void eb_release_persistent_vmas(struct i915_execbuffer
> > > *eb,
> > > bool final)
> > > +{
> > > + struct i915_address_space *vm = eb->context->vm;
> > > + struct i915_vma *vma, *vn;
> > > +
> > > + assert_vm_bind_held(vm);
> > > +
> > > + if (!(eb->args->flags & __EXEC3_HAS_PIN))
> > > + return;
> > > +
> > > + assert_vm_priv_held(vm);
> > > +
> > > + list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link)
> > > + __i915_vma_unp
Re: [Intel-gfx] [RFC 01/10] drm/i915/vm_bind: Introduce VM_BIND ioctl
On Thu, Jul 07, 2022 at 12:32:14AM -0700, Hellstrom, Thomas wrote: On Wed, 2022-07-06 at 22:01 -0700, Niranjana Vishwanathapura wrote: > > + /** > > +* true: allow only vm_bind method of binding. > > +* false: allow only legacy execbuff method of binding. > > +*/ > > Use proper kerneldoc. (Same holds for structure documentation > across > the series). > Also please follow internal locking guidelines on documentation of > members that need protection with locks. I just followed the documentation convention that was already there ;) I think we need a prep patch in this series that adds kernel-doc for these structures and then add new fields for vm_bind with proper kernel-docs. That would be awesome if we could do that, but as a minimum, I think that new in-line struct / union comments should follow https://www.kernel.org/doc/html/v5.3/doc-guide/kernel-doc.html#in-line-member-documentation-comments and completely new struct / unions should follow https://www.kernel.org/doc/html/v5.3/doc-guide/kernel-doc.html#in-line-member-documentation-comments, and in particular the internal locking guidelines what members are protected with what locks and, if applicable, how. (For example a member may be protected by two locks when writing to it and only one of the locks when reading). Sounds good. Niranjana /Thomas
Re: [Intel-gfx] [RFC 02/10] drm/i915/vm_bind: Bind and unbind mappings
On Thu, Jul 07, 2022 at 10:14:38AM +0200, Thomas Hellström wrote:
On Wed, 2022-07-06 at 22:43 -0700, Niranjana Vishwanathapura wrote:
On Wed, Jul 06, 2022 at 06:21:03PM +0200, Thomas Hellström wrote:
> On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> > Bind and unbind the mappings upon VM_BIND and VM_UNBIND calls.
> >
> > Signed-off-by: Niranjana Vishwanathapura
> >
> > Signed-off-by: Prathap Kumar Valsan
> >
> > ---
> > drivers/gpu/drm/i915/Makefile | 1 +
> > drivers/gpu/drm/i915/gem/i915_gem_create.c | 10 +-
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +
> > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 38 +++
> > .../drm/i915/gem/i915_gem_vm_bind_object.c | 233
> > ++
> > drivers/gpu/drm/i915/gt/intel_gtt.c | 7 +
> > drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +
> > drivers/gpu/drm/i915/i915_driver.c | 11 +-
> > drivers/gpu/drm/i915/i915_vma.c | 7 +-
> > drivers/gpu/drm/i915/i915_vma.h | 2 -
> > drivers/gpu/drm/i915/i915_vma_types.h | 8 +
> > 11 files changed, 318 insertions(+), 10 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> > create mode 100644
> > drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile
> > index 522ef9b4aff3..4e1627e96c6e 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -165,6 +165,7 @@ gem-y += \
> > gem/i915_gem_ttm_move.o \
> > gem/i915_gem_ttm_pm.o \
> > gem/i915_gem_userptr.o \
> > + gem/i915_gem_vm_bind_object.o \
> > gem/i915_gem_wait.o \
> > gem/i915_gemfs.o
> > i915-y += \
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > index 33673fe7ee0a..927a87e5ec59 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> > @@ -15,10 +15,10 @@
> > #include "i915_trace.h"
> > #include "i915_user_extensions.h"
> >
> > -static u32 object_max_page_size(struct intel_memory_region
> > **placements,
> > - unsigned int n_placements)
> > +u32 i915_gem_object_max_page_size(struct intel_memory_region
> > **placements,
>
> Kerneldoc.
This is an existing function that is being modified. As I
mentioned in other thread, we probably need a prep patch early
in this series to add missing kernel-docs in i915 which this
patch series would later update.
Here we make a static function extern, which according to the patch
submission guidelines, mandates a kerneloc comment, so it's not so much
that the function is modified. We should be fine adding kerneldoc in
the patch that makes the function extern.
Ok, sounds good.
>
> > + unsigned int n_placements)
> > {
> > - u32 max_page_size = 0;
> > + u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
> > int i;
> >
> > for (i = 0; i < n_placements; i++) {
> > @@ -28,7 +28,6 @@ static u32 object_max_page_size(struct
> > intel_memory_region **placements,
> > max_page_size = max_t(u32, max_page_size, mr-
> > > min_page_size);
> > }
> >
> > - GEM_BUG_ON(!max_page_size);
> > return max_page_size;
> > }
>
> Should this change be separated out? It's not immediately clear to
> a
> reviewer why it is included.
It is being removed as max_page_size now has a non-zero default
value and hence this check is not valid anymore.
But that in itself deserves an explanation in the patch commit message.
So that's why I wondered whether it wouldn't be better to separate it
out?
Yah, we can have this change in a separate patch before we introduce
VM_BIND feature.
>
> >
> > @@ -99,7 +98,8 @@ __i915_gem_object_create_user_ext(struct
> > drm_i915_private *i915, u64 size,
> >
> > i915_gem_flush_free_objects(i915);
> >
> > - size = round_up(size, object_max_page_size(placements,
> > n_placements));
> > + size = round_up(size,
> > i915_gem_object_max_page_size(placements,
> > +
> > n_placements));
> > if (size == 0)
> > return ERR_PTR(-EINVAL);
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 6f0a3ce35567..650de2224843 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -47,6 +47,8 @@ static inline bool
> > i915_gem_object_size_2big(u64
> > size)
> > }
> >
> > void i915_gem_init__objects(struct drm_i915_private *i915);
> > +u32 i915_gem_object_max_page_size(struct intel_memory_region
> > **placements,
> > + unsigned int n_placements);
> >
> > void i915_objects_module_exi
Re: [Intel-gfx] [RFC 07/10] drm/i915/vm_bind: Handle persistent vmas in execbuf3
On Thu, Jul 07, 2022 at 07:54:16AM -0700, Hellstrom, Thomas wrote:
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 176
+-
1 file changed, 175 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 13121df72e3d..2079f5ca9010 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -22,6 +22,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -45,7 +46,9 @@
* execlist. Hence, no support for implicit sync.
*
* The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND
mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that
VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required
for that
+ * submission.
*
* The execbuf3 ioctl directly specifies the batch addresses instead
of as
* object handles as in execbuf2 ioctl. The execbuf3 ioctl will also
not
@@ -61,6 +64,13 @@
* So, a lot of code supporting execbuf2 ioctl, like relocations, VA
evictions,
* vma lookup table, implicit sync, vma active reference tracking
etc., are not
* applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all
VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP
usage will
+ * prevent over sync (See enum dma_resv_usage). Note that
DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP
usage and
+ * hence should not be used for end of batch check. Instead, the
execbuf3
+ * timeline out fence should be used for end of batch check.
*/
struct eb_fence {
@@ -124,6 +134,19 @@ eb_find_vma(struct i915_address_space *vm, u64
addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
}
+static void eb_scoop_unbound_vmas(struct i915_address_space *vm)
+{
+ struct i915_vma *vma, *vn;
+
+ spin_lock(&vm->vm_rebind_lock);
+ list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list,
vm_rebind_link) {
+ list_del_init(&vma->vm_rebind_link);
+ if (!list_empty(&vma->vm_bind_link))
+ list_move_tail(&vma->vm_bind_link, &vm-
>vm_bind_list);
+ }
+ spin_unlock(&vm->vm_rebind_lock);
+}
+
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
unsigned int i, current_batch = 0;
@@ -138,11 +161,118 @@ static int eb_lookup_vmas(struct
i915_execbuffer *eb)
++current_batch;
}
+ eb_scoop_unbound_vmas(eb->context->vm);
+
+ return 0;
+}
+
+static int eb_lock_vmas(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma;
+ int err;
+
+ err = i915_gem_vm_priv_lock(eb->context->vm, &eb->ww);
+ if (err)
+ return err;
+
See comment in review for 08/10 about re-checking the rebind list here.
+ list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+ non_priv_vm_bind_link) {
+ err = i915_gem_object_lock(vma->obj, &eb->ww);
+ if (err)
+ return err;
+ }
+
return 0;
}
+static void eb_release_persistent_vmas(struct i915_execbuffer *eb,
bool final)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma, *vn;
+
+ assert_vm_bind_held(vm);
+
+ if (!(eb->args->flags & __EXEC3_HAS_PIN))
+ return;
+
+ assert_vm_priv_held(vm);
+
+ list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link)
+ __i915_vma_unpin(vma);
+
+ eb->args->flags &= ~__EXEC3_HAS_PIN;
+ if (!final)
+ return;
+
+ list_for_each_entry_safe(vma, vn, &vm->vm_bind_list,
vm_bind_link)
+ if (i915_vma_is_bind_complete(vma))
+ list_move_tail(&vma->vm_bind_link, &vm-
>vm_bound_list);
+}
+
static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
{
+ eb_release_persistent_vmas(eb, final);
+ eb_unpin_engine(eb);
+}
+
+static int eb_reserve_fence_for_persistent_vmas(struct
i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma;
+ int ret;
+
+ ret = dma_resv_reserve_fences(vm->root_obj->base.resv, 1);
+ if (ret)
+ return ret;
+
+ list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+ non_priv_vm_bind_link) {
+ ret = dma_resv_reserve_fences(vma->o
Re: [Intel-gfx] [RFC 09/10] drm/i915/vm_bind: Skip vma_lookup for persistent vmas
On Tue, Jul 05, 2022 at 10:57:17AM +0200, Thomas Hellström wrote:
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 6adb013579be..9aa38b772b5b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -197,6 +197,10 @@ vma_create(struct drm_i915_gem_object *obj,
__set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
}
+ if (!i915_vma_is_ggtt(vma) &&
+ (view && view->type == I915_GGTT_VIEW_PARTIAL))
+ goto skip_rb_insert;
+
Rather than guessing that a vma with this signature is a persistent
vma, which is confusing to the reader, could we have an argument saying
we want to create a persistent vma?
Yah, sounds good. We probably can even check for vm->vm_bind_mode here
instead of passing a new argument. I think i915 won't create any
internal vmas for this VM, so, should be good to check vm->vm_bind_mode.
rb = NULL;
p = &obj->vma.tree.rb_node;
while (*p) {
@@ -221,6 +225,7 @@ vma_create(struct drm_i915_gem_object *obj,
rb_link_node(&vma->obj_node, rb, p);
rb_insert_color(&vma->obj_node, &obj->vma.tree);
+skip_rb_insert:
if (i915_vma_is_ggtt(vma))
/*
* We put the GGTT vma at the start of the vma-list,
followed
@@ -292,13 +297,16 @@ i915_vma_instance(struct drm_i915_gem_object
*obj,
struct i915_address_space *vm,
const struct i915_ggtt_view *view)
{
- struct i915_vma *vma;
+ struct i915_vma *vma = NULL;
GEM_BUG_ON(!kref_read(&vm->ref));
- spin_lock(&obj->vma.lock);
- vma = i915_vma_lookup(obj, vm, view);
- spin_unlock(&obj->vma.lock);
+ if (i915_is_ggtt(vm) || !view ||
+ view->type != I915_GGTT_VIEW_PARTIAL) {
Same here?
We probably can remove this code and have vm_bind ioctl directly
call vma_create.
Niranjana
/Thomas
+ spin_lock(&obj->vma.lock);
+ vma = i915_vma_lookup(obj, vm, view);
+ spin_unlock(&obj->vma.lock);
+ }
/* vma_create() will resolve the race if another creates the
vma */
if (unlikely(!vma))
@@ -1670,7 +1678,8 @@ static void release_references(struct i915_vma
*vma, bool vm_ddestroy)
spin_lock(&obj->vma.lock);
list_del(&vma->obj_link);
- if (!RB_EMPTY_NODE(&vma->obj_node))
+ if (!i915_vma_is_persistent(vma) &&
+ !RB_EMPTY_NODE(&vma->obj_node))
rb_erase(&vma->obj_node, &obj->vma.tree);
spin_unlock(&obj->vma.lock);
Re: [Intel-gfx] [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl
On Thu, 2022-07-07 at 21:38 +0200, Andi Shyti wrote: > Hi, > > > It seems we are duplicating a lot of code from i915_execbuffer.c. > > Did > > you consider > > yeah... while reading the code I was thinking the same then I see > that you made the same comment. Perhaps we need to group > commonalities and make common library for execbuf 2 and 3. > Indeed, we should at least attempt this, and judge whether the assumption that this will allow us to remove a bunch of duplicated code will hold. /Thomas > Andi
Re: [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote: > For persistent (vm_bind) vmas of userptr BOs, handle the user > page pinning by using the i915_gem_object_userptr_submit_init() > /done() functions > > Signed-off-by: Niranjana Vishwanathapura > > --- > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 67 > +++ > .../drm/i915/gem/i915_gem_vm_bind_object.c | 16 + > drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + > drivers/gpu/drm/i915/gt/intel_gtt.h | 1 + > 4 files changed, 85 insertions(+) > Hmm. I also miss the code in userptr invalidate that puts invalidated vm-private userptr vmas on the rebind list? /Thomas
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
Hi Karolina,
[...]
> > > > + dma_resv_for_each_fence_unlocked(&cursor, fence) {
> > > > + if (dma_fence_is_i915(fence) &&
> > > > + !i915_request_started(to_request(fence)))
> > > > + intel_rps_boost(to_request(fence));
> > > > + }
> >
> > you can remove the brackets here.
> >
> > Andi
>
> Would you like me to send v2 for it?
if the committer takes care of removing it, then no need,
otherwise, please yes, resend it. Even if it's a stupid nitpick,
if it gets applied it would be very difficult to get it fixed[*].
Didn't checkpatch.pl complain about it?
If you are going to resend it, you can add my:
Reviewed-by: Andi Shyti
also here.
Thanks,
Andi
[*] Because just minor coding style patches are generally
rejected, the only way for fixing style issues would be if:
1. someone is working in that part of the code
2. someone will sneak in the code fix in some unrelated patch
screwing up git blame
3. someone will send a big series on this file and have some
trivial coding style patches in it.
Amongst the three above, number '2' is the one I dislike the
most, but unfortunately that's also the most used.
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
== Series Details ==
Series: drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
URL : https://patchwork.freedesktop.org/series/106095/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11860 -> Patchwork_106095v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106095v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106095v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/index.html
Participating hosts (36 -> 38)
--
Additional (3): fi-hsw-4770 bat-rpls-2 fi-rkl-11600
Missing(1): bat-dg2-8
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106095v1:
### IGT changes ###
Possible regressions
* igt@kms_addfb_basic@unused-handle:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11860/fi-kbl-soraka/igt@kms_addfb_ba...@unused-handle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-kbl-soraka/igt@kms_addfb_ba...@unused-handle.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11860/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_106095v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#3282])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#3012])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3012])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [PASS][10] -> [INCOMPLETE][11] ([i915#2940])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11860/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][12] ([i915#4528])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][13] -> [DMESG-FAIL][14] ([i915#4494] /
[i915#4957])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11860/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][15] ([i915#5982])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][16] ([fdo#109271]) +9 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#111827]) +7 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106095v
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gem: Look for waitboosting across the whole object prior to individual waits
Hi Rodrigo and Andi,
Thank you very much for your reviews.
On 07.07.2022 23:50, Andi Shyti wrote:
Hi Rodrigo, Chris and Karolina,
On Thu, Jul 07, 2022 at 01:57:52PM -0400, Rodrigo Vivi wrote:
On Tue, Jul 05, 2022 at 12:57:17PM +0200, Karolina Drobnik wrote:
From: Chris Wilson
We employ a "waitboost" heuristic to detect when userspace is stalled
waiting for results from earlier execution. Under latency sensitive work
mixed between the gpu/cpu, the GPU is typically under-utilised and so
RPS sees that low utilisation as a reason to downclock the frequency,
causing longer stalls and lower throughput. The user left waiting for
the results is not impressed.
you can also write here "... is not impressed, was sad and cried"
:)
On applying commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv
workaround") it was observed that deinterlacing h264 on Haswell
performance dropped by 2-5x. The reason being that the natural workload
was not intense enough to trigger RPS (using HW evaluation intervals) to
upclock, and so it was depending on waitboosting for the throughput.
Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
changes the composition of dma-resv from keeping a single write fence +
multiple read fences, to a single array of multiple write and read
fences (a maximum of one pair of write/read fences per context). The
iteration order was also changed implicitly from all-read fences then
the single write fence, to a mix of write fences followed by read
fences. It is that ordering change that belied the fragility of
waitboosting.
Currently, a waitboost is inspected at the point of waiting on an
outstanding fence. If the GPU is backlogged such that we haven't yet
stated the request we need to wait on, we force the GPU to upclock until
the completion of that request. By changing the order in which we waited
upon requests, we ended up waiting on those requests in sequence and as
such we saw that each request was already started and so not a suitable
candidate for waitboosting.
Instead of
Okay, all the explanation makes sense. But this commit message and
the cover letter tells that we are doing X *Instead* *of* Y.
That would mean code for Y would be removed. But this patch just add X.
The boost we have right now is applied in i915_request_wait_timeout,
which is at the lower level than i915_gem_object_wait, and works for all
users, not just gem_object(s).
So it looks to me that we are adding extra boosts with the code below.
That's true - we'll have a redundant boost check for gem_object, but
this is fine. In this case it wouldn't apply the boost again because
either (1) the request already started execution, or (2) intel_rps_boost
returns early because i915_request_has_waitboost(rq) is true.
What am I missing?
I think the two things are unrelated and they are not mutually
exclusive.
Exactly
What this patch does is to scan the fences upfront and boost
those requests that are not naturally boosted (that is what we
currently do and as of now regressed) in order to not leave the
sad user above crying for long.
That is correct (especially the crying part)
Am I right? If so I would r-b this patch as it looks good to me.
asking whether to boost each fence in turn, we can look at
whether boosting is required for the dma-resv ensemble prior to waiting
on any fence, making the heuristic more robust to the order in which
fences are stored in the dma-resv.
Reported-by: Thomas Voegtle
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6284
Fixes: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Karolina Drobnik
Tested-by: Thomas Voegtle
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 319936f91ac5..3fbb464746e1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -9,6 +9,7 @@
#include
#include "gt/intel_engine.h"
+#include "gt/intel_rps.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
@@ -31,6 +32,38 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
timeout);
}
+static void
+i915_gem_object_boost(struct dma_resv *resv, unsigned int flags)
+{
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
+
+ /*
+* Prescan all fences for potential boosting before we begin waiting.
+*
+* When we wait, we wait on outstanding fences serially. If the
+* dma-resv contains a sequence such as 1:1, 1:2 instead of a reduced
+* form 1:2, then as we look at each wait in turn we see that each
+* request is currently executing and not worthy of boosting. But if
+* we only happen to look at the final fence in the sequence (
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ttm: fix sg_table construction
== Series Details ==
Series: drm/i915/ttm: fix sg_table construction
URL : https://patchwork.freedesktop.org/series/106048/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11857_full -> Patchwork_106048v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106048v1_full:
### CI changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* boot:
- {shard-tglu}: ([PASS][1], [PASS][2], [PASS][3], [PASS][4],
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11],
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17],
[PASS][18], [PASS][19]) -> ([PASS][20], [PASS][21], [PASS][22], [PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [FAIL][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-8/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-8/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-8/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-6/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-6/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-5/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-5/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-5/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-4/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-4/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-4/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-3/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-3/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-3/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-1/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-1/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-tglu-8/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-8/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-8/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-6/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-5/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-5/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-5/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-4/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-4/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-4/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-3/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-3/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-3/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-2/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-2/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-2/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-1/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-1/boot.html
[38]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v1/shard-tglu-1/boot.html
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_cursor_legacy@cursor-vs-flip@atomic:
- {shard-dg1}:[PASS][39] -> [FAIL][40] +4 similar issues
[39]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-dg1-17/
Re: [Intel-gfx] [PATCH] drm/i915/hdmi: Prune modes that require HDMI2.1 FRL
Hi Arun,
Thanks for the comments.
Please find my response inline.
On 7/8/2022 9:30 AM, Murthy, Arun R wrote:
-Original Message-
From: Intel-gfx On Behalf Of Ankit
Nautiyal
Sent: Thursday, July 7, 2022 10:57 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915/hdmi: Prune modes that require
HDMI2.1 FRL
HDMI2.1 requires some higher resolution video modes to be enumerated
only if HDMI2.1 Fixed Rate Link (FRL) is supported.
Current platforms do not support FRL transmission so prune modes that
require HDMI2.1 FRL.
If the hardware doesn't support FRL then it basically blocks HDMI2.1 feature.
Then it wont be possible to use any resolution above 4k60 is it?
Yes right. As I understand, the HDMI2.1a supersedes HDMI2.0b, and so the
platforms supporting HDMI2.0 must now pass the HDMI2.1 CTS.
The HDMI2.1a spec introduces Marketing Feature names for 4K100, 4K120,
8k@50, 8k@60 with suffix A, and B.
Suffix A meaning mode supported without compression, and B meaning, mode
supported with compression.
There are CTS tests that expect these modes not to be enumerated, if the
source does support the given requirements.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ebd91aa69dd2..93c00b61795f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1974,6 +1974,20 @@ intel_hdmi_mode_clock_valid(struct
drm_connector *connector, int clock,
return status;
}
+/*
+ * HDMI2.1 requires higher resolution modes like 8k60, 4K120 to be
+ * enumerated only if FRL is supported. Platforms not supporting FRL
+ * must prune these modes.
+ */
+static bool
+hdmi21_frl_quirk(int dotclock, bool frl_supported) {
+ if (dotclock >= 60 && !frl_supported)
+ return true;
+
+ return false;
+}
+
static enum drm_mode_status
intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -2001,6 +2015,13 @@ intel_hdmi_mode_valid(struct drm_connector
*connector,
clock *= 2;
}
+ /*
+* Current Platforms do not support HDMI2.1 FRL mode of
transmission,
+* so prune the modes that require FRL.
+*/
+ if (hdmi21_frl_quirk(clock, false))
+ return MODE_BAD;
+
Instead of setting this frl_supported as false, can we get this info from
hardware, so that when
our hardware supports it later it would be easy to enable this.
We can have something like:
src_supports_frl()
{
/* FRL not supported in
return false;
}
Later we can add check for Platform when HDMI2.1 FRL is supported and
rate parsed from VBT.
Regards,
Ankit
Thanks and Regards,
Arun R Murthy
---
[Intel-gfx] [PATCH v2] drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
The shmem_pin_map() function doesn't return error pointers, it returns
NULL.
Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of the
default context state")
Signed-off-by: Dan Carpenter
Reviewed-by: Matthew Auld
---
v2: Correct the Fixes tag. Add Matthew's reviewed-by tag.
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 8b2c11dbe354..1109088fe8f6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -176,8 +176,8 @@ static int live_lrc_layout(void *arg)
continue;
hw = shmem_pin_map(engine->default_state);
- if (IS_ERR(hw)) {
- err = PTR_ERR(hw);
+ if (!hw) {
+ err = -ENOMEM;
break;
}
hw += LRC_STATE_OFFSET / sizeof(*hw);
@@ -365,8 +365,8 @@ static int live_lrc_fixed(void *arg)
continue;
hw = shmem_pin_map(engine->default_state);
- if (IS_ERR(hw)) {
- err = PTR_ERR(hw);
+ if (!hw) {
+ err = -ENOMEM;
break;
}
hw += LRC_STATE_OFFSET / sizeof(*hw);
--
2.35.1
Re: [Intel-gfx] [PATCH] drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
On Fri, Jul 08, 2022 at 10:02:34AM +0100, Matthew Auld wrote:
> On 08/07/2022 09:40, Dan Carpenter wrote:
> > The shmem_pin_map() function doesn't return error pointers, it returns
> > NULL.
> >
> > Fixes: a0d3fdb628b8 ("drm/i915/gt: Split logical ring contexts from
> > execlist submission"
>
> I think this should be:
>
> Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of the
> default context state")
>
Ah, right. I will resend.
> > Signed-off-by: Dan Carpenter
>
> There looks to be one more in gvt/cmd_parser.c?
>
I fixed that one in a separate patch?
regards,
dan carpenter
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
== Series Details ==
Series: drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
URL : https://patchwork.freedesktop.org/series/106093/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11859 -> Patchwork_106093v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/index.html
Participating hosts (37 -> 40)
--
Additional (4): bat-adlm-1 fi-rkl-11600 bat-adlp-4 fi-hsw-4770
Missing(1): bat-jsl-3
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106093v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {bat-rpls-2}: [DMESG-WARN][1] ([i915#5950]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/bat-rpls-2/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/bat-rpls-2/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_106093v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@verify-random:
- bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/bat-adlp-4/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3282])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
- bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3282])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/bat-adlp-4/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#3012])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3012])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6700k2: [PASS][10] -> [FAIL][11] ([i915#6042])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][12] ([i915#4528])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][13] ([i915#4785])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][14] -> [DMESG-FAIL][15] ([i915#4528])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][16] ([i915#5982])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
- bat-adlp-4: NOTRUN -> [SKIP][17] ([i915#5903])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/bat-adlp-4/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271]) +9 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_busy@basic@modeset:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][19] ([i915#3576])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106093v1/bat-adlp-4/igt@kms_busy@ba...@modeset.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][20]
Re: [Intel-gfx] [PATCH] drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
On 08/07/2022 09:40, Dan Carpenter wrote:
The shmem_pin_map() function doesn't return error pointers, it returns
NULL.
Fixes: a0d3fdb628b8 ("drm/i915/gt: Split logical ring contexts from execlist
submission"
I think this should be:
Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of
the default context state")
Signed-off-by: Dan Carpenter
There looks to be one more in gvt/cmd_parser.c?
Otherwise,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 8b2c11dbe354..1109088fe8f6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -176,8 +176,8 @@ static int live_lrc_layout(void *arg)
continue;
hw = shmem_pin_map(engine->default_state);
- if (IS_ERR(hw)) {
- err = PTR_ERR(hw);
+ if (!hw) {
+ err = -ENOMEM;
break;
}
hw += LRC_STATE_OFFSET / sizeof(*hw);
@@ -365,8 +365,8 @@ static int live_lrc_fixed(void *arg)
continue;
hw = shmem_pin_map(engine->default_state);
- if (IS_ERR(hw)) {
- err = PTR_ERR(hw);
+ if (!hw) {
+ err = -ENOMEM;
break;
}
hw += LRC_STATE_OFFSET / sizeof(*hw);
Re: [Intel-gfx] [PATCH] drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
On 08.07.2022 10:41, Dan Carpenter wrote:
The shmem_pin_map() function returns NULL, it doesn't return error
pointers.
Fixes: 97ea656521c8 ("drm/i915/gvt: Parse default state to update reg
whitelist")
Signed-off-by: Dan Carpenter
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index b9eb75a2b400..1c35a41620ae 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3117,9 +3117,9 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
continue;
vaddr = shmem_pin_map(engine->default_state);
- if (IS_ERR(vaddr)) {
- gvt_err("failed to map %s->default state, err:%zd\n",
- engine->name, PTR_ERR(vaddr));
+ if (!vaddr) {
+ gvt_err("failed to map %s->default state\n",
+ engine->name);
return;
}
Re: [Intel-gfx] [PATCH 2/2] i915/perf: Disable OA sseu config param for gfx12.50+
On 07.07.2022 21:30, Nerlige Ramappa, Umesh wrote:
The global sseu config is applicable only to gen11 platforms where
concurrent media, render and OA use cases may cause some subslices to be
turned off and hence lose NOA configuration. Ideally we want to return
ENODEV for non-gen11 platforms, however, this has shipped with gfx12, so
disable only for gfx12.50+.
v2: gfx12 is already shipped with this, disable for gfx12.50+ (Lionel)
v3: (Matt)
- Update commit message and replace "12.5" with "12.50"
- Replace DRM_DEBUG() with driver specific drm_dbg()
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/i915_perf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b3beb89884e0..f3c23fe9ad9c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3731,6 +3731,13 @@ static int read_properties_unlocked(struct i915_perf
*perf,
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",
+ GRAPHICS_VER_FULL(perf->i915));
+ return -ENODEV;
+ }
+
if (copy_from_user(&user_sseu,
u64_to_user_ptr(value),
sizeof(user_sseu))) {
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: ttm for stolen (rev7)
== Series Details ==
Series: drm/i915: ttm for stolen (rev7)
URL : https://patchwork.freedesktop.org/series/101396/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11857_full -> Patchwork_101396v7_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_101396v7_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_101396v7_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_101396v7_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-skl7/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v7/shard-skl7/igt@i915_selftest@l...@execlists.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_cursor_legacy@cursor-vs-flip@atomic:
- {shard-dg1}:[PASS][3] -> [FAIL][4] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-dg1-17/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v7/shard-dg1-13/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
Known issues
Here are the changes found in Patchwork_101396v7_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-snb: ([PASS][5], [PASS][6], [PASS][7], [PASS][8],
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14],
[PASS][15], [FAIL][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20],
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26],
[PASS][27], [PASS][28], [PASS][29]) ([i915#4338]) -> ([PASS][30], [PASS][31],
[PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37],
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43],
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49],
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb4/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb2/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11857/shard-snb2/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v7/shard-snb7/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v7/shard-snb7/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v7/shard-snb7/boot.html
[33
Re: [Intel-gfx] [PATCH 1/2] i915/perf: Replace DRM_DEBUG with driver specific drm_dbg call
On 07.07.2022 21:30, Nerlige Ramappa, Umesh wrote:
DRM_DEBUG is not the right debug call to use in i915 OA, replace it with
driver specific drm_dbg() call (Matt).
Signed-off-by: Umesh Nerlige Ramappa ---
drivers/gpu/drm/i915/i915_perf.c | 151 ---
1 file changed, 100 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1577ab6754db..b3beb89884e0 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -885,8 +885,9 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
if (ret)
return ret;
- DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",
- stream->period_exponent);
+ drm_dbg(&stream->perf->i915->drm,
Looking at number of uses of &stream->perf->i915->drm I wonder if some
helper wouldn't simplify things, sth like to_drm(stream) ?
Anyway:
Reviewed-by: Andrzej Hajda
Regards
Andrzej
+ "OA buffer overflow (exponent = %d): force restart\n",
+ stream->period_exponent);
stream->perf->ops.oa_disable(stream);
stream->perf->ops.oa_enable(stream);
@@ -1108,8 +1109,9 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
if (ret)
return ret;
- DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",
- stream->period_exponent);
+ drm_dbg(&stream->perf->i915->drm,
+ "OA buffer overflow (exponent = %d): force restart\n",
+ stream->period_exponent);
stream->perf->ops.oa_disable(stream);
stream->perf->ops.oa_enable(stream);
@@ -2863,7 +2865,8 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
int ret;
if (!props->engine) {
- DRM_DEBUG("OA engine not specified\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "OA engine not specified\n");
return -EINVAL;
}
@@ -2873,18 +2876,21 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
* IDs
*/
if (!perf->metrics_kobj) {
- DRM_DEBUG("OA metrics weren't advertised via sysfs\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "OA metrics weren't advertised via sysfs\n");
return -EINVAL;
}
if (!(props->sample_flags & SAMPLE_OA_REPORT) &&
(GRAPHICS_VER(perf->i915) < 12 || !stream->ctx)) {
- DRM_DEBUG("Only OA report sampling supported\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "Only OA report sampling supported\n");
return -EINVAL;
}
if (!perf->ops.enable_metric_set) {
- DRM_DEBUG("OA unit not supported\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "OA unit not supported\n");
return -ENODEV;
}
@@ -2894,12 +2900,14 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
* we currently only allow exclusive access
*/
if (perf->exclusive_stream) {
- DRM_DEBUG("OA unit already in use\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "OA unit already in use\n");
return -EBUSY;
}
if (!props->oa_format) {
- DRM_DEBUG("OA report format not specified\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "OA report format not specified\n");
return -EINVAL;
}
@@ -2929,20 +2937,23 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
if (stream->ctx) {
ret = oa_get_render_ctx_id(stream);
if (ret) {
- DRM_DEBUG("Invalid context id to filter with\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "Invalid context id to filter with\n");
return ret;
}
}
ret = alloc_noa_wait(stream);
if (ret) {
- DRM_DEBUG("Unable to allocate NOA wait batch buffer\n");
+ drm_dbg(&stream->perf->i915->drm,
+ "Unable to allocate NOA wait batch buffer\n");
goto err_noa_wait_alloc;
}
stream->oa_config = i915_perf_get_oa_config(perf, props->metrics_set);
if (!stream->oa_config) {
- DRM_DEBUG("Invalid OA config id=%i\n", props->metrics_set);
+ drm_dbg(&stream->perf->i915->drm,
+ "Invalid OA config id=%i\n", props->metrics_set);
ret = -EINVAL;
goto err_config;
}
@@ -2973,11 +2984,13 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
[Intel-gfx] [PATCH] drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
The shmem_pin_map() function returns NULL, it doesn't return error
pointers.
Fixes: 97ea656521c8 ("drm/i915/gvt: Parse default state to update reg
whitelist")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index b9eb75a2b400..1c35a41620ae 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3117,9 +3117,9 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
continue;
vaddr = shmem_pin_map(engine->default_state);
- if (IS_ERR(vaddr)) {
- gvt_err("failed to map %s->default state, err:%zd\n",
- engine->name, PTR_ERR(vaddr));
+ if (!vaddr) {
+ gvt_err("failed to map %s->default state\n",
+ engine->name);
return;
}
--
2.35.1
[Intel-gfx] [PATCH] drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
The shmem_pin_map() function doesn't return error pointers, it returns
NULL.
Fixes: a0d3fdb628b8 ("drm/i915/gt: Split logical ring contexts from execlist
submission"
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 8b2c11dbe354..1109088fe8f6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -176,8 +176,8 @@ static int live_lrc_layout(void *arg)
continue;
hw = shmem_pin_map(engine->default_state);
- if (IS_ERR(hw)) {
- err = PTR_ERR(hw);
+ if (!hw) {
+ err = -ENOMEM;
break;
}
hw += LRC_STATE_OFFSET / sizeof(*hw);
@@ -365,8 +365,8 @@ static int live_lrc_fixed(void *arg)
continue;
hw = shmem_pin_map(engine->default_state);
- if (IS_ERR(hw)) {
- err = PTR_ERR(hw);
+ if (!hw) {
+ err = -ENOMEM;
break;
}
hw += LRC_STATE_OFFSET / sizeof(*hw);
--
2.35.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: fix sg_table construction (rev2)
== Series Details == Series: drm/i915/ttm: fix sg_table construction (rev2) URL : https://patchwork.freedesktop.org/series/106048/ State : success == Summary == CI Bug Log - changes from CI_DRM_11859 -> Patchwork_106048v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/index.html Participating hosts (37 -> 34) -- Additional (3): fi-hsw-4770 fi-rkl-11600 bat-dg2-9 Missing(6): bat-dg1-6 bat-dg2-8 bat-adlp-6 bat-adln-1 bat-rpls-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_106048v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#3282]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3012]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3012]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_lrc: - fi-rkl-guc: NOTRUN -> [INCOMPLETE][6] ([i915#4983]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@requests: - fi-blb-e6850: [PASS][7] -> [DMESG-FAIL][8] ([i915#4528]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11859/fi-blb-e6850/igt@i915_selftest@l...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-blb-e6850/igt@i915_selftest@l...@requests.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: NOTRUN -> [INCOMPLETE][9] ([i915#5982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271]) +9 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4103]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html - fi-hsw-4770:NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1072]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4098]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-read: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106048v2/fi-rkl-11600/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][19] ([fdo#1
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/ttm: fix sg_table construction (rev2)
== Series Details == Series: drm/i915/ttm: fix sg_table construction (rev2) URL : https://patchwork.freedesktop.org/series/106048/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v10 04/11] drm/i915/gem: selftest should not attempt mmap of private regions
On 07/07/2022 21:02, Robert Beckett wrote:
During testing make can_mmap consider whether the region is private.
Do we still need this with: 938d2fd17d17 ("drm/i915/selftests: skip the
mman tests for stolen") ?
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..76181e28c75e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object *obj, enum
i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
+ if (obj->mm.region && obj->mm.region->private)
+ return false;
+
if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
[Intel-gfx] [PATCH] drm/i915/ttm: fix sg_table construction
If we encounter some monster sized local-memory page that exceeds the
maximum sg length (UINT32_MAX), ensure that don't end up with some
misaligned address in the entry that follows, leading to fireworks
later. Also ensure we have some coverage of this in the selftests.
v2(Chris): use round_down consistently to avoid udiv errors
Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +--
drivers/gpu/drm/i915/i915_scatterlist.c | 19 +++
drivers/gpu/drm/i915/i915_scatterlist.h | 6 --
drivers/gpu/drm/i915/intel_region_ttm.c | 10 +++---
drivers/gpu/drm/i915/intel_region_ttm.h | 3 ++-
.../drm/i915/selftests/intel_memory_region.c | 17 -
drivers/gpu/drm/i915/selftests/mock_region.c | 3 ++-
7 files changed, 55 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 7e1f8b83077f..c5c8aa1f8558 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -602,10 +602,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct ttm_resource *res)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ u64 page_alignment;
if (!i915_ttm_gtt_binds_lmem(res))
return i915_ttm_tt_get_st(bo->ttm);
+ page_alignment = bo->page_alignment << PAGE_SHIFT;
+ if (!page_alignment)
+ page_alignment = obj->mm.region->min_page_size;
+
/*
* If CPU mapping differs, we need to add the ttm_tt pages to
* the resulting st. Might make sense for GGTT.
@@ -616,7 +621,8 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct i915_refct_sgt *rsgt;
rsgt = intel_region_ttm_resource_to_rsgt(obj->mm.region,
-res);
+res,
+
page_alignment);
if (IS_ERR(rsgt))
return rsgt;
@@ -625,7 +631,8 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
return i915_refct_sgt_get(obj->ttm.cached_io_rsgt);
}
- return intel_region_ttm_resource_to_rsgt(obj->mm.region, res);
+ return intel_region_ttm_resource_to_rsgt(obj->mm.region, res,
+page_alignment);
}
static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 159571b9bd24..f63b50b71e10 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -68,6 +68,7 @@ void i915_refct_sgt_init(struct i915_refct_sgt *rsgt, size_t
size)
* drm_mm_node
* @node: The drm_mm_node.
* @region_start: An offset to add to the dma addresses of the sg list.
+ * @page_alignment: Required page alignment for each sg entry. Power of two.
*
* Create a struct sg_table, initializing it from a struct drm_mm_node,
* taking a maximum segment length into account, splitting into segments
@@ -77,15 +78,18 @@ void i915_refct_sgt_init(struct i915_refct_sgt *rsgt,
size_t size)
* error code cast to an error pointer on failure.
*/
struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct drm_mm_node *node,
- u64 region_start)
+ u64 region_start,
+ u64 page_alignment)
{
- const u64 max_segment = SZ_1G; /* Do we have a limit on this? */
+ const u64 max_segment = round_down(UINT_MAX, page_alignment);
u64 segment_pages = max_segment >> PAGE_SHIFT;
u64 block_size, offset, prev_end;
struct i915_refct_sgt *rsgt;
struct sg_table *st;
struct scatterlist *sg;
+ GEM_BUG_ON(!max_segment);
+
rsgt = kmalloc(sizeof(*rsgt), GFP_KERNEL);
if (!rsgt)
return ERR_PTR(-ENOMEM);
@@ -112,6 +116,8 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
sg = __sg_next(sg);
sg_dma_address(sg) = region_start + offset;
+ GEM_BUG_ON(!IS_ALIGNED(sg_dma_address(sg),
+ page_alignment));
sg_dma_len(sg) = 0;
sg->length = 0;
st->nents++;
@@ -138,6 +144,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
* i915_buddy_block list
Re: [Intel-gfx] [RFT][PATCH v2 0/9] Update vfio_pin/unpin_pages API
> -Original Message- > From: intel-gvt-dev On Behalf Of > On Thu, Jul 07, 2022 at 06:08:45AM +, Tian, Kevin wrote: > > > > Request for testing: I only did build for s390 and i915 code, so > > > it'd be nice to have people who have environment to run sanity > > > accordingly. > > > > > > > +Terrence who is testing it for i915 now... > > Hi Terrence, would it be possible for you to pull v3 to test on? > https://github.com/nicolinc/iommufd/commits/dev/vfio_pin_pages-v3 > > They are basically same but there's a new DIV_ROUND_UP change, which > shouldn't result in any functional difference, IMHO. If > v3 passes, I can simply add your Tested-by when I respin it. Hi Nicolin, I already completed KVMGT key feature testing based on your v3 repo, VM booted up successfully and run smoothly, but there is a call trace during each time VM booting up, as the attachment. call_trace.log Description: call_trace.log
