[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_color: Fix pipe degamma subtests
We need to collect CRC with no degamma transformation
and after drawing gradient with degamma LUT.
This patch makes subtest pipe degamma code
similar to pipe gamma is written.
Signed-off-by: Vidya Srinivas
---
tests/kms_color.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/tests/kms_color.c b/tests/kms_color.c
index 3a42532a5c27..2d55f2611e72 100644
--- a/tests/kms_color.c
+++ b/tests/kms_color.c
@@ -31,8 +31,7 @@ static void test_pipe_degamma(data_t *data,
{
igt_output_t *output;
igt_display_t *display = >display;
- gamma_lut_t *degamma_linear, *degamma_full;
- gamma_lut_t *gamma_linear;
+ gamma_lut_t *degamma_full;
color_t red_green_blue[] = {
{ 1.0, 0.0, 0.0 },
{ 0.0, 1.0, 0.0 },
@@ -42,11 +41,8 @@ static void test_pipe_degamma(data_t *data,
igt_require(igt_pipe_obj_has_prop(primary->pipe, IGT_CRTC_DEGAMMA_LUT));
igt_require(igt_pipe_obj_has_prop(primary->pipe, IGT_CRTC_GAMMA_LUT));
- degamma_linear = generate_table(data->degamma_lut_size, 1.0);
degamma_full = generate_table_max(data->degamma_lut_size);
- gamma_linear = generate_table(data->gamma_lut_size, 1.0);
-
for_each_valid_output_on_pipe(>display, primary->pipe->pipe,
output) {
drmModeModeInfo *mode;
struct igt_fb fb_modeset, fb;
@@ -75,8 +71,7 @@ static void test_pipe_degamma(data_t *data,
igt_plane_set_fb(primary, _modeset);
disable_ctm(primary->pipe);
- disable_degamma(primary->pipe);
- set_gamma(data, primary->pipe, gamma_linear);
+ set_degamma(data, primary->pipe, degamma_full);
igt_display_commit(>display);
/* Draw solid colors with no degamma transformation. */
@@ -92,7 +87,6 @@ static void test_pipe_degamma(data_t *data,
*/
paint_gradient_rectangles(data, mode, red_green_blue, );
igt_plane_set_fb(primary, );
- set_degamma(data, primary->pipe, degamma_full);
igt_display_commit(>display);
igt_wait_for_vblank(data->drm_fd,
display->pipes[primary->pipe->pipe].crtc_offset);
@@ -109,9 +103,7 @@ static void test_pipe_degamma(data_t *data,
igt_remove_fb(data->drm_fd, _modeset);
}
- free_lut(degamma_linear);
free_lut(degamma_full);
- free_lut(gamma_linear);
}
/*
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms
For Intel platforms, pitch needs to be 64 byte aligned.
Kernel code vgem_gem_dumb_create which is platform generic code
doesnt do the alignment. This causes frame buffer creation to fail
on Intel platforms where the pitch is not 64 byte aligned.
tests: test run on Intel platforms with panel resolution 1366x768
Signed-off-by: Vidya Srinivas
---
tests/kms_prime.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/kms_prime.c b/tests/kms_prime.c
index 8cb2ca2a9dc3..fdc941fe8100 100644
--- a/tests/kms_prime.c
+++ b/tests/kms_prime.c
@@ -51,6 +51,8 @@ static struct {
{ .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },
};
+bool check_platform;
+
IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
static bool has_prime_import(int fd)
@@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct dumb_bo
*scratch,
scratch->bpp = 32;
scratch->handle = kmstest_dumb_create(exporter_fd,
- scratch->width,
+ check_platform? ALIGN(scratch->width, 64):
scratch->width,
scratch->height,
scratch->bpp,
>pitch,
@@ -262,6 +264,7 @@ igt_main
/* ANY = anything that is not VGEM */
first_fd = __drm_open_driver_another(0, DRIVER_ANY |
DRIVER_VGEM);
+ check_platform = is_i915_device(first_fd);
igt_require(first_fd >= 0);
second_fd = __drm_open_driver_another(1, DRIVER_ANY |
DRIVER_VGEM);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer
Using (void *)-1 directly in read is aborting on chrome systems.
Following message is seen.
Starting subtest: invalid-buffer
*** buffer overflow detected ***: terminated
Received signal SIGABRT.
Stack trace:
Aborted (core dumped)
Patch just adds a pointer variable and uses it in read.
Signed-off-by: Vidya Srinivas
---
tests/drm_read.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/drm_read.c b/tests/drm_read.c
index ccf9d822fd8d..2fdec5be4078 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -103,10 +103,11 @@ static void teardown(int fd)
static void test_invalid_buffer(int in)
{
int fd = setup(in, 0);
+ void *add = (void *)-1;
alarm(1);
- igt_assert_eq(read(fd, (void *)-1, 4096), -1);
+ igt_assert_eq(read(fd, add, 4096), -1);
igt_assert_eq(errno, EFAULT);
teardown(fd);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
Without wait for vblank, CRC mismatch is seen
between big and small CRC on few Gen11 systems.
Signed-off-by: Vidya Srinivas
---
tests/kms_big_fb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
index b35727a09bd0..f90363c3beb2 100644
--- a/tests/kms_big_fb.c
+++ b/tests/kms_big_fb.c
@@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
static bool test_plane(data_t *data)
{
igt_plane_t *plane = data->plane;
+ igt_display_t *display = >display;
struct igt_fb *small_fb = >small_fb;
struct igt_fb *big_fb = >big_fb;
int w = data->big_fb_width - small_fb->width;
@@ -337,16 +338,17 @@ static bool test_plane(data_t *data)
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, big_fb);
igt_fb_set_position(big_fb, plane, x, y);
igt_fb_set_size(big_fb, plane, small_fb->width,
small_fb->height);
+
igt_plane_set_size(plane, data->width, data->height);
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, NULL);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_flip.c: Fix subtests flip-vs-suspend
Some Intel Gen11 systems are not able to do a RTC wake. Instead change the default SUSPEND_TEST_NONE to SUSPEND_TEST_PLATFORM. Signed-off-by: Vidya Srinivas --- tests/kms_flip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 8f736652be90..8afac88c9b15 100755 --- a/tests/kms_flip.c +++ b/tests/kms_flip.c @@ -835,7 +835,8 @@ static bool run_test_step(struct test_output *o, unsigned int *events) if (o->flags & TEST_SUSPEND) igt_system_suspend_autoresume(SUSPEND_STATE_MEM, - SUSPEND_TEST_NONE); + is_i915_device(drm_fd)? + SUSPEND_TEST_PLATFORM:SUSPEND_TEST_NONE); if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > 0) igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, _reply) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Add a prefetching memcpy_from_wc
== Series Details == Series: drm: Add a prefetching memcpy_from_wc URL : https://patchwork.freedesktop.org/series/90656/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10140_full -> Patchwork_20220_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20220_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20220_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20220_full: ### Piglit changes ### Possible regressions * spec@!opengl 1.3@gl-1.3-texture-env (NEW): - pig-snb-2600: NOTRUN -> [INCOMPLETE][1] +7 similar issues [1]: None New tests - New tests have been introduced between CI_DRM_10140_full and Patchwork_20220_full: ### New Piglit tests (8) ### * spec@!opengl 1.3@gl-1.3-texture-env: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_texture_cube_map_array@texsubimage cube_map_array: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@ext_framebuffer_object@fbo-fragcoord: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@ext_texture_array@fbo-depth-array fs-writes-depth: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@ext_texture_compression_rgtc@fbo-generatemipmap-formats: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@ext_texture_compression_rgtc@fbo-generatemipmap-formats-signed: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@ext_texture_compression_rgtc@texwrap formats: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@ext_texture_swizzle@ext_texture_swizzle-swizzle: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_20220_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-3x: - shard-iclb: NOTRUN -> [SKIP][2] ([i915#1839]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-iclb5/igt@feature_discov...@display-3x.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_ctx_ringsize@active@bcs0: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([i915#3316]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10140/shard-skl10/igt@gem_ctx_ringsize@act...@bcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-skl8/igt@gem_ctx_ringsize@act...@bcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10140/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10140/shard-iclb5/igt@gem_exec_fair@basic-p...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10140/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][13] ([i915#2389]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-apl8/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-iclb: [PASS][14] -> [INCOMPLETE][15] ([i915#3468]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10140/shard-iclb5/igt@gem_mmap_...@cpuset-medium-copy-xy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20220/shard-iclb4/igt@gem_mmap_...@cpuset-medium-copy-xy.html - shard-glk: [PASS][16] -> [FAIL][17]
Re: [Intel-gfx] [PATCH 15/18] drm/i915/guc: Ensure H2G buffer updates visible before tail update
On 5/26/2021 10:58, Matthew Brost wrote:
On Wed, May 26, 2021 at 02:36:18PM +0200, Michal Wajdeczko wrote:
On 26.05.2021 08:42, Matthew Brost wrote:
Ensure H2G buffer updates are visible before descriptor tail updates by
inserting a barrier between the H2G buffer update and the tail. The
barrier is simple wmb() for SMEM and is register write for LMEM. This is
needed if more than 1 H2G can be inflight at once.
Signed-off-by: Matthew Brost
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index fb875d257536..42063e1c355d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -328,6 +328,18 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
return ++ct->requests.last_fence;
}
+static void write_barrier(struct intel_guc_ct *ct) {
+ struct intel_guc *guc = ct_to_guc(ct);
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
+ GEM_BUG_ON(guc->send_regs.fw_domains);
+ intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
hmm, as this is one of the GuC scratch registers used for H2G MMIO
communication, writing 0 there might be interpreted by the GuC as new
request with action=0 and might results in extra processing/logging on
GuC side, and, since from here we don't protect access to this register
by send_mutex, we can corrupt other MMIO message being prepared from
different thread, ... can't we use other register ?
Hmm, this code has been internal for a long time and we haven't seen an
issues. MMIOs are always attempted to be processed each interrupt and
then CTBs are processed next. A value a 0 in scratch0 results in no MMIOs
being processed as a value of 0 is a reserved action which translates to
a NOP.
Also in the current i915 once CTBs are enabled MMIOs are never used.
That being said, I think once we transition to the new interface +
enable suspend on a VF MMIOs might be used.
With that I purpose that we merge this as is with a comment saying if we
ever mix CTBs and MMIOs we need to find another MMIO register. I don't
changing this now is worth delaying upstreaming this and also any change
we make now will make us lose confidence in code that has been
thoroughly tested.
Matt
This was discussed in chat while inspecting the GuC firmware code.
Writing zero to the scratch does indeed not trigger any extra processing
of spurious MMIO H2Gs. The register is indeed always checked when the
host triggers a CTB H2G, but zero counts as invalid and thus will be
skipped.
So with a comment about not mixing CTB and MMIOs, I think we are good
for now. It seems unlikely that MMIOs & CTB would be mixed. MMIOs are
only used for initialisation operations and should not be necessary once
the CTBs are up and running. If mixing does occur in the future, it
sounds like something that should be addressed at the GuC architecture
level!
With the comment added:
Reviewed-by: John Harrison
+ } else {
+ wmb();
+ }
+}
+
/**
* DOC: CTB Host to GuC request
*
@@ -411,6 +423,12 @@ static int ct_write(struct intel_guc_ct *ct,
}
GEM_BUG_ON(tail > size);
+ /*
+* make sure H2G buffer update and LRC tail update (if this triggering a
+* submission) are visible before updating the descriptor tail
+*/
+ write_barrier(ct);
+
/* now update desc tail (back in bytes) */
desc->tail = tail * 4;
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/1] drm/i915/dg1: Add HWMON power sensor support
As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. Signed-off-by: Dale B Stimson --- .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon new file mode 100644 index 0..2ee7c413ca190 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -0,0 +1,116 @@ +What: /sys/devices/.../hwmon/hwmon/energy1_input +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Energy input of device in microjoules. + + The returned textual representation is an unsigned integer + number that can be stored in 64-bits. Warning: The hardware + register is 32-bits wide and can overflow by wrapping around. + A single wrap-around between calls to read this value can + be detected and will be accounted for in the returned value. + At a power consumption of 1 watt, the 32-bit hardware register + would wrap-around approximately every 3 days. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit is enabled - true or false. + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit in milliwatts + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_interval +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit interval in milliseconds over +which sustained power is averaged. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit is enabled - true or false + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit in milliwatts. + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_default_limit +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Default power limit. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_min_limit +Date: June 2021 +KernelVersion: 5.14
[Intel-gfx] [PATCH v4 0/1] drm/i915/dg1: Add HWMON power sensor support
drm/i915/dg1: Add HWMON power support As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON entries are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. - v4 Commit mesage minor rewording v4 Move call to i915_hwmon_register() to a more appropriate location, so that it is done after intel_gt_driver_register(). The call to i915_perf_unregister() is moved correspondingly. v4 The proper register to read energy status is PCU_PACKAGE_ENERGY_STATUS. v4 Attribute power1_max_enable is read-only. v3 Added documentation of these hwmon attributes in file Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon v3 Commit mesage minor rewording v3 Function name changes: i915_hwmon_init() -> i915_hwmon_register() i915_hwmon_fini() -> i915_hwmon_unregister() v3 i915_hwmon_register and i915_hwmon_unregister now take arg i915. v3 i915_hwmon_register() now returns void instead of int. v3 Macro FIELD_SHIFT() added to compute shift value from constant field mask. v3 Certain functions now longer require "inline" due to addition of new parameter field_shift, allowing access to constant expressions for the field mask at each call site. These functions now do field access via shift and masking and no longer use le32*() functions (as le32*() required a local constant expression for the mask). _field_read_and_scale() _field_read64_and_scale() _field_scale_and_write() v3 Some comments were modified. v3 Now using sysfs_emit() instead of scnprintf(). V2 Rename local function parameter field_mask to field_msk in order to avoid shadowing the name of function field_mask() from include/linux/bitfield.h. V2 Change a comment introduction from "/**" to "/*", as it is not intended to match a pattern that triggers documentation. Reported-by: kernel test robot V2 Slight movement of calls: - i915_hwmon_init slightly later, after call to i915_setup_sysfs() - i915_hwmon_fini slightly earlier, before i915_teardown_sysfs() V2 Fixed some strong typing issues with le32 functions. Detected by sparse in a run by kernel test robot: Reported-by: kernel test robot Dale B Stimson (1): drm/i915/dg1: Add HWMON power sensor support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h Range-diff against v3: 1: ed34d683a0ef1 ! 1: bc8bd78b2c006 drm/i915/dg1: Add HWMON power support @@ Metadata Author: Dale B Stimson ## Commit message ## -drm/i915/dg1: Add HWMON power support +drm/i915/dg1: Add HWMON power sensor support As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. -The following standard HWMON entries are currently supported +The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input @@ drivers/gpu/drm/i915/i915_drv.c #include "i915_irq.h" #include "i915_memcpy.h" @@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_register(struct drm_i915_private *dev_priv) - i915_debugfs_register(dev_priv); - i915_setup_sysfs(dev_priv); + + intel_gt_driver_register(_priv->gt); + i915_hwmon_register(dev_priv); + - /* Depends on sysfs having been initialized */ - i915_perf_register(dev_priv); + intel_display_driver_register(dev_priv); + intel_power_domains_enable(dev_priv); @@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_unregister(struct drm_i915_private *dev_priv) + + intel_display_driver_unregister(dev_priv); + ++ i915_hwmon_unregister(dev_priv); ++ intel_gt_driver_unregister(_priv->gt); i915_perf_unregister(dev_priv); -+ -+ i915_hwmon_unregister(dev_priv); + i915_pmu_unregister(dev_priv); @@ drivers/gpu/drm/i915/i915_hwmon.c (new) + +
[Intel-gfx] [PATCH v4 1/1] drm/i915/dg1: Add HWMON power sensor support
As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. Signed-off-by: Dale B Stimson --- .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon new file mode 100644 index 0..2ee7c413ca190 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -0,0 +1,116 @@ +What: /sys/devices/.../hwmon/hwmon/energy1_input +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Energy input of device in microjoules. + + The returned textual representation is an unsigned integer + number that can be stored in 64-bits. Warning: The hardware + register is 32-bits wide and can overflow by wrapping around. + A single wrap-around between calls to read this value can + be detected and will be accounted for in the returned value. + At a power consumption of 1 watt, the 32-bit hardware register + would wrap-around approximately every 3 days. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit is enabled - true or false. + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit in milliwatts + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_interval +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit interval in milliseconds over +which sustained power is averaged. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit is enabled - true or false + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit in milliwatts. + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_default_limit +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Default power limit. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_min_limit +Date: June 2021 +KernelVersion: 5.14
[Intel-gfx] [PATCH v4 0/1] drm/i915/dg1: Add HWMON power sensor support
drm/i915/dg1: Add HWMON power support As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON entries are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. - v4 Commit mesage minor rewording v4 Move call to i915_hwmon_register() to a more appropriate location, so that it is done after intel_gt_driver_register(). The call to i915_perf_unregister() is moved correspondingly. v4 The proper register to read energy status is PCU_PACKAGE_ENERGY_STATUS. v4 Attribute power1_max_enable is read-only. v3 Added documentation of these hwmon attributes in file Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon v3 Commit mesage minor rewording v3 Function name changes: i915_hwmon_init() -> i915_hwmon_register() i915_hwmon_fini() -> i915_hwmon_unregister() v3 i915_hwmon_register and i915_hwmon_unregister now take arg i915. v3 i915_hwmon_register() now returns void instead of int. v3 Macro FIELD_SHIFT() added to compute shift value from constant field mask. v3 Certain functions now longer require "inline" due to addition of new parameter field_shift, allowing access to constant expressions for the field mask at each call site. These functions now do field access via shift and masking and no longer use le32*() functions (as le32*() required a local constant expression for the mask). _field_read_and_scale() _field_read64_and_scale() _field_scale_and_write() v3 Some comments were modified. v3 Now using sysfs_emit() instead of scnprintf(). V2 Rename local function parameter field_mask to field_msk in order to avoid shadowing the name of function field_mask() from include/linux/bitfield.h. V2 Change a comment introduction from "/**" to "/*", as it is not intended to match a pattern that triggers documentation. Reported-by: kernel test robot V2 Slight movement of calls: - i915_hwmon_init slightly later, after call to i915_setup_sysfs() - i915_hwmon_fini slightly earlier, before i915_teardown_sysfs() V2 Fixed some strong typing issues with le32 functions. Detected by sparse in a run by kernel test robot: Reported-by: kernel test robot Dale B Stimson (1): drm/i915/dg1: Add HWMON power sensor support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h Range-diff against v3: 1: ed34d683a0ef1 ! 1: bc8bd78b2c006 drm/i915/dg1: Add HWMON power support @@ Metadata Author: Dale B Stimson ## Commit message ## -drm/i915/dg1: Add HWMON power support +drm/i915/dg1: Add HWMON power sensor support As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. -The following standard HWMON entries are currently supported +The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input @@ drivers/gpu/drm/i915/i915_drv.c #include "i915_irq.h" #include "i915_memcpy.h" @@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_register(struct drm_i915_private *dev_priv) - i915_debugfs_register(dev_priv); - i915_setup_sysfs(dev_priv); + + intel_gt_driver_register(_priv->gt); + i915_hwmon_register(dev_priv); + - /* Depends on sysfs having been initialized */ - i915_perf_register(dev_priv); + intel_display_driver_register(dev_priv); + intel_power_domains_enable(dev_priv); @@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_unregister(struct drm_i915_private *dev_priv) + + intel_display_driver_unregister(dev_priv); + ++ i915_hwmon_unregister(dev_priv); ++ intel_gt_driver_unregister(_priv->gt); i915_perf_unregister(dev_priv); -+ -+ i915_hwmon_unregister(dev_priv); + i915_pmu_unregister(dev_priv); @@ drivers/gpu/drm/i915/i915_hwmon.c (new) + +
Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter > Cc: Joel Stanley > Cc: Andrew Jeffery > Cc: "Noralf Trønnes" > Cc: Linus Walleij > Cc: Emma Anholt > Cc: David Lechner > Cc: Kamlesh Gurudasani > Cc: Oleksandr Andrushchenko > Cc: Daniel Vetter > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: Sam Ravnborg > Cc: Alex Deucher > Cc: Andy Shevchenko > Cc: linux-asp...@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: xen-de...@lists.xenproject.org Acked-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/1] drm/i915/dg1: Add HWMON power sensor support
As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. Signed-off-by: Dale B Stimson --- .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon new file mode 100644 index 0..2ee7c413ca190 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -0,0 +1,116 @@ +What: /sys/devices/.../hwmon/hwmon/energy1_input +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Energy input of device in microjoules. + + The returned textual representation is an unsigned integer + number that can be stored in 64-bits. Warning: The hardware + register is 32-bits wide and can overflow by wrapping around. + A single wrap-around between calls to read this value can + be detected and will be accounted for in the returned value. + At a power consumption of 1 watt, the 32-bit hardware register + would wrap-around approximately every 3 days. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit is enabled - true or false. + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit in milliwatts + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_interval +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit interval in milliseconds over +which sustained power is averaged. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit is enabled - true or false + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit in milliwatts. + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_default_limit +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Default power limit. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power_min_limit +Date: June 2021 +KernelVersion: 5.14
[Intel-gfx] [PATCH v4 0/1] drm/i915/dg1: Add HWMON power sensor support
drm/i915/dg1: Add HWMON power support As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON entries are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. - v4 Commit mesage minor rewording v4 Move call to i915_hwmon_register() to a more appropriate location, so that it is done after intel_gt_driver_register(). The call to i915_perf_unregister() is moved correspondingly. v4 The proper register to read energy status is PCU_PACKAGE_ENERGY_STATUS. v4 Attribute power1_max_enable is read-only. v3 Added documentation of these hwmon attributes in file Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon v3 Commit mesage minor rewording v3 Function name changes: i915_hwmon_init() -> i915_hwmon_register() i915_hwmon_fini() -> i915_hwmon_unregister() v3 i915_hwmon_register and i915_hwmon_unregister now take arg i915. v3 i915_hwmon_register() now returns void instead of int. v3 Macro FIELD_SHIFT() added to compute shift value from constant field mask. v3 Certain functions now longer require "inline" due to addition of new parameter field_shift, allowing access to constant expressions for the field mask at each call site. These functions now do field access via shift and masking and no longer use le32*() functions (as le32*() required a local constant expression for the mask). _field_read_and_scale() _field_read64_and_scale() _field_scale_and_write() v3 Some comments were modified. v3 Now using sysfs_emit() instead of scnprintf(). V2 Rename local function parameter field_mask to field_msk in order to avoid shadowing the name of function field_mask() from include/linux/bitfield.h. V2 Change a comment introduction from "/**" to "/*", as it is not intended to match a pattern that triggers documentation. Reported-by: kernel test robot V2 Slight movement of calls: - i915_hwmon_init slightly later, after call to i915_setup_sysfs() - i915_hwmon_fini slightly earlier, before i915_teardown_sysfs() V2 Fixed some strong typing issues with le32 functions. Detected by sparse in a run by kernel test robot: Reported-by: kernel test robot Dale B Stimson (1): drm/i915/dg1: Add HWMON power sensor support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h Range-diff against v3: 1: ed34d683a0ef1 ! 1: bc8bd78b2c006 drm/i915/dg1: Add HWMON power support @@ Metadata Author: Dale B Stimson ## Commit message ## -drm/i915/dg1: Add HWMON power support +drm/i915/dg1: Add HWMON power sensor support As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. -The following standard HWMON entries are currently supported +The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input @@ drivers/gpu/drm/i915/i915_drv.c #include "i915_irq.h" #include "i915_memcpy.h" @@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_register(struct drm_i915_private *dev_priv) - i915_debugfs_register(dev_priv); - i915_setup_sysfs(dev_priv); + + intel_gt_driver_register(_priv->gt); + i915_hwmon_register(dev_priv); + - /* Depends on sysfs having been initialized */ - i915_perf_register(dev_priv); + intel_display_driver_register(dev_priv); + intel_power_domains_enable(dev_priv); @@ drivers/gpu/drm/i915/i915_drv.c: static void i915_driver_unregister(struct drm_i915_private *dev_priv) + + intel_display_driver_unregister(dev_priv); + ++ i915_hwmon_unregister(dev_priv); ++ intel_gt_driver_unregister(_priv->gt); i915_perf_unregister(dev_priv); -+ -+ i915_hwmon_unregister(dev_priv); + i915_pmu_unregister(dev_priv); @@ drivers/gpu/drm/i915/i915_hwmon.c (new) + +
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting
== Series Details == Series: series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting URL : https://patchwork.freedesktop.org/series/90652/ State : success == Summary == CI Bug Log - changes from CI_DRM_10139_full -> Patchwork_20219_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20219_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-apl6/igt@gem_ctx_isolation@preservation...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_eio@in-flight-contexts-10ms: - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-tglb3/igt@gem_...@in-flight-contexts-10ms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_exec_fair@basic-deadline: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-tglb7/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-tglb2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-iclb8/igt@gem_exec_fair@basic-p...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-iclb8/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][16] ([i915#2389]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#3468]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-iclb2/igt@gem_mmap_...@cpuset-basic-small-copy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-iclb3/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#198] / [i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-skl4/igt@gem_mmap_...@cpuset-basic-small-copy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-skl9/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-tglb6/igt@gem_mmap_...@cpuset-basic-small-copy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-tglb8/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-medium-copy-odd: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#307]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10139/shard-glk3/igt@gem_mmap_...@cpuset-medium-copy-odd.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20219/shard-glk8/igt@gem_mmap_...@cpuset-medium-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-tglb: [PASS][25] -> [INCOMPLETE][26] ([i915#3468] /
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "i915: use io_mapping_map_user"
== Series Details ==
Series: Revert "i915: use io_mapping_map_user"
URL : https://patchwork.freedesktop.org/series/90696/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10145 -> Patchwork_20229
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/index.html
Known issues
Here are the changes found in Patchwork_20229 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-bsw-n3050: NOTRUN -> [INCOMPLETE][2] ([i915#3159])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#2782])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2: [FAIL][5] ([i915#2416]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@runner@aborted:
- fi-kbl-soraka: [FAIL][7] ([i915#1436] / [i915#3363]) -> [FAIL][8]
([i915#1436] / [i915#2426] / [i915#3363])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-kbl-soraka/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-7567u: [FAIL][9] ([i915#1436] / [i915#3363]) -> [FAIL][10]
([i915#1436] / [i915#2426] / [i915#3363])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-kbl-7567u/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-kbl-7567u/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][11] ([i915#1436] / [i915#3363]) -> [FAIL][12]
([i915#1436] / [i915#2426] / [i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-skl-6700k2/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2416]: https://gitlab.freedesktop.org/drm/intel/issues/2416
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3159]: https://gitlab.freedesktop.org/drm/intel/issues/3159
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
Participating hosts (43 -> 40)
--
Additional (1): fi-bsw-n3050
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10145 -> Patchwork_20229
CI-20190529: 20190529
CI_DRM_10145: 1b8b25e48b6d72ccd335a79d30c7e6641befb17b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6095: 5c7b7a8e441577a00cc4e71ec0ae57af640eb92a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_20229: 479d445cbfa3304df2fea5a473489cf5474534e2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
479d445cbfa3 Revert "i915: use io_mapping_map_user"
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20229/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "i915: use io_mapping_map_user"
== Series Details ==
Series: Revert "i915: use io_mapping_map_user"
URL : https://patchwork.freedesktop.org/series/90696/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
479d445cbfa3 Revert "i915: use io_mapping_map_user"
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 293837b9ac8d ("Revert "i915: fix
remap_io_sg to verify the pgprot"")'
#8:
We are unfortunately seeing more issues like we did in 293837b9ac8d
total: 1 errors, 0 warnings, 0 checks, 88 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
Re-reported. -Original Message- From: Deak, Imre Sent: Thursday, May 27, 2021 10:50 AM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana ; Sarvela, Tomi P Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies Hi Lakshmi, Tomi, On Thu, May 27, 2021 at 04:21:06PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies > URL : https://patchwork.freedesktop.org/series/90631/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20215_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20215_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20215_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20215_full: > > ### IGT changes ### > > Possible regressions > > * igt@drm_read@fault-buffer: > - shard-tglb: [PASS][1] -> [DMESG-WARN][2] +1 similar issue >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb5/igt@drm_r...@fault-buffer.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb5/i > gt@drm_r...@fault-buffer.html Unrelated platform. The same issue on shard-tglb5 was reported earlier, see https://lists.freedesktop.org/archives/igt-dev/2021-May/031535.html Could the eDP cable/panel get checked/replaced on this machine? > * igt@i915_pm_sseu@full-enable: > - shard-skl: [PASS][3] -> [FAIL][4] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl2/igt@i915_pm_s...@full-enable.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl2/ig > t@i915_pm_s...@full-enable.html Unrelated platform, a similar issue seen before: https://gitlab.freedesktop.org/drm/intel/-/issues/286 > Known issues > > > Here are the changes found in Patchwork_20215_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@legacy-engines-mixed: > - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2 > similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/ig > t@gem_ctx_persiste...@legacy-engines-mixed.html > > * igt@gem_exec_fair@basic-deadline: > - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk8/igt@gem_exec_f...@basic-deadline.html > - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/ig > t@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-none-share@rcs0: > - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb3/i > gt@gem_exec_fair@basic-none-sh...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs1: > - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html > - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/ig > t@gem_exec_fair@basic-n...@vcs1.html > > * igt@gem_exec_reloc@basic-wide-active@rcs0: > - shard-snb: NOTRUN -> [FAIL][14] ([i915#2389]) +2 similar issues >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/ig > t@gem_exec_reloc@basic-wide-act...@rcs0.html > > * igt@gem_exec_suspend@basic-s3: > - shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#180]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/ig > t@gem_exec_susp...@basic-s3.html > > * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: > - shard-apl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) +1 similar > issue >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html > - shard-kbl: [PASS][17] -> [INCOMPLETE][18]
[Intel-gfx] ✓ Fi.CI.BAT: success for Finish conversion to GRAPHICS_VER
== Series Details == Series: Finish conversion to GRAPHICS_VER URL : https://patchwork.freedesktop.org/series/90693/ State : success == Summary == CI Bug Log - changes from CI_DRM_10145 -> Patchwork_20228 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/index.html Known issues Here are the changes found in Patchwork_20228 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3: - fi-bsw-n3050: NOTRUN -> [INCOMPLETE][2] ([i915#3159]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@gt_heartbeat: - fi-skl-6700k2: [PASS][3] -> [DMESG-FAIL][4] ([i915#2291] / [i915#541]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#2782]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html Warnings * igt@i915_selftest@live@execlists: - fi-tgl-u2: [INCOMPLETE][7] ([i915#3462]) -> [DMESG-FAIL][8] ([i915#3462]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-tgl-u2/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/fi-tgl-u2/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-bdw-5557u: [FAIL][9] ([i915#3462]) -> [FAIL][10] ([i915#1602] / [i915#2029]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10145/fi-bdw-5557u/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/fi-bdw-5557u/igt@run...@aborted.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#3159]: https://gitlab.freedesktop.org/drm/intel/issues/3159 [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (43 -> 40) -- Additional (1): fi-bsw-n3050 Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_10145 -> Patchwork_20228 CI-20190529: 20190529 CI_DRM_10145: 1b8b25e48b6d72ccd335a79d30c7e6641befb17b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6095: 5c7b7a8e441577a00cc4e71ec0ae57af640eb92a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_20228: 473d823e72053a189d32c2758ea5589ede97af85 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 473d823e7205 drm/i915/display: replace IS_GEN() in commented code 39f44ce0df3a drm/i915: Add remaining conversions to GRAPHICS_VER e466a8d9d7b2 drm/i915: replace IS_GEN and friends with IS_GRAPHICS_VER 5f5511830f0a drm/i915/gvt: replace IS_GEN and friends with IS_GRAPHICS_VER bf349477ef65 drm/i915/gem: replace IS_GEN and friends with IS_GRAPHICS_VER dc0babe0e3f4 drm/i915/gt: Add remaining conversions to GRAPHICS_VER c7eb65fd23b6 drm/i915/gt: replace IS_GEN and friends with IS_GRAPHICS_VER == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20228/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Finish conversion to GRAPHICS_VER
== Series Details == Series: Finish conversion to GRAPHICS_VER URL : https://patchwork.freedesktop.org/series/90693/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Finish conversion to GRAPHICS_VER
== Series Details == Series: Finish conversion to GRAPHICS_VER URL : https://patchwork.freedesktop.org/series/90693/ State : warning == Summary == $ dim checkpatch origin/drm-tip c7eb65fd23b6 drm/i915/gt: replace IS_GEN and friends with IS_GRAPHICS_VER -:2316: WARNING:LONG_LINE: line length of 112 exceeds 100 columns #2316: FILE: drivers/gpu/drm/i915/gt/selftest_llc.c:47: + intel_gpu_freq(rps, gpu_freq * (GRAPHICS_VER(i915) >= 9 ? GEN9_FREQ_SCALER : 1)), -:2325: WARNING:LONG_LINE: line length of 112 exceeds 100 columns #2325: FILE: drivers/gpu/drm/i915/gt/selftest_llc.c:57: + intel_gpu_freq(rps, gpu_freq * (GRAPHICS_VER(i915) >= 9 ? GEN9_FREQ_SCALER : 1)), total: 0 errors, 2 warnings, 0 checks, 2252 lines checked dc0babe0e3f4 drm/i915/gt: Add remaining conversions to GRAPHICS_VER bf349477ef65 drm/i915/gem: replace IS_GEN and friends with IS_GRAPHICS_VER 5f5511830f0a drm/i915/gvt: replace IS_GEN and friends with IS_GRAPHICS_VER e466a8d9d7b2 drm/i915: replace IS_GEN and friends with IS_GRAPHICS_VER -:149: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #149: FILE: drivers/gpu/drm/i915/i915_debugfs.c:500: + (gt_perf_status & (GRAPHICS_VER(dev_priv) >= 9 ? 0x1ff00 : 0xff00)) >> 8); total: 0 errors, 1 warnings, 0 checks, 1352 lines checked 39f44ce0df3a drm/i915: Add remaining conversions to GRAPHICS_VER -:23: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #23: FILE: drivers/gpu/drm/i915/i915_drv.h:1567: +#define IS_GEN9_LP(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv)) -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #24: FILE: drivers/gpu/drm/i915/i915_drv.h:1568: +#define IS_GEN9_BC(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && !IS_LP(dev_priv)) -:59: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #59: FILE: drivers/gpu/drm/i915/i915_drv.h:1635: +#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \ IS_GEMINILAKE(dev_priv) || \ IS_KABYLAKE(dev_priv)) -:69: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #69: FILE: drivers/gpu/drm/i915/i915_drv.h:1642: +#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \ +!(IS_I915G(dev_priv) || IS_I915GM(dev_priv))) -:78: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #78: FILE: drivers/gpu/drm/i915/i915_drv.h:1649: +#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) >= 7) total: 0 errors, 0 warnings, 5 checks, 207 lines checked 473d823e7205 drm/i915/display: replace IS_GEN() in commented code ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gem: ioctl clean-ups (rev5)
== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev5) URL : https://patchwork.freedesktop.org/series/89443/ State : failure == Summary == Applying: drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Applying: drm/i915: Stop storing the ring size in the ring pointer (v2) Applying: drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Applying: drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2) Applying: drm/i915/gem: Return void from context_apply_all Applying: drm/i915: Drop the CONTEXT_CLONE API (v2) Applying: drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4) Applying: drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES Applying: drm/i915/gem: Disallow bonding of virtual engines (v3) Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_execlists_submission.c M drivers/gpu/drm/i915/gt/intel_execlists_submission.h M drivers/gpu/drm/i915/gt/selftest_execlists.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/selftest_execlists.c Auto-merging drivers/gpu/drm/i915/gt/intel_execlists_submission.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/intel_execlists_submission.h Auto-merging drivers/gpu/drm/i915/gt/intel_execlists_submission.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0009 drm/i915/gem: Disallow bonding of virtual engines (v3) When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Move LMEM (VRAM) management over to TTM
== Series Details == Series: Move LMEM (VRAM) management over to TTM URL : https://patchwork.freedesktop.org/series/90681/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gem/i915_gem_ttm.o drivers/gpu/drm/i915/gem/i915_gem_ttm.c:393:3: error: ‘struct ttm_device_funcs’ has no member named ‘verify_access’ .verify_access = NULL, ^ drivers/gpu/drm/i915/gem/i915_gem_ttm.c:395:23: error: initialized field overwritten [-Werror=override-init] .delete_mem_notify = i915_ttm_delete_mem_notify, ^~ drivers/gpu/drm/i915/gem/i915_gem_ttm.c:395:23: note: (near initialization for ‘i915_ttm_bo_driver.delete_mem_notify’) cc1: all warnings being treated as errors scripts/Makefile.build:272: recipe for target 'drivers/gpu/drm/i915/gem/i915_gem_ttm.o' failed make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_ttm.o] Error 1 scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:515: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1839: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
== Series Details == Series: drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies URL : https://patchwork.freedesktop.org/series/90631/ State : success == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20215_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20215_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2846]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk8/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][4] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][10] ([i915#2389]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][11] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][12] ([i915#3468]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([i915#3468]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-glk: NOTRUN -> [INCOMPLETE][15] ([i915#3468]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk6/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-skl: NOTRUN -> [INCOMPLETE][16] ([i915#198] / [i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl10/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-skl: NOTRUN -> [INCOMPLETE][17] ([i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl9/igt@gem_mmap_...@fault-concurrent-y.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_pwr...@basic-exhaustion.html - shard-apl: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_render_copy@yf-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb6/igt@gem_render_c...@yf-tiled-to-vebox-linear.html * igt@gem_softpin@noreloc-s3: - shard-apl: NOTRUN -> [DMESG-WARN][21] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl2/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#3323]) [22]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
== Series Details == Series: drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies URL : https://patchwork.freedesktop.org/series/90631/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20215_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20215_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20215_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20215_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-gtt-read-noreloc: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb5/igt@gem_exec_re...@basic-gtt-read-noreloc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb5/igt@gem_exec_re...@basic-gtt-read-noreloc.html Known issues Here are the changes found in Patchwork_20215_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk8/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][12] ([i915#2389]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][13] ([i915#180]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][14] ([i915#3468]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([i915#3468]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-glk: NOTRUN -> [INCOMPLETE][17] ([i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk6/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-skl: NOTRUN -> [INCOMPLETE][18] ([i915#198] / [i915#3468]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl10/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-skl: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl9/igt@gem_mmap_...@fault-concurrent-y.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_pwr...@basic-exhaustion.html -
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/ttm: Fix swapping dereferences of freed memory
== Series Details == Series: drm/ttm: Fix swapping dereferences of freed memory URL : https://patchwork.freedesktop.org/series/90673/ State : failure == Summary == Applying: drm/ttm: Fix swapping dereferences of freed memory error: sha1 information is lacking or useless (drivers/gpu/drm/ttm/ttm_bo.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/ttm: Fix swapping dereferences of freed memory When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
== Series Details == Series: drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies URL : https://patchwork.freedesktop.org/series/90631/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20215_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20215_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20215_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20215_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-gtt-read-noreloc: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb5/igt@gem_exec_re...@basic-gtt-read-noreloc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb5/igt@gem_exec_re...@basic-gtt-read-noreloc.html Known issues Here are the changes found in Patchwork_20215_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk8/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][12] ([i915#2389]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][13] ([i915#180]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][14] ([i915#3468]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([i915#3468]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-glk: NOTRUN -> [INCOMPLETE][17] ([i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk6/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-skl: NOTRUN -> [INCOMPLETE][18] ([i915#198] / [i915#3468]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl10/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-skl: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl9/igt@gem_mmap_...@fault-concurrent-y.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_pwr...@basic-exhaustion.html -
Re: [Intel-gfx] [RFC PATCH 24/97] drm/i915/guc: Add flag for mark broken CTB
On Thu, May 06, 2021 at 12:13:38PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> Once CTB descriptor is found in error state, either set by GuC
> or us, there is no need continue checking descriptor any more,
> we can rely on our internal flag.
>
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
> Cc: Piotr Piórkowski
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 ++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 1afdeac683b5..178f73ab2c96 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -123,6 +123,7 @@ static void guc_ct_buffer_desc_init(struct
> guc_ct_buffer_desc *desc,
>
> static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32
> cmds_addr)
> {
> + ctb->broken = false;
> guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
> }
>
> @@ -365,9 +366,12 @@ static int ct_write(struct intel_guc_ct *ct,
> u32 *cmds = ctb->cmds;
> unsigned int i;
>
> - if (unlikely(desc->is_in_error))
> + if (unlikely(ctb->broken))
> return -EPIPE;
>
> + if (unlikely(desc->is_in_error))
> + goto corrupted;
> +
> if (unlikely(!IS_ALIGNED(head | tail, 4) ||
>(tail | head) >= size))
> goto corrupted;
> @@ -423,6 +427,7 @@ static int ct_write(struct intel_guc_ct *ct,
> CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
>desc->addr, desc->head, desc->tail, desc->size);
> desc->is_in_error = 1;
> + ctb->broken = true;
> return -EPIPE;
> }
>
> @@ -608,9 +613,12 @@ static int ct_read(struct intel_guc_ct *ct, struct
> ct_incoming_msg **msg)
> unsigned int i;
> u32 header;
>
> - if (unlikely(desc->is_in_error))
> + if (unlikely(ctb->broken))
> return -EPIPE;
>
> + if (unlikely(desc->is_in_error))
> + goto corrupted;
> +
> if (unlikely(!IS_ALIGNED(head | tail, 4) ||
>(tail | head) >= size))
> goto corrupted;
> @@ -674,6 +682,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
> ct_incoming_msg **msg)
> CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
>desc->addr, desc->head, desc->tail, desc->size);
> desc->is_in_error = 1;
> + ctb->broken = true;
> return -EPIPE;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> index cb222f202301..7d3cd375d6a7 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> @@ -32,12 +32,14 @@ struct intel_guc;
> * @desc: pointer to the buffer descriptor
> * @cmds: pointer to the commands buffer
> * @size: size of the commands buffer
> + * @broken: flag to indicate if descriptor data is broken
> */
> struct intel_guc_ct_buffer {
> spinlock_t lock;
> struct guc_ct_buffer_desc *desc;
> u32 *cmds;
> u32 size;
> + bool broken;
> };
>
>
> --
> 2.28.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload
Re-reported. -Original Message- From: Deak, Imre Sent: Thursday, May 27, 2021 11:04 AM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload On Thu, May 27, 2021 at 10:02:11AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915/ddi: Flush encoder power domain > ref puts during driver unload > URL : https://patchwork.freedesktop.org/series/90613/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20207_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20207_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20207_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20207_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_mmap_gtt@fault-concurrent-y: > - shard-skl: NOTRUN -> [INCOMPLETE][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-skl5/ig > t@gem_mmap_...@fault-concurrent-y.html The test scenario/platform is not related to the changes in patches 1 and 2. I can't see how the change in patch 3 would introduce a hang; at most it would leave a display power well enabled triggering a power state check failure. Possibly related issues: https://gitlab.freedesktop.org/drm/intel/-/issues/3468 https://gitlab.freedesktop.org/drm/intel/-/issues/3485 > Known issues > > > Here are the changes found in Patchwork_20207_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@feature_discovery@display-3x: > - shard-tglb: NOTRUN -> [SKIP][2] ([i915#1839]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb3/i > gt@feature_discov...@display-3x.html > > * igt@gem_ctx_persistence@legacy-engines-mixed: > - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +6 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-snb2/ig > t@gem_ctx_persiste...@legacy-engines-mixed.html > > * igt@gem_eio@in-flight-contexts-1us: > - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_...@in-flight-contexts-1us.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb5/i > gt@gem_...@in-flight-contexts-1us.html > > * igt@gem_exec_fair@basic-deadline: > - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-glk9/igt@gem_exec_f...@basic-deadline.html > - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl7/ig > t@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-pace@rcs0: > - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar > issue >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-kbl1/ig > t@gem_exec_fair@basic-p...@rcs0.html > > * igt@gem_exec_reloc@basic-wide-active@rcs0: > - shard-snb: NOTRUN -> [FAIL][11] ([i915#2389]) +2 similar issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-snb2/ig > t@gem_exec_reloc@basic-wide-act...@rcs0.html > > * igt@gem_exec_suspend@basic-s3: > - shard-kbl: NOTRUN -> [DMESG-WARN][12] ([i915#180]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-kbl1/ig > t@gem_exec_susp...@basic-s3.html > > * igt@gem_mmap_gtt@cpuset-basic-small-copy: > - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#3468]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-apl6/igt@gem_mmap_...@cpuset-basic-small-copy.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy.html > - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198] / > [i915#3468]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl10/igt@gem_mmap_...@cpuset-basic-small-copy.html >[16]: >
[Intel-gfx] [PATCH] Revert "i915: use io_mapping_map_user"
This reverts commit b739f125e4ebd73d10ed30a856574e13649119ed.
We are unfortunately seeing more issues like we did in 293837b9ac8d
("Revert "i915: fix remap_io_sg to verify the pgprot""), except this is
now for the vm_fault_gtt path, where we are now hitting the same
BUG_ON(!pte_none(*pte)):
[10887.466150] kernel BUG at mm/memory.c:2183!
[10887.466162] invalid opcode: [#1] PREEMPT SMP PTI
[10887.466168] CPU: 0 PID: 7775 Comm: ffmpeg Tainted: G U
5.13.0-rc3-CI-Nightly #1
[10887.466174] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./J4205-ITX, BIOS P1.40 07/14/2017
[10887.466177] RIP: 0010:remap_pfn_range_notrack+0x30f/0x440
[10887.466188] Code: e8 96 d7 e0 ff 84 c0 0f 84 27 01 00 00 48 ba 00 f0 ff ff
ff ff 0f 00 4c 89 e0 48 c1 e0 0c 4d 85 ed 75 96 48 21 d0 31 f6 eb a9 <0f> 0b 48
39 37 0f 85 0e 01 00 00 48 8b 0c 24 48 39 4f 08 0f 85 00
[10887.466193] RSP: 0018:c90006e33c50 EFLAGS: 00010286
[10887.466198] RAX: 802f RBX: 7f5e0180 RCX: 0028
[10887.466201] RDX: 0001 RSI: ea00 RDI:
[10887.466204] RBP: ea33fea8 R08: 802f R09: 8881072256e0
[10887.466207] R10: c9000b84fff8 R11: 17dab000 R12: 00089f9f
[10887.466210] R13: 802f R14: 7f5e017e4000 R15: 88800cffaf20
[10887.466213] FS: 7f5e04849640() GS:88827800()
knlGS:
[10887.466216] CS: 0010 DS: ES: CR0: 80050033
[10887.466220] CR2: 7fd9b191a2ac CR3: 0001829ac000 CR4: 003506f0
[10887.466223] Call Trace:
[10887.466233] vm_fault_gtt+0x1ca/0x5d0 [i915]
[10887.466381] ? ktime_get+0x38/0x90
[10887.466389] __do_fault+0x37/0x90
[10887.466395] __handle_mm_fault+0xc46/0x1200
[10887.466402] handle_mm_fault+0xce/0x2a0
[10887.466407] do_user_addr_fault+0x1c5/0x660
Reverting this commit is reported to fix the issue.
Reported-by: Eero Tamminen
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3519
Fixes: b739f125e4eb ("i915: use io_mapping_map_user")
Cc: Christoph Hellwig
Cc: Daniel Vetter
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/Kconfig | 1 -
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 9 ++---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_mm.c | 44
4 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 93f4d059fc89..1e1cb245fca7 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -20,7 +20,6 @@ config DRM_I915
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
- select IO_MAPPING
select SYNC_FILE
select IOSF_MBI
select CRC32
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index f6fe5cb01438..8598a1c78a4c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -367,10 +367,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
goto err_unpin;
/* Finally, remap it using the new GTT offset */
- ret = io_mapping_map_user(>iomap, area, area->vm_start +
- (vma->ggtt_view.partial.offset << PAGE_SHIFT),
- (ggtt->gmadr.start + vma->node.start) >> PAGE_SHIFT,
- min_t(u64, vma->size, area->vm_end - area->vm_start));
+ ret = remap_io_mapping(area,
+ area->vm_start + (vma->ggtt_view.partial.offset
<< PAGE_SHIFT),
+ (ggtt->gmadr.start + vma->node.start) >>
PAGE_SHIFT,
+ min_t(u64, vma->size, area->vm_end -
area->vm_start),
+ >iomap);
if (ret)
goto err_fence;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f6d27da69ac..e926f20c5b82 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1941,6 +1941,9 @@ int i915_reg_read_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file);
/* i915_mm.c */
+int remap_io_mapping(struct vm_area_struct *vma,
+unsigned long addr, unsigned long pfn, unsigned long size,
+struct io_mapping *iomap);
int remap_io_sg(struct vm_area_struct *vma,
unsigned long addr, unsigned long size,
struct scatterlist *sgl, resource_size_t iobase);
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 9a777b0ff59b..666808cb3a32 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -37,6 +37,17 @@ struct remap_pfn {
resource_size_t iobase;
};
+static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
+{
+ struct remap_pfn *r = data;
+
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for shmem helpers for vgem
== Series Details == Series: shmem helpers for vgem URL : https://patchwork.freedesktop.org/series/90670/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10143 -> Patchwork_20224 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20224 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20224, 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_20224/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20224: ### IGT changes ### Possible regressions * igt@prime_vgem@basic-fence-mmap: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-bsw-nick/igt@prime_v...@basic-fence-mmap.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bsw-nick/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-fence-read: - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html - fi-ilk-650: [PASS][5] -> [INCOMPLETE][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-ilk-650/igt@prime_v...@basic-fence-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-ilk-650/igt@prime_v...@basic-fence-read.html - fi-elk-e7500: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-elk-e7500/igt@prime_v...@basic-fence-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-elk-e7500/igt@prime_v...@basic-fence-read.html - fi-bwr-2160:[PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-bwr-2160/igt@prime_v...@basic-fence-read.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bwr-2160/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - fi-ilk-650: [PASS][11] -> [FAIL][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-ilk-650/igt@prime_v...@basic-gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-ilk-650/igt@prime_v...@basic-gtt.html - fi-elk-e7500: [PASS][13] -> [FAIL][14] +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-elk-e7500/igt@prime_v...@basic-gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-elk-e7500/igt@prime_v...@basic-gtt.html * igt@prime_vgem@basic-read: - fi-bwr-2160:[PASS][15] -> [FAIL][16] +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-bwr-2160/igt@prime_v...@basic-read.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bwr-2160/igt@prime_v...@basic-read.html - fi-bsw-nick:[PASS][17] -> [FAIL][18] +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-bsw-nick/igt@prime_v...@basic-read.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bsw-nick/igt@prime_v...@basic-read.html - fi-bsw-kefka: [PASS][19] -> [FAIL][20] +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-bsw-kefka/igt@prime_v...@basic-read.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bsw-kefka/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-write: - fi-pnv-d510:[PASS][21] -> [FAIL][22] +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10143/fi-pnv-d510/igt@prime_v...@basic-write.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-pnv-d510/igt@prime_v...@basic-write.html Known issues Here are the changes found in Patchwork_20224 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][23] ([i915#2283]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@execlists: - fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][24] ([i915#3462]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20224/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html * igt@kms_frontbuffer_tracking@basic: - fi-tgl-u2: [PASS][25] -> [FAIL][26] ([i915#2416]) [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload
== Series Details == Series: series starting with [1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload URL : https://patchwork.freedesktop.org/series/90613/ State : success == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20207_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20207_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-3x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb3/igt@feature_discov...@display-3x.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +6 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_eio@in-flight-contexts-1us: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_...@in-flight-contexts-1us.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb5/igt@gem_...@in-flight-contexts-1us.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-glk9/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][10] ([i915#2389]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][11] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-kbl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: [PASS][12] -> [INCOMPLETE][13] ([i915#3468]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-apl6/igt@gem_mmap_...@cpuset-basic-small-copy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-skl: [PASS][14] -> [INCOMPLETE][15] ([i915#198] / [i915#3468]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl10/igt@gem_mmap_...@cpuset-basic-small-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-skl3/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-iclb: [PASS][16] -> [INCOMPLETE][17] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-iclb6/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-iclb3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][18] -> [FAIL][19] ([i915#307]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([i915#3468] / [i915#750]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_mmap_...@cpuset-medium-copy-xy.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb1/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-skl: NOTRUN -> [INCOMPLETE][22] ([i915#198] / [i915#3468]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-skl3/igt@gem_mmap_...@fault-concurrent-x.html - shard-apl: NOTRUN -> [INCOMPLETE][23] ([i915#3468]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl8/igt@gem_mmap_...@fault-concurrent-x.html - shard-kbl: NOTRUN -> [INCOMPLETE][24] ([i915#3468])
Re: [Intel-gfx] [PATCH 20/29] drm/i915/gem: Make an alignment check more sensible
On Thu, May 27, 2021 at 11:26:41AM -0500, Jason Ekstrand wrote:
> What we really want to check is that size of the engines array, i.e.
> args->size - sizeof(*user) is divisible by the element size, i.e.
> sizeof(*user->engines) because that's what's required for computing the
> array length right below the check. However, we're currently not doing
> this and instead doing a compile-time check that sizeof(*user) is
> divisible by sizeof(*user->engines) and avoiding the subtraction. As
> far as I can tell, the only reason for the more confusing pair of checks
> is to avoid a single subtraction of a constant.
>
> The other thing the BUILD_BUG_ON might be trying to implicitly check is
> that offsetof(user->engines) == sizeof(*user) and we don't have any
> weird padding throwing us off. However, that's not the check it's doing
> and it's not even a reliable way to do that check.
>
> Signed-off-by: Jason Ekstrand
Yeah a non-dense compiler should be able to figure this out, plus
set_engines isn't a hotpath.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 12a148ba421b6..cf7c281977a3e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1758,9 +1758,8 @@ set_engines(struct i915_gem_context *ctx,
> goto replace;
> }
>
> - BUILD_BUG_ON(!IS_ALIGNED(sizeof(*user), sizeof(*user->engines)));
> if (args->size < sizeof(*user) ||
> - !IS_ALIGNED(args->size, sizeof(*user->engines))) {
> + !IS_ALIGNED(args->size - sizeof(*user), sizeof(*user->engines))) {
> drm_dbg(>drm, "Invalid size for engine array: %d\n",
> args->size);
> return -EINVAL;
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/29] drm/i915: Add an i915_gem_vm_lookup helper
On Thu, May 27, 2021 at 11:26:40AM -0500, Jason Ekstrand wrote:
> This is the VM equivalent of i915_gem_context_lookup. It's only used
> once in this patch but future patches will need to duplicate this lookup
> code so it's better to have it in a helper.
>
> Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +-
> drivers/gpu/drm/i915/i915_drv.h | 14 ++
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index d247fb223aac7..12a148ba421b6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1346,11 +1346,7 @@ static int set_ppgtt(struct drm_i915_file_private
> *file_priv,
> if (upper_32_bits(args->value))
> return -ENOENT;
>
> - rcu_read_lock();
> - vm = xa_load(_priv->vm_xa, args->value);
> - if (vm && !kref_get_unless_zero(>ref))
> - vm = NULL;
> - rcu_read_unlock();
> + vm = i915_gem_vm_lookup(file_priv, args->value);
> if (!vm)
> return -ENOENT;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 48316d273af66..fee2342219da1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1871,6 +1871,20 @@ i915_gem_context_lookup(struct drm_i915_file_private
> *file_priv, u32 id)
> return ctx;
> }
>
> +static inline struct i915_address_space *
> +i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
> +{
> + struct i915_address_space *vm;
> +
> + rcu_read_lock();
> + vm = xa_load(_priv->vm_xa, id);
> + if (vm && !kref_get_unless_zero(>ref))
> + vm = NULL;
> + rcu_read_unlock();
> +
> + return vm;
> +}
> +
> /* i915_gem_evict.c */
> int __must_check i915_gem_evict_something(struct i915_address_space *vm,
> u64 min_size, u64 alignment,
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Resend More DMC cleanup
== Series Details == Series: Resend More DMC cleanup URL : https://patchwork.freedesktop.org/series/90635/ State : success == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20217_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20217_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#750]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb5/igt@drm_import_exp...@prime.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-tglb2/igt@drm_import_exp...@prime.html * igt@feature_discovery@display-3x: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#1839]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-tglb5/igt@feature_discov...@display-3x.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-snb2/igt@gem_ctx_persiste...@clone.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#3063]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb3/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-glk6/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][9] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-apl7/igt@gem_exec_f...@basic-deadline.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_20217/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_mmap_gtt@big-copy-odd: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#307]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl10/igt@gem_mmap_...@big-copy-odd.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-skl5/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-kbl1/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-glk: [PASS][19] -> [INCOMPLETE][20] ([i915#2055] / [i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk8/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-glk4/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-iclb6/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-iclb7/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@cpuset-medium-copy: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#307]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-iclb1/igt@gem_mmap_...@cpuset-medium-copy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20217/shard-iclb1/igt@gem_mmap_...@cpuset-medium-copy.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-apl: [PASS][25] -> [INCOMPLETE][26] ([i915#3468]) [25]:
[Intel-gfx] [PATCH 5/7] drm/i915: replace IS_GEN and friends with IS_GRAPHICS_VER
This was done by the following semantic patch:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_GRAPHICS_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ GRAPHICS_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_GRAPHICS_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_RANGE(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_cmd_parser.c| 10 +--
drivers/gpu/drm/i915/i915_debugfs.c | 32
drivers/gpu/drm/i915/i915_drv.c | 20 ++---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 80 +--
drivers/gpu/drm/i915/i915_irq.c | 34
drivers/gpu/drm/i915/i915_perf.c | 44 +-
drivers/gpu/drm/i915/i915_pmu.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 4 +-
drivers/gpu/drm/i915/i915_suspend.c | 16 ++--
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 22 ++---
drivers/gpu/drm/i915/intel_dram.c | 14 ++--
drivers/gpu/drm/i915/intel_pch.c | 10 +--
drivers/gpu/drm/i915/intel_pm.c | 14 ++--
drivers/gpu/drm/i915/intel_sideband.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 26 +++---
drivers/gpu/drm/i915/intel_wopcm.c| 10 +--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_perf.c| 6 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 8 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 12 +--
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
24 files changed, 193 insertions(+), 193 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5b4b2bd46e7c..3992c25a191d 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -946,8 +946,8 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
int cmd_table_count;
int ret;
- if (!IS_GEN(engine->i915, 7) && !(IS_GEN(engine->i915, 9) &&
- engine->class == COPY_ENGINE_CLASS))
+ if (GRAPHICS_VER(engine->i915) != 7 && !(GRAPHICS_VER(engine->i915) ==
9 &&
+engine->class ==
COPY_ENGINE_CLASS))
return 0;
switch (engine->class) {
@@ -977,7 +977,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
break;
case COPY_ENGINE_CLASS:
engine->get_cmd_length_mask = gen7_blt_get_cmd_length_mask;
- if (IS_GEN(engine->i915, 9)) {
+ if (GRAPHICS_VER(engine->i915) == 9) {
cmd_tables = gen9_blt_cmd_table;
cmd_table_count = ARRAY_SIZE(gen9_blt_cmd_table);
engine->get_cmd_length_mask =
@@ -993,7 +993,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
cmd_table_count = ARRAY_SIZE(gen7_blt_cmd_table);
}
- if (IS_GEN(engine->i915, 9)) {
+ if (GRAPHICS_VER(engine->i915) == 9) {
engine->reg_tables = gen9_blt_reg_tables;
engine->reg_table_count =
ARRAY_SIZE(gen9_blt_reg_tables);
@@ -1537,7 +1537,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs
*engine,
if (IS_HASWELL(engine->i915))
flags = MI_BATCH_NON_SECURE_HSW;
- GEM_BUG_ON(!IS_GEN_RANGE(engine->i915, 6, 7));
+ GEM_BUG_ON(!IS_GRAPHICS_VER(engine->i915, 6,
7));
__gen6_emit_bb_start(batch_end,
batch_addr,
flags);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a4d8a836bd57..0529576f069c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -361,7 +361,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
wakeref = intel_runtime_pm_get(_priv->runtime_pm);
[Intel-gfx] [PATCH 7/7] drm/i915/display: replace IS_GEN() in commented code
Since we are replacing IS_GEN() with GRAPHICS_VER(), make sure we take
care of the comments as well.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
b/drivers/gpu/drm/i915/display/intel_tv.c
index ce73ebdfc669..aa52af7891f0 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -1307,7 +1307,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
* the active portion. Hence following this formula seems
* more trouble that it's worth.
*
-* if (IS_GEN(dev_priv, 4)) {
+* if (GRAPHICS_VER(dev_priv) == 4) {
* num = cdclk * (tv_mode->oversample >> !tv_mode->progressive);
* den = tv_mode->clock;
* } else {
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Add remaining conversions to GRAPHICS_VER
For some reason coccinelle misses a few cases in header files with calls to INTEL_GEN()/IS_GEN(). Do a manual conversion for those. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_drv.h | 35 - drivers/gpu/drm/i915/i915_reg.h | 26 2 files changed, 30 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 0f6d27da69ac..ea8cc2656261 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1563,9 +1563,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, (IS_ALDERLAKE_P(__i915) && \ IS_GT_STEP(__i915, since, until)) -#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) -#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) -#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv)) +#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) +#define IS_GEN9_LP(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv)) +#define IS_GEN9_BC(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && !IS_LP(dev_priv)) #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id)) #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id) @@ -1585,12 +1585,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution * All later gens can run the final buffer from the ppgtt */ -#define CMDPARSER_USES_GGTT(dev_priv) IS_GEN(dev_priv, 7) +#define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7) #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop) #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb) -#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6) +#define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6) #define HAS_WT(dev_priv) HAS_EDRAM(dev_priv) #define HWS_NEEDS_PHYSICAL(dev_priv) (INTEL_INFO(dev_priv)->hws_needs_physical) @@ -1623,7 +1623,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || IS_I845G(dev_priv)) #define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv) \ - (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9)) + (IS_BROADWELL(dev_priv) || GRAPHICS_VER(dev_priv) == 9) /* WaRsDisableCoarsePowerGating:skl,cnl */ #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \ @@ -1631,23 +1631,22 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, IS_SKL_GT3(dev_priv) ||\ IS_SKL_GT4(dev_priv)) -#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4) -#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \ +#define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4) +#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \ IS_GEMINILAKE(dev_priv) || \ IS_KABYLAKE(dev_priv)) /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte * rows, which changed the alignment requirements and fence programming. */ -#define HAS_128_BYTE_Y_TILING(dev_priv) (!IS_GEN(dev_priv, 2) && \ -!(IS_I915G(dev_priv) || \ -IS_I915GM(dev_priv))) +#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \ +!(IS_I915G(dev_priv) || IS_I915GM(dev_priv))) #define SUPPORTS_TV(dev_priv) (INTEL_INFO(dev_priv)->display.supports_tv) #define I915_HAS_HOTPLUG(dev_priv) (INTEL_INFO(dev_priv)->display.has_hotplug) -#define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2) +#define HAS_FW_BLC(dev_priv) (GRAPHICS_VER(dev_priv) > 2) #define HAS_FBC(dev_priv) (INTEL_INFO(dev_priv)->display.has_fbc) -#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >= 7) +#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) >= 7) #define HAS_IPS(dev_priv) (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv)) @@ -1658,7 +1657,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr) #define HAS_PSR_HW_TRACKING(dev_priv) \ (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking) -#define HAS_PSR2_SEL_FETCH(dev_priv)(INTEL_GEN(dev_priv) >= 12) +#define HAS_PSR2_SEL_FETCH(dev_priv)(GRAPHICS_VER(dev_priv) >= 12) #define HAS_TRANSCODER(dev_priv, trans) ((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0) #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6) @@ -1669,7 +1668,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_DMC(dev_priv) (INTEL_INFO(dev_priv)->display.has_dmc)
[Intel-gfx] [PATCH 3/7] drm/i915/gem: replace IS_GEN and friends with IS_GRAPHICS_VER
This was done by the following semantic patch:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_GRAPHICS_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ GRAPHICS_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_GRAPHICS_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_RANGE(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 8
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 16
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 12 ++--
.../drm/i915/gem/selftests/i915_gem_client_blt.c | 10 +-
.../drm/i915/gem/selftests/i915_gem_coherency.c | 4 ++--
.../drm/i915/gem/selftests/i915_gem_context.c| 16
.../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +++---
.../gpu/drm/i915/gem/selftests/igt_gem_utils.c | 10 +-
10 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 188dee13e017..7720b8c22c81 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1190,7 +1190,7 @@ static void set_ppgtt_barrier(void *data)
{
struct i915_address_space *old = data;
- if (INTEL_GEN(old->i915) < 8)
+ if (GRAPHICS_VER(old->i915) < 8)
gen6_ppgtt_unpin_all(i915_vm_to_ppgtt(old));
i915_vm_close(old);
@@ -1436,7 +1436,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
context->max_eus_per_subslice = user->max_eus_per_subslice;
/* Part specific restrictions. */
- if (IS_GEN(i915, 11)) {
+ if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
unsigned int req_s = hweight8(context->slice_mask);
@@ -1503,7 +1503,7 @@ static int set_sseu(struct i915_gem_context *ctx,
if (args->size < sizeof(user_sseu))
return -EINVAL;
- if (!IS_GEN(i915, 11))
+ if (GRAPHICS_VER(i915) != 11)
return -ENODEV;
if (copy_from_user(_sseu, u64_to_user_ptr(args->value),
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 297143511f99..24c0582e46fb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -500,7 +500,7 @@ eb_validate_vma(struct i915_execbuffer *eb,
* also covers all platforms with local memory.
*/
if (entry->relocation_count &&
- INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+ GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
return -EINVAL;
if (unlikely(entry->flags & eb->invalid_flags))
@@ -1439,7 +1439,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
{
- return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
+ return engine->class != VIDEO_DECODE_CLASS ||
GRAPHICS_VER(engine->i915) != 6;
}
static u32 *reloc_gpu(struct i915_execbuffer *eb,
@@ -1671,7 +1671,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
- IS_GEN(eb->i915, 6)) {
+ GRAPHICS_VER(eb->i915) == 6) {
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
@@ -2332,7 +2332,7 @@ static int i915_reset_gen7_sol_offsets(struct
i915_request *rq)
u32 *cs;
int i;
- if (!IS_GEN(rq->engine->i915, 7) || rq->engine->id != RCS0) {
+ if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {
drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs only\n");
return -EINVAL;
}
@@ -3375,7 +3375,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
eb.batch_flags = 0;
if (args->flags &
[Intel-gfx] [PATCH 1/7] drm/i915/gt: replace IS_GEN and friends with IS_GRAPHICS_VER
This was done by the following semantic patch:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_GRAPHICS_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ GRAPHICS_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_GRAPHICS_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_RANGE(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 38 +--
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 +++
.../drm/i915/gt/intel_execlists_submission.c | 18 ++---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 27
.../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 ++--
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++--
drivers/gpu/drm/i915/gt/intel_llc.c | 6 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 46 ++---
drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +-
drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 12 ++--
.../gpu/drm/i915/gt/intel_ring_submission.c | 64 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 60 -
drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +--
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +-
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +--
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_rc6.c| 4 +-
.../drm/i915/gt/selftest_ring_submission.c| 6 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
44 files changed, 323 insertions(+), 322 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index d4f4452ce5ed..0389bceebd06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -85,14 +85,14 @@ static int gen6_drpc(struct seq_file *m)
gt_core_status = intel_uncore_read_fw(uncore, GEN6_GT_CORE_STATUS);
rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
- if (INTEL_GEN(i915) >= 9) {
+ if (GRAPHICS_VER(i915) >= 9) {
gen9_powergate_enable =
intel_uncore_read(uncore, GEN9_PG_ENABLE);
gen9_powergate_status =
intel_uncore_read(uncore, GEN9_PWRGT_DOMAIN_STATUS);
}
- if (INTEL_GEN(i915) <= 7)
+ if (GRAPHICS_VER(i915) <= 7)
sandybridge_pcode_read(i915, GEN6_PCODE_READ_RC6VIDS,
, NULL);
@@ -100,7 +100,7 @@ static int gen6_drpc(struct seq_file *m)
yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
seq_printf(m, "RC6 Enabled: %s\n",
yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
- if (INTEL_GEN(i915) >= 9) {
+ if (GRAPHICS_VER(i915) >= 9) {
seq_printf(m, "Render Well Gating Enabled: %s\n",
yesno(gen9_powergate_enable &
GEN9_RENDER_PG_ENABLE));
seq_printf(m, "Media Well Gating Enabled: %s\n",
@@ -134,7 +134,7 @@ static int
[Intel-gfx] [PATCH 4/7] drm/i915/gvt: replace IS_GEN and friends with IS_GRAPHICS_VER
This was done by the following semantic patch:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_GRAPHICS_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ GRAPHICS_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_GRAPHICS_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_RANGE(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Cc: intel-gvt-...@lists.freedesktop.org
Cc: Zhenyu Wang
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 8
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/gvt/fb_decoder.c | 10 +-
drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
drivers/gpu/drm/i915/gvt/interrupt.c| 2 +-
drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-
drivers/gpu/drm/i915/gvt/scheduler.c| 4 ++--
drivers/gpu/drm/i915/gvt/vgpu.c | 4 ++--
9 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index ca9c9e27a43d..c4118b808268 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1006,7 +1006,7 @@ static int cmd_reg_handler(struct parser_exec_state *s,
* update reg values in it into vregs, so LRIs in workload with
* inhibit context will restore with correct values
*/
- if (IS_GEN(s->engine->i915, 9) &&
+ if (GRAPHICS_VER(s->engine->i915) == 9 &&
intel_gvt_mmio_is_sr_in_ctx(gvt, offset) &&
!strncmp(cmd, "lri", 3)) {
intel_gvt_hypervisor_read_gpa(s->vgpu,
@@ -1390,7 +1390,7 @@ static int gen8_check_mi_display_flip(struct
parser_exec_state *s,
if (!info->async_flip)
return 0;
- if (INTEL_GEN(s->engine->i915) >= 9) {
+ if (GRAPHICS_VER(s->engine->i915) >= 9) {
stride = vgpu_vreg_t(s->vgpu, info->stride_reg) & GENMASK(9, 0);
tile = (vgpu_vreg_t(s->vgpu, info->ctrl_reg) &
GENMASK(12, 10)) >> 10;
@@ -1418,7 +1418,7 @@ static int gen8_update_plane_mmio_from_mi_display_flip(
set_mask_bits(_vreg_t(vgpu, info->surf_reg), GENMASK(31, 12),
info->surf_val << 12);
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
set_mask_bits(_vreg_t(vgpu, info->stride_reg), GENMASK(9,
0),
info->stride_val);
set_mask_bits(_vreg_t(vgpu, info->ctrl_reg), GENMASK(12,
10),
@@ -1446,7 +1446,7 @@ static int decode_mi_display_flip(struct
parser_exec_state *s,
{
if (IS_BROADWELL(s->engine->i915))
return gen8_decode_mi_display_flip(s, info);
- if (INTEL_GEN(s->engine->i915) >= 9)
+ if (GRAPHICS_VER(s->engine->i915) >= 9)
return skl_decode_mi_display_flip(s, info);
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..8e65cd8258b9 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -223,7 +223,7 @@ static struct drm_i915_gem_object *vgpu_create_gem(struct
drm_device *dev,
obj->read_domains = I915_GEM_DOMAIN_GTT;
obj->write_domain = 0;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
unsigned int tiling_mode = 0;
unsigned int stride = 0;
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 0889ad8291b0..11a8baba6822 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -151,7 +151,7 @@ static u32 intel_vgpu_get_stride(struct intel_vgpu *vgpu,
int pipe,
u32 stride_reg = vgpu_vreg_t(vgpu, DSPSTRIDE(pipe)) & stride_mask;
u32 stride = stride_reg;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
switch (tiled) {
case PLANE_CTL_TILED_LINEAR:
stride = stride_reg * 64;
@@ -215,7 +215,7 @@ int intel_vgpu_decode_primary_plane(struct intel_vgpu *vgpu,
if (!plane->enabled)
return -ENODEV;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
plane->tiled = val & PLANE_CTL_TILED_MASK;
fmt =
[Intel-gfx] [PATCH 2/7] drm/i915/gt: Add remaining conversions to GRAPHICS_VER
For some reason coccinelle misses a few cases in gt with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 0389bceebd06..4270b5a34a83 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -230,7 +230,7 @@ static int drpc_show(struct seq_file *m, void *unused)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
err = vlv_drpc(m);
- else if (INTEL_GEN(i915) >= 6)
+ else if (GRAPHICS_VER(i915) >= 6)
err = gen6_drpc(m);
else
err = ilk_drpc(m);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9ef349cd5cea..e113f93b3274 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -606,10 +606,10 @@ intel_engine_has_relative_mmio(const struct
intel_engine_cs * const engine)
}
#define instdone_has_slice(dev_priv___, sseu___, slice___) \
- ((IS_GEN(dev_priv___, 7) ? 1 : ((sseu___)->slice_mask)) & BIT(slice___))
+ ((GRAPHICS_VER(dev_priv___) == 7 ? 1 : ((sseu___)->slice_mask)) &
BIT(slice___))
#define instdone_has_subslice(dev_priv__, sseu__, slice__, subslice__) \
- (IS_GEN(dev_priv__, 7) ? (1 & BIT(subslice__)) : \
+ (GRAPHICS_VER(dev_priv__) == 7 ? (1 & BIT(subslice__)) : \
intel_sseu_has_subslice(sseu__, 0, subslice__))
#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
index 51780282d872..714fe8495775 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
@@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
struct sseu_dev_info sseu;
intel_wakeref_t wakeref;
- if (INTEL_GEN(i915) < 8)
+ if (GRAPHICS_VER(i915) < 8)
return -ENODEV;
seq_puts(m, "SSEU Device Info\n");
@@ -265,9 +265,9 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
cherryview_sseu_device_status(gt, );
else if (IS_BROADWELL(i915))
bdw_sseu_device_status(gt, );
- else if (IS_GEN(i915, 9))
+ else if (GRAPHICS_VER(i915) == 9)
gen9_sseu_device_status(gt, );
- else if (INTEL_GEN(i915) >= 10)
+ else if (GRAPHICS_VER(i915) >= 10)
gen10_sseu_device_status(gt, );
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Finish conversion to GRAPHICS_VER
Latest version of previous series "drm/i915: Extend GEN renames to the rest of the driver" (https://patchwork.freedesktop.org/series/88825/) dropped one patch converting all the instances of IS_GEN() and INTEL_GEN() to GRAPHICS_VER() due to the patches changing the meaning of the macros IS_GRAPHICS_VER/GRAPHICS_VER and removal of IS_GRAPHICS_RANGE(). I couldn't find a way to convince coccinelle to fix all places, so I just did it manually in separate commits the places that were not updated. Finish the conversion splitting the changes so it can go to the different branches (drm-intel-gt-next and drm-intel-next). I also split the gvt changes, but I think it would be easeir to take this directly on drm-intel-next. Also, please do not apply this series as I have other series I'd like to rebase on top before landing it. Cc: intel-gvt-...@lists.freedesktop.org Cc: Zhenyu Wang Lucas De Marchi (7): drm/i915/gt: replace IS_GEN and friends with IS_GRAPHICS_VER drm/i915/gt: Add remaining conversions to GRAPHICS_VER drm/i915/gem: replace IS_GEN and friends with IS_GRAPHICS_VER drm/i915/gvt: replace IS_GEN and friends with IS_GRAPHICS_VER drm/i915: replace IS_GEN and friends with IS_GRAPHICS_VER drm/i915: Add remaining conversions to GRAPHICS_VER drm/i915/display: replace IS_GEN() in commented code drivers/gpu/drm/i915/display/intel_tv.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 +-- .../gpu/drm/i915/gem/i915_gem_object_blt.c| 8 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 16 ++-- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 12 +-- .../i915/gem/selftests/i915_gem_client_blt.c | 10 +-- .../i915/gem/selftests/i915_gem_coherency.c | 4 +- .../drm/i915/gem/selftests/i915_gem_context.c | 16 ++-- .../drm/i915/gem/selftests/i915_gem_mman.c| 14 ++-- .../drm/i915/gem/selftests/igt_gem_utils.c| 10 +-- drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 40 +- drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 ++--- drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +- .../drm/i915/gt/intel_execlists_submission.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 drivers/gpu/drm/i915/gt/intel_gt.c| 27 --- .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 +-- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +- drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_llc.c | 6 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +-- drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c | 12 +-- .../gpu/drm/i915/gt/intel_ring_submission.c | 64 +++ drivers/gpu/drm/i915/gt/intel_rps.c | 60 +++--- drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +++ drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +- drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- drivers/gpu/drm/i915/gt/selftest_rc6.c| 4 +- .../drm/i915/gt/selftest_ring_submission.c| 6 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++-- drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +- drivers/gpu/drm/i915/gvt/fb_decoder.c | 10 +-- drivers/gpu/drm/i915/gvt/gtt.c| 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 6 +- drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-- drivers/gpu/drm/i915/gvt/scheduler.c
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for shmem helpers for vgem
== Series Details == Series: shmem helpers for vgem URL : https://patchwork.freedesktop.org/series/90670/ State : warning == Summary == $ dim checkpatch origin/drm-tip c1ff21db4f2a dma-buf: Require VM_PFNMAP vma for mmap -:34: WARNING:TYPO_SPELLING: 'entires' may be misspelled - perhaps 'entries'? #34: >From auditing the various functions to insert pfn pte entires ^^^ -:39: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #39: References: https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/ -:97: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 3 warnings, 0 checks, 39 lines checked feb77c89ec75 drm/vgem: use shmem helpers -:424: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 381 lines checked db7a46a2ca2f drm/shmem-helper: Switch to vmf_insert_pfn -:38: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 16 lines checked 9b3b6aecb7eb drm/shmem-helper: Align to page size in dumb_create -:37: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 15 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload
On Thu, May 27, 2021 at 10:02:11AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915/ddi: Flush encoder power domain > ref puts during driver unload > URL : https://patchwork.freedesktop.org/series/90613/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20207_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20207_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20207_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20207_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_mmap_gtt@fault-concurrent-y: > - shard-skl: NOTRUN -> [INCOMPLETE][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-skl5/igt@gem_mmap_...@fault-concurrent-y.html The test scenario/platform is not related to the changes in patches 1 and 2. I can't see how the change in patch 3 would introduce a hang; at most it would leave a display power well enabled triggering a power state check failure. Possibly related issues: https://gitlab.freedesktop.org/drm/intel/-/issues/3468 https://gitlab.freedesktop.org/drm/intel/-/issues/3485 > Known issues > > > Here are the changes found in Patchwork_20207_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@feature_discovery@display-3x: > - shard-tglb: NOTRUN -> [SKIP][2] ([i915#1839]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb3/igt@feature_discov...@display-3x.html > > * igt@gem_ctx_persistence@legacy-engines-mixed: > - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +6 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html > > * igt@gem_eio@in-flight-contexts-1us: > - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_...@in-flight-contexts-1us.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-tglb5/igt@gem_...@in-flight-contexts-1us.html > > * igt@gem_exec_fair@basic-deadline: > - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-glk9/igt@gem_exec_f...@basic-deadline.html > - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl7/igt@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-pace@rcs0: > - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar > issue >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html > > * igt@gem_exec_reloc@basic-wide-active@rcs0: > - shard-snb: NOTRUN -> [FAIL][11] ([i915#2389]) +2 similar issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html > > * igt@gem_exec_suspend@basic-s3: > - shard-kbl: NOTRUN -> [DMESG-WARN][12] ([i915#180]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-kbl1/igt@gem_exec_susp...@basic-s3.html > > * igt@gem_mmap_gtt@cpuset-basic-small-copy: > - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#3468]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-apl6/igt@gem_mmap_...@cpuset-basic-small-copy.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy.html > - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198] / > [i915#3468]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl10/igt@gem_mmap_...@cpuset-basic-small-copy.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20207/shard-skl3/igt@gem_mmap_...@cpuset-basic-small-copy.html > > * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: > - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#3468]) >[17]: >
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
Hi Lakshmi, Tomi, On Thu, May 27, 2021 at 04:21:06PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies > URL : https://patchwork.freedesktop.org/series/90631/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20215_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20215_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20215_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20215_full: > > ### IGT changes ### > > Possible regressions > > * igt@drm_read@fault-buffer: > - shard-tglb: [PASS][1] -> [DMESG-WARN][2] +1 similar issue >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb5/igt@drm_r...@fault-buffer.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb5/igt@drm_r...@fault-buffer.html Unrelated platform. The same issue on shard-tglb5 was reported earlier, see https://lists.freedesktop.org/archives/igt-dev/2021-May/031535.html Could the eDP cable/panel get checked/replaced on this machine? > * igt@i915_pm_sseu@full-enable: > - shard-skl: [PASS][3] -> [FAIL][4] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl2/igt@i915_pm_s...@full-enable.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl2/igt@i915_pm_s...@full-enable.html Unrelated platform, a similar issue seen before: https://gitlab.freedesktop.org/drm/intel/-/issues/286 > Known issues > > > Here are the changes found in Patchwork_20215_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@legacy-engines-mixed: > - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2 > similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html > > * igt@gem_exec_fair@basic-deadline: > - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk8/igt@gem_exec_f...@basic-deadline.html > - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-none-share@rcs0: > - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs1: > - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html > - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html > > * igt@gem_exec_reloc@basic-wide-active@rcs0: > - shard-snb: NOTRUN -> [FAIL][14] ([i915#2389]) +2 similar issues >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html > > * igt@gem_exec_suspend@basic-s3: > - shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#180]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_susp...@basic-s3.html > > * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: > - shard-apl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) +1 similar > issue >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html > - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([i915#3468]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html > > *
Re: [Intel-gfx] [PATCH 06/18] drm/i915/guc: Drop guc->interrupts.enabled
On Thu, May 27, 2021 at 10:17:20AM -0700, John Harrison wrote:
> On 5/25/2021 23:42, Matthew Brost wrote:
> > Drop the variable guc->interrupts.enabled as this variable is just
> > leading to bugs creeping into the code.
> >
> > e.g. A full GPU reset disables the GuC interrupts but forgot to clear
> > guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
> > interrupts from getting re-enabled and now we are broken.
> >
> > It is harmless to enable interrupt while already enabled so let's just
> > delete this variable to avoid bugs like this going forward.
> Is it worth leaving the enabled flag in place but only using it to trip a
> WARN to catch such cases in a less catastrophic manner? Or are there valid
> reasons for calling enable when already enabled?
>
I don't think so as mentioned above a reset disables these interrupts
and if we didn't clear this field the WARN_ON would be triggered making
CI unhappy. Yes, the bug would less catastrophic but we'd still have to
waste time and energy chasing it.
Matt
> Either way, it seems like a plausible change and CI is happy with it, so:
> Reviewed-by: John Harrison
>
> John.
>
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 27 +-
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 -
> > 2 files changed, 9 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > index ab2c8fe8cdfa..18da9ed15728 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -96,12 +96,9 @@ static void gen9_enable_guc_interrupts(struct intel_guc
> > *guc)
> > assert_rpm_wakelock_held(>i915->runtime_pm);
> > spin_lock_irq(>irq_lock);
> > - if (!guc->interrupts.enabled) {
> > - WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
> > -gt->pm_guc_events);
> > - guc->interrupts.enabled = true;
> > - gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
> > - }
> > + WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
> > +gt->pm_guc_events);
> > + gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
> > spin_unlock_irq(>irq_lock);
> > }
> > @@ -112,7 +109,6 @@ static void gen9_disable_guc_interrupts(struct
> > intel_guc *guc)
> > assert_rpm_wakelock_held(>i915->runtime_pm);
> > spin_lock_irq(>irq_lock);
> > - guc->interrupts.enabled = false;
> > gen6_gt_pm_disable_irq(gt, gt->pm_guc_events);
> > @@ -134,18 +130,14 @@ static void gen11_reset_guc_interrupts(struct
> > intel_guc *guc)
> > static void gen11_enable_guc_interrupts(struct intel_guc *guc)
> > {
> > struct intel_gt *gt = guc_to_gt(guc);
> > + u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
> > spin_lock_irq(>irq_lock);
> > - if (!guc->interrupts.enabled) {
> > - u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
> > -
> > - WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
> > - intel_uncore_write(gt->uncore,
> > - GEN11_GUC_SG_INTR_ENABLE, events);
> > - intel_uncore_write(gt->uncore,
> > - GEN11_GUC_SG_INTR_MASK, ~events);
> > - guc->interrupts.enabled = true;
> > - }
> > + WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
> > + intel_uncore_write(gt->uncore,
> > + GEN11_GUC_SG_INTR_ENABLE, events);
> > + intel_uncore_write(gt->uncore,
> > + GEN11_GUC_SG_INTR_MASK, ~events);
> > spin_unlock_irq(>irq_lock);
> > }
> > @@ -154,7 +146,6 @@ static void gen11_disable_guc_interrupts(struct
> > intel_guc *guc)
> > struct intel_gt *gt = guc_to_gt(guc);
> > spin_lock_irq(>irq_lock);
> > - guc->interrupts.enabled = false;
> > intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_MASK, ~0);
> > intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index c20f3839de12..4abc59f6f3cd 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -33,7 +33,6 @@ struct intel_guc {
> > unsigned int msg_enabled_mask;
> > struct {
> > - bool enabled;
> > void (*reset)(struct intel_guc *guc);
> > void (*enable)(struct intel_guc *guc);
> > void (*disable)(struct intel_guc *guc);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for A couple more prerequisite patches to GuC submission
== Series Details == Series: A couple more prerequisite patches to GuC submission URL : https://patchwork.freedesktop.org/series/90633/ State : success == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20216_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20216_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-3x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-tglb3/igt@feature_discov...@display-3x.html * igt@gem_create@create-clear: - shard-skl: [PASS][2] -> [FAIL][3] ([i915#3160]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl5/igt@gem_cre...@create-clear.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-skl7/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +5 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][7] ([i915#3316]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-skl8/igt@gem_ctx_ringsize@i...@bcs0.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +324 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-snb2/igt@gem_ctx_sha...@q-in-order.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#3063]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb3/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-tglb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_exec_f...@basic-deadline.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-kbl4/igt@gem_exec_f...@basic-deadline.html - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2846]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-glk4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][17] -> [FAIL][18] ([i915#2842] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-apl3/igt@gem_exec_fair@basic-n...@vecs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][21] ([i915#2389]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][22] ([i915#180]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-kbl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@big-copy-xy: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#307]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk4/igt@gem_mmap_...@big-copy-xy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20216/shard-glk4/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: [PASS][25] -> [INCOMPLETE][26] ([i915#3468]) [25]:
Re: [Intel-gfx] [PATCH 06/18] drm/i915/guc: Drop guc->interrupts.enabled
On 5/25/2021 23:42, Matthew Brost wrote:
Drop the variable guc->interrupts.enabled as this variable is just
leading to bugs creeping into the code.
e.g. A full GPU reset disables the GuC interrupts but forgot to clear
guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
interrupts from getting re-enabled and now we are broken.
It is harmless to enable interrupt while already enabled so let's just
delete this variable to avoid bugs like this going forward.
Is it worth leaving the enabled flag in place but only using it to trip
a WARN to catch such cases in a less catastrophic manner? Or are there
valid reasons for calling enable when already enabled?
Either way, it seems like a plausible change and CI is happy with it, so:
Reviewed-by: John Harrison
John.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 27 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 -
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index ab2c8fe8cdfa..18da9ed15728 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -96,12 +96,9 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
spin_lock_irq(>irq_lock);
- if (!guc->interrupts.enabled) {
- WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
- guc->interrupts.enabled = true;
- gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
- }
+ WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
+gt->pm_guc_events);
+ gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(>irq_lock);
}
@@ -112,7 +109,6 @@ static void gen9_disable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
spin_lock_irq(>irq_lock);
- guc->interrupts.enabled = false;
gen6_gt_pm_disable_irq(gt, gt->pm_guc_events);
@@ -134,18 +130,14 @@ static void gen11_reset_guc_interrupts(struct intel_guc *guc)
static void gen11_enable_guc_interrupts(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
+ u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
spin_lock_irq(>irq_lock);
- if (!guc->interrupts.enabled) {
- u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
-
- WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
- intel_uncore_write(gt->uncore,
- GEN11_GUC_SG_INTR_ENABLE, events);
- intel_uncore_write(gt->uncore,
- GEN11_GUC_SG_INTR_MASK, ~events);
- guc->interrupts.enabled = true;
- }
+ WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
+ intel_uncore_write(gt->uncore,
+ GEN11_GUC_SG_INTR_ENABLE, events);
+ intel_uncore_write(gt->uncore,
+ GEN11_GUC_SG_INTR_MASK, ~events);
spin_unlock_irq(>irq_lock);
}
@@ -154,7 +146,6 @@ static void gen11_disable_guc_interrupts(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
spin_lock_irq(>irq_lock);
- guc->interrupts.enabled = false;
intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_MASK, ~0);
intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index c20f3839de12..4abc59f6f3cd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -33,7 +33,6 @@ struct intel_guc {
unsigned int msg_enabled_mask;
struct {
- bool enabled;
void (*reset)(struct intel_guc *guc);
void (*enable)(struct intel_guc *guc);
void (*disable)(struct intel_guc *guc);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Non-interface changing GuC CTBs updates (rev2)
On Thu, May 27, 2021 at 10:13:21AM -0700, John Harrison wrote:
> On 5/25/2021 23:42, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Non-interface changing GuC CTBs updates (rev2)
> > URL : https://patchwork.freedesktop.org/series/90552/
> > State : warning
> >
> > == Summary ==
> >
> > $ dim checkpatch origin/drm-tip
> > 6b6bffd59ced drm/i915/guc: skip disabling CTBs before sanitizing the GuC
> > 3f9bbaddbf9d drm/i915/guc: use probe_error log for CT enablement failure
> > 866285dad8d0 drm/i915/guc: enable only the user interrupt when using GuC
> > submission
> > eafc57f85f6f drm/i915/guc: Remove sample_forcewake h2g action
> > cb62a7f50e3b drm/i915/guc: Keep strict GuC ABI definitions
> > -:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
> > MAINTAINERS need updating?
> > #18:
> > new file mode 100644
> >
> > total: 0 errors, 1 warnings, 0 checks, 476 lines checked
> > 28e9b20a7873 drm/i915/guc: Drop guc->interrupts.enabled
> > 190975af8c9f drm/i915/guc: Stop using fence/status from CTB descriptor
> > 15a068ac5b1e drm/i915: Promote ptrdiff() to i915_utils.h
> > e3a6d58106c2 drm/i915/guc: Only rely on own CTB size
> > aaa8781a008e drm/i915/guc: Don't repeat CTB layout calculations
> > b065023c038e drm/i915/guc: Replace CTB array with explicit members
> > 9f1ec21626ae drm/i915/guc: Update sizes of CTB buffers
> > 7a0e05be601b drm/i915/guc: Relax CTB response timeout
> > 11573d2c3987 drm/i915/guc: Start protecting access to CTB descriptors
> > -:87: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
> > #87: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h:36:
> > + spinlock_t lock;
> >
> > total: 0 errors, 0 warnings, 1 checks, 61 lines checked
> > f32e4faa422e drm/i915/guc: Ensure H2G buffer updates visible before tail
> > update
> > -:23: ERROR:OPEN_BRACE: open brace '{' following function definitions go on
> > the next line
> > #23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:331:
> > +static void write_barrier(struct intel_guc_ct *ct) {
> >
> > -:31: WARNING:MEMORY_BARRIER: memory barrier without comment
> > #31: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:339:
> > + wmb();
> These three warnings should be fixed.
>
Will do. But it seems odd to require comments for these.
> John.
>
> > total: 1 errors, 1 warnings, 0 checks, 30 lines checked
> > 6feab437948e drm/i915/guc: Stop using mutex while sending CTB messages
> > a44bbeef3e75 drm/i915/guc: Don't receive all G2H messages in irq handler
> > 41650b9fd9e5 drm/i915/guc: Always copy CT message to new allocation
> >
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Non-interface changing GuC CTBs updates (rev2)
On Thu, May 27, 2021 at 10:13:11AM -0700, John Harrison wrote: > AFAICT, none of these warnings are related to this patch set. > Yep, other series submitted around the same time as this had the same warnings. > John. > > > On 5/25/2021 23:43, Patchwork wrote: > > == Series Details == > > > > Series: Non-interface changing GuC CTBs updates (rev2) > > URL : https://patchwork.freedesktop.org/series/90552/ > > State : warning > > > > == Summary == > > > > $ dim sparse --fast origin/drm-tip > > Sparse version: v0.6.2 > > Fast mode used, each commit won't be checked separately. > > - > > +drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct > > i915_vma *[assigned] vma > > +drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void > > [noderef] __iomem *[assigned] iomem > > +drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect > > type in assignment (different address spaces) > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy > > expression type 31 > > +drivers/gpu/drm/i915/gt/intel_reset.c:1328:5: warning: context imbalance > > in 'intel_gt_reset_trylock' - different lock contexts for basic block > > +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using > > plain integer as NULL pointer > > +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count > > of 16777216 > > +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count > > of 16777216 > > +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in > > 'wakeref_auto_timeout' - unexpected unlock > > +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | > > !y > > +./include/asm-generic/bitops/find.h:112:45: warning: shift count is > > negative (-262080) > > +./include/asm-generic/bitops/find.h:32:31: warning: shift count is > > negative (-262080) > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_read16' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_read32' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_read64' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_read8' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_write16' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_write32' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'fwtable_write8' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_read16' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_read32' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_read64' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_read8' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_write16' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_write32' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen11_fwtable_write8' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen12_fwtable_read16' - different lock contexts for basic block > > +./include/linux/spinlock.h:409:9: warning: context imbalance in > > 'gen12_fwtable_read32' -
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Non-interface changing GuC CTBs updates (rev2)
On 5/25/2021 23:42, Patchwork wrote:
== Series Details ==
Series: Non-interface changing GuC CTBs updates (rev2)
URL : https://patchwork.freedesktop.org/series/90552/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6b6bffd59ced drm/i915/guc: skip disabling CTBs before sanitizing the GuC
3f9bbaddbf9d drm/i915/guc: use probe_error log for CT enablement failure
866285dad8d0 drm/i915/guc: enable only the user interrupt when using GuC
submission
eafc57f85f6f drm/i915/guc: Remove sample_forcewake h2g action
cb62a7f50e3b drm/i915/guc: Keep strict GuC ABI definitions
-:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#18:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 476 lines checked
28e9b20a7873 drm/i915/guc: Drop guc->interrupts.enabled
190975af8c9f drm/i915/guc: Stop using fence/status from CTB descriptor
15a068ac5b1e drm/i915: Promote ptrdiff() to i915_utils.h
e3a6d58106c2 drm/i915/guc: Only rely on own CTB size
aaa8781a008e drm/i915/guc: Don't repeat CTB layout calculations
b065023c038e drm/i915/guc: Replace CTB array with explicit members
9f1ec21626ae drm/i915/guc: Update sizes of CTB buffers
7a0e05be601b drm/i915/guc: Relax CTB response timeout
11573d2c3987 drm/i915/guc: Start protecting access to CTB descriptors
-:87: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#87: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h:36:
+ spinlock_t lock;
total: 0 errors, 0 warnings, 1 checks, 61 lines checked
f32e4faa422e drm/i915/guc: Ensure H2G buffer updates visible before tail update
-:23: ERROR:OPEN_BRACE: open brace '{' following function definitions go on the
next line
#23: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:331:
+static void write_barrier(struct intel_guc_ct *ct) {
-:31: WARNING:MEMORY_BARRIER: memory barrier without comment
#31: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:339:
+ wmb();
These three warnings should be fixed.
John.
total: 1 errors, 1 warnings, 0 checks, 30 lines checked
6feab437948e drm/i915/guc: Stop using mutex while sending CTB messages
a44bbeef3e75 drm/i915/guc: Don't receive all G2H messages in irq handler
41650b9fd9e5 drm/i915/guc: Always copy CT message to new allocation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Non-interface changing GuC CTBs updates (rev2)
AFAICT, none of these warnings are related to this patch set. John. On 5/25/2021 23:43, Patchwork wrote: == Series Details == Series: Non-interface changing GuC CTBs updates (rev2) URL : https://patchwork.freedesktop.org/series/90552/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1887:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1328:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in
Re: [Intel-gfx] [RFC PATCH 60/97] drm/i915: Track 'serial' counts for virtual engines
On 5/27/2021 01:53, Tvrtko Ursulin wrote: On 26/05/2021 19:45, John Harrison wrote: On 5/26/2021 01:40, Tvrtko Ursulin wrote: On 25/05/2021 18:52, Matthew Brost wrote: On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote: On 06/05/2021 20:14, Matthew Brost wrote: From: John Harrison The serial number tracking of engines happens at the backend of request submission and was expecting to only be given physical engines. However, in GuC submission mode, the decomposition of virtual to physical engines does not happen in i915. Instead, requests are submitted to their virtual engine mask all the way through to the hardware (i.e. to GuC). This would mean that the heart beat code thinks the physical engines are idle due to the serial number not incrementing. This patch updates the tracking to decompose virtual engines into their physical constituents and tracks the request against each. This is not entirely accurate as the GuC will only be issuing the request to one physical engine. However, it is the best that i915 can do given that it has no knowledge of the GuC's scheduling decisions. Commit text sounds a bit defeatist. I think instead of making up the serial counts, which has downsides (could you please document in the commit what they are), we should think how to design things properly. IMO, I don't think fixing serial counts is the scope of this series. We should focus on getting GuC submission in not cleaning up all the crap that is in the i915. Let's make a note of this though so we can revisit later. I will say again - commit message implies it is introducing an unspecified downside by not fully fixing an also unspecified issue. It is completely reasonable, and customary even, to ask for both to be documented in the commit message. Not sure what exactly is 'unspecified'. I thought the commit message described both the problem (heartbeat not running when using virtual engines) and the result (heartbeat running on more engines than strictly necessary). But in greater detail... The serial number tracking is a hack for the heartbeat code to know whether an engine is busy or idle, and therefore whether it should be pinged for aliveness. Whenever a submission is made to an engine, the serial number is incremented. The heartbeat code keeps a copy of the value. If the value has changed, the engine is busy and needs to be pinged. This works fine for execlist mode where virtual engine decomposition is done inside i915. It fails miserably for GuC mode where the decomposition is done by the hardware. The reason being that the heartbeat code only looks at physical engines but the serial count is only incremented on the virtual engine. Thus, the heartbeat sees everything as idle and does not ping. So hangcheck does not work. Or it works because GuC does it anyway. Either way, that's one thing to explicitly state in the commit message. This patch decomposes the virtual engines for the sake of incrementing the serial count on each sub-engine in order to keep the heartbeat code happy. The downside is that now the heartbeat sees all sub-engines as busy rather than only the one the submission actually ends up on. There really isn't much that can be done about that. The heartbeat code is in i915 not GuC, the scheduler is in GuC not i915. The only way to improve it is to either move the heartbeat code into GuC as well and completely disable the i915 side, or add some way for i915 to interrogate GuC as to which engines are or are not active. Technically, we do have both. GuC has (or at least had) an option to force a context switch on every execution quantum pre-emption. However, that is much, much, more heavy weight than the heartbeat. For the latter, we do (almost) have the engine usage statistics for PMU and such like. I'm not sure how much effort it would be to wire that up to the heartbeat code instead of using the serial count. In short, the serial count is ever so slightly inefficient in that it causes heartbeat pings on engines which are idle. On the other hand, it is way more efficient and simpler than the current alternatives. And the hack to make hangcheck work creates this inefficiency where heartbeats are sent to idle engines. Which is probably fine just needs to be explained. Does that answer the questions? With the two points I re-raise clearly explained, possibly even patch title changed, yeah. I am just wanting for it to be more easily obvious to patch reader what it is functionally about - not just what implementation details have been change but why as well. My understanding is that we don't explain every piece of code in minute detail in every checkin email that touches it. I thought my description was already pretty verbose. I've certainly seen way less informative checkins that apparently made it through review without issue. Regarding the problem statement, I thought this was fairly clear that the
[Intel-gfx] [PATCH 17/29] drm/i915/gem: Rework error handling in default_engines
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 10bff488444b6..f8f3f514b4265 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -420,7 +420,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
{
const struct intel_gt *gt = >i915->gt;
struct intel_engine_cs *engine;
- struct i915_gem_engines *e;
+ struct i915_gem_engines *e, *err;
enum intel_engine_id id;
e = alloc_engines(I915_NUM_ENGINES);
@@ -438,18 +438,21 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
- __free_engines(e, e->num_engines + 1);
- return ERR_CAST(ce);
+ err = ERR_CAST(ce);
+ goto free_engines;
}
intel_context_set_gem(ce, ctx);
e->engines[engine->legacy_idx] = ce;
- e->num_engines = max(e->num_engines, engine->legacy_idx);
+ e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
}
- e->num_engines++;
return e;
+
+free_engines:
+ free_engines(e);
+ return err;
}
void i915_gem_context_release(struct kref *ref)
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/29] drm/i915/gem: Add a separate validate_priority helper
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 910d31cb043e9..fc471243aa769 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -169,6 +169,28 @@ lookup_user_engine(struct i915_gem_context *ctx,
return i915_gem_context_get_engine(ctx, idx);
}
+static int validate_priority(struct drm_i915_private *i915,
+const struct drm_i915_gem_context_param *args)
+{
+ s64 priority = args->value;
+
+ if (args->size)
+ return -EINVAL;
+
+ if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PRIORITY))
+ return -ENODEV;
+
+ if (priority > I915_CONTEXT_MAX_USER_PRIORITY ||
+ priority < I915_CONTEXT_MIN_USER_PRIORITY)
+ return -EINVAL;
+
+ if (priority > I915_CONTEXT_DEFAULT_PRIORITY &&
+ !capable(CAP_SYS_NICE))
+ return -EPERM;
+
+ return 0;
+}
+
static struct i915_address_space *
context_get_vm_rcu(struct i915_gem_context *ctx)
{
@@ -1744,23 +1766,13 @@ static void __apply_priority(struct intel_context *ce,
void *arg)
static int set_priority(struct i915_gem_context *ctx,
const struct drm_i915_gem_context_param *args)
{
- s64 priority = args->value;
-
- if (args->size)
- return -EINVAL;
-
- if (!(ctx->i915->caps.scheduler & I915_SCHEDULER_CAP_PRIORITY))
- return -ENODEV;
-
- if (priority > I915_CONTEXT_MAX_USER_PRIORITY ||
- priority < I915_CONTEXT_MIN_USER_PRIORITY)
- return -EINVAL;
+ int err;
- if (priority > I915_CONTEXT_DEFAULT_PRIORITY &&
- !capable(CAP_SYS_NICE))
- return -EPERM;
+ err = validate_priority(ctx->i915, args);
+ if (err)
+ return err;
- ctx->sched.priority = priority;
+ ctx->sched.priority = args->value;
context_apply_all(ctx, __apply_priority, ctx);
return 0;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 27/29] drm/i915/selftests: Take a VM in kernel_context()
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 9 -
.../gpu/drm/i915/gem/selftests/mock_context.h | 4 +++-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 20 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
5 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 506cd9e9d4b25..aee5642818824 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -680,7 +680,7 @@ static int igt_ctx_exec(void *arg)
struct i915_gem_context *ctx;
struct intel_context *ce;
- ctx = kernel_context(i915);
+ ctx = kernel_context(i915, NULL);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto out_file;
@@ -813,7 +813,7 @@ static int igt_shared_ctx_exec(void *arg)
struct i915_gem_context *ctx;
struct intel_context *ce;
- ctx = kernel_context(i915);
+ ctx = kernel_context(i915, NULL);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto out_test;
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
index 61aaac4a334cf..500ef27ba4771 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
@@ -150,7 +150,8 @@ live_context_for_engine(struct intel_engine_cs *engine,
struct file *file)
}
struct i915_gem_context *
-kernel_context(struct drm_i915_private *i915)
+kernel_context(struct drm_i915_private *i915,
+ struct i915_address_space *vm)
{
struct i915_gem_context *ctx;
struct i915_gem_proto_context *pc;
@@ -159,6 +160,12 @@ kernel_context(struct drm_i915_private *i915)
if (IS_ERR(pc))
return ERR_CAST(pc);
+ if (vm) {
+ if (pc->vm)
+ i915_vm_put(pc->vm);
+ pc->vm = i915_vm_get(vm);
+ }
+
ctx = i915_gem_create_context(i915, pc);
proto_context_close(pc);
if (IS_ERR(ctx))
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
index 2a6121d33352d..7a02fd9b5866a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
@@ -10,6 +10,7 @@
struct file;
struct drm_i915_private;
struct intel_engine_cs;
+struct i915_address_space;
void mock_init_contexts(struct drm_i915_private *i915);
@@ -25,7 +26,8 @@ live_context(struct drm_i915_private *i915, struct file
*file);
struct i915_gem_context *
live_context_for_engine(struct intel_engine_cs *engine, struct file *file);
-struct i915_gem_context *kernel_context(struct drm_i915_private *i915);
+struct i915_gem_context *kernel_context(struct drm_i915_private *i915,
+ struct i915_address_space *vm);
void kernel_context_close(struct i915_gem_context *ctx);
#endif /* !__MOCK_CONTEXT_H */
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index a0e75b71a3374..0989e024f7a03 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -1522,12 +1522,12 @@ static int live_busywait_preempt(void *arg)
* preempt the busywaits used to synchronise between rings.
*/
- ctx_hi = kernel_context(gt->i915);
+ ctx_hi = kernel_context(gt->i915, NULL);
if (!ctx_hi)
return -ENOMEM;
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
- ctx_lo = kernel_context(gt->i915);
+ ctx_lo = kernel_context(gt->i915, NULL);
if (!ctx_lo)
goto err_ctx_hi;
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
@@ -1724,12 +1724,12 @@ static int live_preempt(void *arg)
if (igt_spinner_init(_lo, gt))
goto err_spin_hi;
- ctx_hi = kernel_context(gt->i915);
+ ctx_hi = kernel_context(gt->i915, NULL);
if (!ctx_hi)
goto err_spin_lo;
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
- ctx_lo = kernel_context(gt->i915);
+ ctx_lo = kernel_context(gt->i915, NULL);
if (!ctx_lo)
goto err_ctx_hi;
ctx_lo->sched.priority =
[Intel-gfx] [PATCH 26/29] drm/i915/gem: Don't allow changing the engine set on running contexts (v2)
When the APIs were added to manage the engine set on a GEM context
directly from userspace, the questionable choice was made to allow
changing the engine set on a context at any time. This is horribly racy
and there's absolutely no reason why any userspace would want to do this
outside of trying to exercise interesting race conditions. By removing
support for CONTEXT_PARAM_ENGINES from ctx_setparam, we make it
impossible to change the engine set after the context has been fully
created.
This doesn't yet let us delete all the deferred engine clean-up code as
that's still used for handling the case where the client dies or calls
GEM_CONTEXT_DESTROY while work is in flight. However, moving to an API
where the engine set is effectively immutable gives us more options to
potentially clean that code up a bit going forward. It also removes a
whole class of ways in which a client can hurt itself or try to get
around kernel context banning.
v2 (Jason Ekstrand):
- Expand the commit mesage
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 303
1 file changed, 303 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a528c8f3354a0..e6a6ead477ff4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1819,305 +1819,6 @@ static int set_sseu(struct i915_gem_context *ctx,
return ret;
}
-struct set_engines {
- struct i915_gem_context *ctx;
- struct i915_gem_engines *engines;
-};
-
-static int
-set_engines__load_balance(struct i915_user_extension __user *base, void *data)
-{
- struct i915_context_engines_load_balance __user *ext =
- container_of_user(base, typeof(*ext), base);
- const struct set_engines *set = data;
- struct drm_i915_private *i915 = set->ctx->i915;
- struct intel_engine_cs *stack[16];
- struct intel_engine_cs **siblings;
- struct intel_context *ce;
- struct intel_sseu null_sseu = {};
- u16 num_siblings, idx;
- unsigned int n;
- int err;
-
- if (!HAS_EXECLISTS(i915))
- return -ENODEV;
-
- if (intel_uc_uses_guc_submission(>gt.uc))
- return -ENODEV; /* not implement yet */
-
- if (get_user(idx, >engine_index))
- return -EFAULT;
-
- if (idx >= set->engines->num_engines) {
- drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
- idx, set->engines->num_engines);
- return -EINVAL;
- }
-
- idx = array_index_nospec(idx, set->engines->num_engines);
- if (set->engines->engines[idx]) {
- drm_dbg(>drm,
- "Invalid placement[%d], already occupied\n", idx);
- return -EEXIST;
- }
-
- if (get_user(num_siblings, >num_siblings))
- return -EFAULT;
-
- err = check_user_mbz(>flags);
- if (err)
- return err;
-
- err = check_user_mbz(>mbz64);
- if (err)
- return err;
-
- siblings = stack;
- if (num_siblings > ARRAY_SIZE(stack)) {
- siblings = kmalloc_array(num_siblings,
-sizeof(*siblings),
-GFP_KERNEL);
- if (!siblings)
- return -ENOMEM;
- }
-
- for (n = 0; n < num_siblings; n++) {
- struct i915_engine_class_instance ci;
-
- if (copy_from_user(, >engines[n], sizeof(ci))) {
- err = -EFAULT;
- goto out_siblings;
- }
-
- siblings[n] = intel_engine_lookup_user(i915,
- ci.engine_class,
- ci.engine_instance);
- if (!siblings[n]) {
- drm_dbg(>drm,
- "Invalid sibling[%d]: { class:%d, inst:%d }\n",
- n, ci.engine_class, ci.engine_instance);
- err = -EINVAL;
- goto out_siblings;
- }
- }
-
- ce = intel_execlists_create_virtual(siblings, n);
- if (IS_ERR(ce)) {
- err = PTR_ERR(ce);
- goto out_siblings;
- }
-
- intel_context_set_gem(ce, set->ctx, null_sseu);
-
- if (cmpxchg(>engines->engines[idx], NULL, ce)) {
- intel_context_put(ce);
- err = -EEXIST;
- goto out_siblings;
- }
-
-out_siblings:
- if (siblings != stack)
- kfree(siblings);
-
- return err;
-}
-
-static int
-set_engines__bond(struct i915_user_extension __user *base, void *data)
-{
- struct i915_context_engines_bond __user *ext =
- container_of_user(base, typeof(*ext), base);
- const
[Intel-gfx] [PATCH 28/29] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index aee5642818824..01f7615eb3a8a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -813,16 +813,12 @@ static int igt_shared_ctx_exec(void *arg)
struct i915_gem_context *ctx;
struct intel_context *ce;
- ctx = kernel_context(i915, NULL);
+ ctx = kernel_context(i915, ctx_vm(parent));
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto out_test;
}
- mutex_lock(>mutex);
- __assign_ppgtt(ctx, ctx_vm(parent));
- mutex_unlock(>mutex);
-
ce = i915_gem_context_get_engine(ctx,
engine->legacy_idx);
GEM_BUG_ON(IS_ERR(ce));
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/29] drm/i915: Add an i915_gem_vm_lookup helper
This is the VM equivalent of i915_gem_context_lookup. It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 14 ++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d247fb223aac7..12a148ba421b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1346,11 +1346,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
if (upper_32_bits(args->value))
return -ENOENT;
- rcu_read_lock();
- vm = xa_load(_priv->vm_xa, args->value);
- if (vm && !kref_get_unless_zero(>ref))
- vm = NULL;
- rcu_read_unlock();
+ vm = i915_gem_vm_lookup(file_priv, args->value);
if (!vm)
return -ENOENT;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48316d273af66..fee2342219da1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1871,6 +1871,20 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+static inline struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+ struct i915_address_space *vm;
+
+ rcu_read_lock();
+ vm = xa_load(_priv->vm_xa, id);
+ if (vm && !kref_get_unless_zero(>ref))
+ vm = NULL;
+ rcu_read_unlock();
+
+ return vm;
+}
+
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
u64 min_size, u64 alignment,
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 29/29] drm/i915/gem: Roll all of context creation together
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 159 ++
.../gpu/drm/i915/gem/selftests/mock_context.c | 33 ++--
2 files changed, 64 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index e6a6ead477ff4..502a2bd1a043e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1298,56 +1298,6 @@ static int __context_set_persistence(struct
i915_gem_context *ctx, bool state)
return 0;
}
-static struct i915_gem_context *
-__create_context(struct drm_i915_private *i915,
-const struct i915_gem_proto_context *pc)
-{
- struct i915_gem_context *ctx;
- struct i915_gem_engines *e;
- int err;
- int i;
-
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (!ctx)
- return ERR_PTR(-ENOMEM);
-
- kref_init(>ref);
- ctx->i915 = i915;
- ctx->sched = pc->sched;
- mutex_init(>mutex);
- INIT_LIST_HEAD(>link);
-
- spin_lock_init(>stale.lock);
- INIT_LIST_HEAD(>stale.engines);
-
- mutex_init(>engines_mutex);
- e = default_engines(ctx, pc->legacy_rcs_sseu);
- if (IS_ERR(e)) {
- err = PTR_ERR(e);
- goto err_free;
- }
- RCU_INIT_POINTER(ctx->engines, e);
-
- INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
- mutex_init(>lut_mutex);
-
- /* NB: Mark all slices as needing a remap so that when the context first
-* loads it will restore whatever remap state already exists. If there
-* is no remap info, it will be a NOP. */
- ctx->remap_slice = ALL_L3_SLICES(i915);
-
- ctx->user_flags = pc->user_flags;
-
- for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
- ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
-
- return ctx;
-
-err_free:
- kfree(ctx);
- return ERR_PTR(err);
-}
-
static inline struct i915_gem_engines *
__context_engines_await(const struct i915_gem_context *ctx,
bool *user_engines)
@@ -1391,86 +1341,77 @@ context_apply_all(struct i915_gem_context *ctx,
i915_sw_fence_complete(>fence);
}
-static void __apply_ppgtt(struct intel_context *ce, void *vm)
-{
- i915_vm_put(ce->vm);
- ce->vm = i915_vm_get(vm);
-}
-
-static struct i915_address_space *
-__set_ppgtt(struct i915_gem_context *ctx, struct i915_address_space *vm)
-{
- struct i915_address_space *old;
-
- old = rcu_replace_pointer(ctx->vm,
- i915_vm_open(vm),
- lockdep_is_held(>mutex));
- GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
-
- context_apply_all(ctx, __apply_ppgtt, vm);
-
- return old;
-}
-
-static void __assign_ppgtt(struct i915_gem_context *ctx,
- struct i915_address_space *vm)
-{
- if (vm == rcu_access_pointer(ctx->vm))
- return;
-
- vm = __set_ppgtt(ctx, vm);
- if (vm)
- i915_vm_close(vm);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915,
const struct i915_gem_proto_context *pc)
{
struct i915_gem_context *ctx;
- int ret;
+ struct i915_gem_engines *e;
+ int err;
+ int i;
- ctx = __create_context(i915, pc);
- if (IS_ERR(ctx))
- return ctx;
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
- if (pc->vm) {
- mutex_lock(>mutex);
- __assign_ppgtt(ctx, pc->vm);
- mutex_unlock(>mutex);
- }
+ kref_init(>ref);
+ ctx->i915 = i915;
+ ctx->sched = pc->sched;
+ mutex_init(>mutex);
+ INIT_LIST_HEAD(>link);
- if (pc->num_user_engines >= 0) {
- struct i915_gem_engines *engines;
+ spin_lock_init(>stale.lock);
+ INIT_LIST_HEAD(>stale.engines);
- engines = user_engines(ctx, pc->num_user_engines,
- pc->user_engines);
- if (IS_ERR(engines)) {
- context_close(ctx);
- return ERR_CAST(engines);
- }
+ if (pc->vm)
+ RCU_INIT_POINTER(ctx->vm, i915_vm_open(pc->vm));
- mutex_lock(>engines_mutex);
+ mutex_init(>engines_mutex);
+ if (pc->num_user_engines >= 0) {
i915_gem_context_set_user_engines(ctx);
- engines =
[Intel-gfx] [PATCH 10/29] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2)
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was ready to start and then attempt to assign it to a different
engine than the primary. There is an IGT test (the bonded-slice subtest
of gem_exec_balancer) which exercises this by submitting a primary batch
to a specific VCS and then using FENCE_SUBMIT to submit a secondary
which can run on any VCS and have i915 figure out which VCS to run it on
such that they can run in parallel.
However, this functionality has never been used in the real world. The
media driver (the only user of FENCE_SUBMIT) always picks exactly two
physical engines to bond and never asks us to pick which to use.
v2 (Daniel Vetter):
- Mention the exact IGT test this breaks
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h| 7 ---
.../drm/i915/gt/intel_execlists_submission.c| 17 -
3 files changed, 1 insertion(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d640bba6ad9ab..efb2fa3522a42 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3474,7 +3474,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_FENCE_SUBMIT)
err = i915_request_await_execution(eb.request,
in_fence,
-
eb.engine->bond_execute);
+ NULL);
else
err = i915_request_await_dma_fence(eb.request,
in_fence);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 883bafc449024..68cfe5080325c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -446,13 +446,6 @@ struct intel_engine_cs {
*/
void(*submit_request)(struct i915_request *rq);
- /*
-* Called on signaling of a SUBMIT_FENCE, passing along the signaling
-* request down to the bonded pairs.
-*/
- void(*bond_execute)(struct i915_request *rq,
- struct dma_fence *signal);
-
/*
* Call when the priority on a request has changed and it and its
* dependencies may need rescheduling. Note the request itself may
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 14378b28169b7..635d6d2494d26 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3547,22 +3547,6 @@ static void virtual_submit_request(struct i915_request
*rq)
spin_unlock_irqrestore(>base.active.lock, flags);
}
-static void
-virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
-{
- intel_engine_mask_t allowed, exec;
-
- allowed = ~to_request(signal)->engine->mask;
-
- /* Restrict the bonded request to run on only the available engines */
- exec = READ_ONCE(rq->execution_mask);
- while (!try_cmpxchg(>execution_mask, , exec & allowed))
- ;
-
- /* Prevent the master from being re-run on the bonded engines */
- to_request(signal)->execution_mask &= ~allowed;
-}
-
struct intel_context *
intel_execlists_create_virtual(struct intel_engine_cs **siblings,
unsigned int count)
@@ -3616,7 +3600,6 @@ intel_execlists_create_virtual(struct intel_engine_cs
**siblings,
ve->base.schedule = i915_schedule;
ve->base.submit_request = virtual_submit_request;
- ve->base.bond_execute = virtual_bond_execute;
INIT_LIST_HEAD(virtual_queue(ve));
ve->base.execlists.queue_priority_hint = INT_MIN;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/29] drm/i915/gem: Disallow creating contexts with too many engines
There's no sense in allowing userspace to create more engines than it can possibly access via execbuf. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 5e159fb526631..2b9207b557cc9 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1639,11 +1639,11 @@ set_engines(struct i915_gem_context *ctx, return -EINVAL; } - /* -* Note that I915_EXEC_RING_MASK limits execbuf to only using the -* first 64 engines defined here. -*/ num_engines = (args->size - sizeof(*user)) / sizeof(*user->engines); + /* RING_MASK has no shift so we can use it directly here */ + if (num_engines > I915_EXEC_RING_MASK + 1) + return -EINVAL; + set.engines = alloc_engines(num_engines); if (!set.engines) return -ENOMEM; -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 25/29] drm/i915/gem: Don't allow changing the VM on running contexts (v2)
When the APIs were added to manage VMs more directly from userspace, the
questionable choice was made to allow changing out the VM on a context
at any time. This is horribly racy and there's absolutely no reason why
any userspace would want to do this outside of testing that exact race.
By removing support for CONTEXT_PARAM_VM from ctx_setparam, we make it
impossible to change out the VM after the context has been fully
created. This lets us delete a bunch of deferred task code as well as a
duplicated (and slightly different) copy of the code which programs the
PPGTT registers.
v2 (Jason Ekstrand):
- Expand the commit message
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 262 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed, 1 insertion(+), 383 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f7c83730ee07f..a528c8f3354a0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1633,120 +1633,6 @@ int i915_gem_vm_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
-struct context_barrier_task {
- struct i915_active base;
- void (*task)(void *data);
- void *data;
-};
-
-static void cb_retire(struct i915_active *base)
-{
- struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
-
- if (cb->task)
- cb->task(cb->data);
-
- i915_active_fini(>base);
- kfree(cb);
-}
-
-I915_SELFTEST_DECLARE(static intel_engine_mask_t context_barrier_inject_fault);
-static int context_barrier_task(struct i915_gem_context *ctx,
- intel_engine_mask_t engines,
- bool (*skip)(struct intel_context *ce, void
*data),
- int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
- int (*emit)(struct i915_request *rq, void
*data),
- void (*task)(void *data),
- void *data)
-{
- struct context_barrier_task *cb;
- struct i915_gem_engines_iter it;
- struct i915_gem_engines *e;
- struct i915_gem_ww_ctx ww;
- struct intel_context *ce;
- int err = 0;
-
- GEM_BUG_ON(!task);
-
- cb = kmalloc(sizeof(*cb), GFP_KERNEL);
- if (!cb)
- return -ENOMEM;
-
- i915_active_init(>base, NULL, cb_retire, 0);
- err = i915_active_acquire(>base);
- if (err) {
- kfree(cb);
- return err;
- }
-
- e = __context_engines_await(ctx, NULL);
- if (!e) {
- i915_active_release(>base);
- return -ENOENT;
- }
-
- for_each_gem_engine(ce, e, it) {
- struct i915_request *rq;
-
- if (I915_SELFTEST_ONLY(context_barrier_inject_fault &
- ce->engine->mask)) {
- err = -ENXIO;
- break;
- }
-
- if (!(ce->engine->mask & engines))
- continue;
-
- if (skip && skip(ce, data))
- continue;
-
- i915_gem_ww_ctx_init(, true);
-retry:
- err = intel_context_pin_ww(ce, );
- if (err)
- goto err;
-
- if (pin)
- err = pin(ce, , data);
- if (err)
- goto err_unpin;
-
- rq = i915_request_create(ce);
- if (IS_ERR(rq)) {
- err = PTR_ERR(rq);
- goto err_unpin;
- }
-
- err = 0;
- if (emit)
- err = emit(rq, data);
- if (err == 0)
- err = i915_active_add_request(>base, rq);
-
- i915_request_add(rq);
-err_unpin:
- intel_context_unpin(ce);
-err:
- if (err == -EDEADLK) {
- err = i915_gem_ww_ctx_backoff();
- if (!err)
- goto retry;
- }
- i915_gem_ww_ctx_fini();
-
- if (err)
- break;
- }
- i915_sw_fence_complete(>fence);
-
- cb->task = err ? NULL : task; /* caller needs to unwind instead */
- cb->data = data;
-
- i915_active_release(>base);
-
- return err;
-}
-
static int get_ppgtt(struct drm_i915_file_private *file_priv,
struct i915_gem_context *ctx,
struct drm_i915_gem_context_param *args)
@@ -1779,150 +1665,6 @@ static int get_ppgtt(struct drm_i915_file_private
*file_priv,
[Intel-gfx] [PATCH 24/29] drm/i915/gem: Delay context creation
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other. While some params are fairly simple and setting
them on a live context is harmless such the context priority, others are
far trickier such as the VM or the set of engines. In order to swap out
the VM, for instance, we have to delay until all current in-flight work
is complete, swap in the new VM, and then continue. This leads to a
plethora of potential race conditions we'd really rather avoid.
In previous patches, we added a i915_gem_proto_context struct which is
capable of storing and tracking all such create parameters. This commit
delays the creation of the actual context until after the client is done
configuring it with SET_CONTEXT_PARAM. From the perspective of the
client, it has the same u32 context ID the whole time. From the
perspective of i915, however, it's an i915_gem_proto_context right up
until the point where we attempt to do something which the proto-context
can't handle at which point the real context gets created.
This is accomplished via a little xarray dance. When GEM_CONTEXT_CREATE
is called, we create a proto-context, reserve a slot in context_xa but
leave it NULL, the proto-context in the corresponding slot in
proto_context_xa. Then, whenever we go to look up a context, we first
check context_xa. If it's there, we return the i915_gem_context and
we're done. If it's not, we look in proto_context_xa and, if we find it
there, we create the actual context and kill the proto-context.
In order for this dance to work properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-path anyway.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 211 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 54 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
drivers/gpu/drm/i915/i915_drv.h | 24 +-
5 files changed, 239 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8288af0d33245..f7c83730ee07f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -298,6 +298,42 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
return err;
}
+static int proto_context_register_locked(struct drm_i915_file_private *fpriv,
+struct i915_gem_proto_context *pc,
+u32 *id)
+{
+ int ret;
+ void *old;
+
+ lockdep_assert_held(>proto_context_lock);
+
+ ret = xa_alloc(>context_xa, id, NULL, xa_limit_32b, GFP_KERNEL);
+ if (ret)
+ return ret;
+
+ old = xa_store(>proto_context_xa, *id, pc, GFP_KERNEL);
+ if (xa_is_err(old)) {
+ xa_erase(>context_xa, *id);
+ return xa_err(old);
+ }
+ GEM_BUG_ON(old);
+
+ return 0;
+}
+
+static int proto_context_register(struct drm_i915_file_private *fpriv,
+ struct i915_gem_proto_context *pc,
+ u32 *id)
+{
+ int ret;
+
+ mutex_lock(>proto_context_lock);
+ ret = proto_context_register_locked(fpriv, pc, id);
+ mutex_unlock(>proto_context_lock);
+
+ return ret;
+}
+
static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
struct i915_gem_proto_context *pc,
const struct drm_i915_gem_context_param *args)
@@ -1448,12 +1484,12 @@ void i915_gem_init__contexts(struct drm_i915_private
*i915)
init_contexts(>gem.contexts);
}
-static int gem_context_register(struct i915_gem_context *ctx,
- struct drm_i915_file_private *fpriv,
- u32 *id)
+static void gem_context_register(struct i915_gem_context *ctx,
+struct drm_i915_file_private *fpriv,
+u32 id)
{
struct drm_i915_private *i915 = ctx->i915;
- int ret;
+ void *old;
ctx->file_priv = fpriv;
@@ -1462,19 +1498,12 @@ static int gem_context_register(struct i915_gem_context
*ctx,
current->comm, pid_nr(ctx->pid));
/* And finally expose ourselves to userspace via the idr */
- ret = xa_alloc(>context_xa, id, ctx, xa_limit_32b, GFP_KERNEL);
- if (ret)
- goto err_pid;
+ old =
[Intel-gfx] [PATCH 13/29] drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2)
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit more complicated, so let's get rid of the one hand-
rolled case.
Some usermode drivers such as our Vulkan driver call GET_RESET_STATS on
every execbuf so the perf here could theoretically be an issue. If this
ever does become a performance issue for any such userspace drivers,
they can use set CONTEXT_PARAM_RECOVERABLE to false and look for -EIO
coming from execbuf to check for hangs instead.
v2 (Daniel Vetter):
- Add a comment in the commit message about recoverable contexts
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/i915_drv.h | 8 +---
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 2b9207b557cc9..910d31cb043e9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2090,16 +2090,13 @@ int i915_gem_context_reset_stats_ioctl(struct
drm_device *dev,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
- int ret;
if (args->flags || args->pad)
return -EINVAL;
- ret = -ENOENT;
- rcu_read_lock();
- ctx = __i915_gem_context_lookup_rcu(file->driver_priv, args->ctx_id);
+ ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
if (!ctx)
- goto out;
+ return -ENOENT;
/*
* We opt for unserialised reads here. This may result in tearing
@@ -2116,10 +2113,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
args->batch_active = atomic_read(>guilty_count);
args->batch_pending = atomic_read(>active_count);
- ret = 0;
-out:
- rcu_read_unlock();
- return ret;
+ i915_gem_context_put(ctx);
+ return 0;
}
/* GEM context-engines iterator: for_each_gem_engine() */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 39b5e019c1a5b..48316d273af66 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1857,19 +1857,13 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int
flags);
-static inline struct i915_gem_context *
-__i915_gem_context_lookup_rcu(struct drm_i915_file_private *file_priv, u32 id)
-{
- return xa_load(_priv->context_xa, id);
-}
-
static inline struct i915_gem_context *
i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_gem_context *ctx;
rcu_read_lock();
- ctx = __i915_gem_context_lookup_rcu(file_priv, id);
+ ctx = xa_load(_priv->context_xa, id);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/29] drm/i915/gt: Drop i915_address_space::file (v2)
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In f6e8aa387171
("drm/i915: Report the number of closed vma held by each context in
debugfs") we removed one use of it by switching to a context walk and
comparing with the VM in the context. Finally, VM stats for debugfs
were entirely nuked in db80a1294c23 ("drm/i915/gem: Remove per-client
stats from debugfs/i915_gem_objects")
v2 (Daniel Vetter):
- Delete a struct drm_i915_file_private pre-declaration
- Add a comment to the commit message about history
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
drivers/gpu/drm/i915/gt/intel_gtt.h | 11 ---
drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 -
3 files changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 76662175e6980..8288af0d33245 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1453,17 +1453,10 @@ static int gem_context_register(struct i915_gem_context
*ctx,
u32 *id)
{
struct drm_i915_private *i915 = ctx->i915;
- struct i915_address_space *vm;
int ret;
ctx->file_priv = fpriv;
- mutex_lock(>mutex);
- vm = i915_gem_context_vm(ctx);
- if (vm)
- WRITE_ONCE(vm->file, fpriv); /* XXX */
- mutex_unlock(>mutex);
-
ctx->pid = get_task_pid(current, PIDTYPE_PID);
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
current->comm, pid_nr(ctx->pid));
@@ -1562,8 +1555,6 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
- ppgtt->vm.file = file_priv;
-
if (args->extensions) {
err = i915_user_extensions(u64_to_user_ptr(args->extensions),
NULL, 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ca00b45827b74..cbd89fded6f2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -140,7 +140,6 @@ typedef u64 gen8_pte_t;
enum i915_cache_level;
-struct drm_i915_file_private;
struct drm_i915_gem_object;
struct i915_fence_reg;
struct i915_vma;
@@ -220,16 +219,6 @@ struct i915_address_space {
struct intel_gt *gt;
struct drm_i915_private *i915;
struct device *dma;
- /*
-* Every address space belongs to a struct file - except for the global
-* GTT that is owned by the driver (and so @file is set to NULL). In
-* principle, no information should leak from one context to another
-* (or between files/processes etc) unless explicitly shared by the
-* owner. Tracking the owner is important in order to free up per-file
-* objects along with the file, to aide resource tracking, and to
-* assign blame.
-*/
- struct drm_i915_file_private *file;
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c
b/drivers/gpu/drm/i915/selftests/mock_gtt.c
index 5c7ae40bba634..cc047ec594f93 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c
@@ -73,7 +73,6 @@ struct i915_ppgtt *mock_ppgtt(struct drm_i915_private *i915,
const char *name)
ppgtt->vm.gt = >gt;
ppgtt->vm.i915 = i915;
ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE);
- ppgtt->vm.file = ERR_PTR(-ENODEV);
ppgtt->vm.dma = i915->drm.dev;
i915_address_space_init(>vm, VM_CLASS_PPGTT);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/29] drm/i915/gem: Use the proto-context to handle create parameters (v2)
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
There's an extra bit of fun here when it comes to setting SSEU and the
way it interacts with PARAM_ENGINES. Unfortunately, thanks to
SET_CONTEXT_PARAM and not being allowed to pick the order in which we
handle certain parameters, we have think about those interactions.
v2 (Daniel Vetter):
- Add a proto_context_free_user_engines helper
- Comment on SSEU in the commit message
- Use proto_context_set_persistence in set_proto_ctx_param
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 552 +-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 58 ++
2 files changed, 588 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cf7c281977a3e..d68c111bc824a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -191,10 +191,24 @@ static int validate_priority(struct drm_i915_private
*i915,
return 0;
}
+static void proto_context_free_user_engines(struct i915_gem_proto_context *pc)
+{
+ int i;
+
+ if (pc->user_engines) {
+ for (i = 0; i < pc->num_user_engines; i++)
+ kfree(pc->user_engines[i].siblings);
+ kfree(pc->user_engines);
+ }
+ pc->user_engines = NULL;
+ pc->num_user_engines = -1;
+}
+
static void proto_context_close(struct i915_gem_proto_context *pc)
{
if (pc->vm)
i915_vm_put(pc->vm);
+ proto_context_free_user_engines(pc);
kfree(pc);
}
@@ -211,7 +225,7 @@ static int proto_context_set_persistence(struct
drm_i915_private *i915,
if (!i915->params.enable_hangcheck)
return -EINVAL;
- __set_bit(UCONTEXT_PERSISTENCE, >user_flags);
+ pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
} else {
/* To cancel a context we use "preempt-to-idle" */
if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
@@ -233,7 +247,7 @@ static int proto_context_set_persistence(struct
drm_i915_private *i915,
if (!intel_has_reset_engine(>gt))
return -ENODEV;
- __clear_bit(UCONTEXT_PERSISTENCE, >user_flags);
+ pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
}
return 0;
@@ -248,6 +262,9 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
if (!pc)
return ERR_PTR(-ENOMEM);
+ pc->num_user_engines = -1;
+ pc->user_engines = NULL;
+
if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
@@ -261,9 +278,8 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
pc->vm = >vm;
}
- pc->user_flags = 0;
- __set_bit(UCONTEXT_BANNABLE, >user_flags);
- __set_bit(UCONTEXT_RECOVERABLE, >user_flags);
+ pc->user_flags = BIT(UCONTEXT_BANNABLE) |
+BIT(UCONTEXT_RECOVERABLE);
proto_context_set_persistence(i915, pc, true);
pc->sched.priority = I915_PRIORITY_NORMAL;
@@ -282,6 +298,429 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
return err;
}
+static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
+ struct i915_gem_proto_context *pc,
+ const struct drm_i915_gem_context_param *args)
+{
+ struct i915_address_space *vm;
+
+ if (args->size)
+ return -EINVAL;
+
+ if (!pc->vm)
+ return -ENODEV;
+
+ if (upper_32_bits(args->value))
+ return -ENOENT;
+
+ vm = i915_gem_vm_lookup(fpriv, args->value);
+ if (!vm)
+ return -ENOENT;
+
+ i915_vm_put(pc->vm);
+ pc->vm = vm;
+
+ return 0;
+}
+
+struct set_proto_ctx_engines {
+ struct drm_i915_private *i915;
+ unsigned num_engines;
+ struct i915_gem_proto_engine *engines;
+};
+
+static int
+set_proto_ctx_engines_balance(struct i915_user_extension __user *base,
+ void *data)
+{
+ struct i915_context_engines_load_balance __user *ext =
+ container_of_user(base, typeof(*ext), base);
+ const struct set_proto_ctx_engines *set = data;
+ struct drm_i915_private *i915 = set->i915;
+ struct intel_engine_cs **siblings;
+ u16 num_siblings, idx;
+ unsigned int n;
+ int err;
+
+ if (!HAS_EXECLISTS(i915))
+ return -ENODEV;
+
+ if (intel_uc_uses_guc_submission(>gt.uc))
+ return -ENODEV; /* not implement yet */
+
+ if (get_user(idx,
[Intel-gfx] [PATCH 20/29] drm/i915/gem: Make an alignment check more sensible
What we really want to check is that size of the engines array, i.e.
args->size - sizeof(*user) is divisible by the element size, i.e.
sizeof(*user->engines) because that's what's required for computing the
array length right below the check. However, we're currently not doing
this and instead doing a compile-time check that sizeof(*user) is
divisible by sizeof(*user->engines) and avoiding the subtraction. As
far as I can tell, the only reason for the more confusing pair of checks
is to avoid a single subtraction of a constant.
The other thing the BUILD_BUG_ON might be trying to implicitly check is
that offsetof(user->engines) == sizeof(*user) and we don't have any
weird padding throwing us off. However, that's not the check it's doing
and it's not even a reliable way to do that check.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 12a148ba421b6..cf7c281977a3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1758,9 +1758,8 @@ set_engines(struct i915_gem_context *ctx,
goto replace;
}
- BUILD_BUG_ON(!IS_ALIGNED(sizeof(*user), sizeof(*user->engines)));
if (args->size < sizeof(*user) ||
- !IS_ALIGNED(args->size, sizeof(*user->engines))) {
+ !IS_ALIGNED(args->size - sizeof(*user), sizeof(*user->engines))) {
drm_dbg(>drm, "Invalid size for engine array: %d\n",
args->size);
return -EINVAL;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/29] drm/i915/gem: Return an error ptr from context_lookup
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d68c111bc824a..76662175e6980 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2636,8 +2636,8 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
int ret = 0;
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
- if (!ctx)
- return -ENOENT;
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
switch (args->param) {
case I915_CONTEXT_PARAM_GTT_SIZE:
@@ -2705,8 +2705,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
int ret;
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
- if (!ctx)
- return -ENOENT;
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
ret = ctx_setparam(file_priv, ctx, args);
@@ -2725,8 +2725,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
return -EINVAL;
ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
- if (!ctx)
- return -ENOENT;
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
/*
* We opt for unserialised reads here. This may result in tearing
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 7024adcd5cf15..de14b26f3b2d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -739,8 +739,8 @@ static int eb_select_context(struct i915_execbuffer *eb)
struct i915_gem_context *ctx;
ctx = i915_gem_context_lookup(eb->file->driver_priv, eb->args->rsvd1);
- if (unlikely(!ctx))
- return -ENOENT;
+ if (unlikely(IS_ERR(ctx)))
+ return PTR_ERR(ctx);
eb->gem_context = ctx;
if (rcu_access_pointer(ctx->vm))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fee2342219da1..d7bd732ceacfc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1868,7 +1868,7 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
ctx = NULL;
rcu_read_unlock();
- return ctx;
+ return ctx ? ctx : ERR_PTR(-ENOENT);
}
static inline struct i915_address_space *
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index de8ebc34af0ff..dfc2a5c067c29 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3414,10 +3414,10 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
struct drm_i915_file_private *file_priv = file->driver_priv;
specific_ctx = i915_gem_context_lookup(file_priv, ctx_handle);
- if (!specific_ctx) {
+ if (IS_ERR(specific_ctx)) {
DRM_DEBUG("Failed to look up context with ID %u for
opening perf stream\n",
ctx_handle);
- ret = -ENOENT;
+ ret = PTR_ERR(specific_ctx);
goto err;
}
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/29] drm/i915/gem: Optionally set SSEU in intel_context_set_gem
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm/i915/gem/selftests/mock_context.c | 6 ++-
2 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f8f3f514b4265..d247fb223aac7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -320,9 +320,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
} while (1);
}
-static void intel_context_set_gem(struct intel_context *ce,
- struct i915_gem_context *ctx)
+static int intel_context_set_gem(struct intel_context *ce,
+struct i915_gem_context *ctx,
+struct intel_sseu sseu)
{
+ int ret = 0;
+
GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
RCU_INIT_POINTER(ce->gem_context, ctx);
@@ -349,6 +352,12 @@ static void intel_context_set_gem(struct intel_context *ce,
intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
}
+
+ /* A valid SSEU has no zero fields */
+ if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
+ ret = intel_context_reconfigure_sseu(ce, sseu);
+
+ return ret;
}
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -416,7 +425,8 @@ static struct i915_gem_engines *alloc_engines(unsigned int
count)
return e;
}
-static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
+static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
+ struct intel_sseu rcs_sseu)
{
const struct intel_gt *gt = >i915->gt;
struct intel_engine_cs *engine;
@@ -429,6 +439,8 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
for_each_engine(engine, gt, id) {
struct intel_context *ce;
+ struct intel_sseu sseu = {};
+ int ret;
if (engine->legacy_idx == INVALID_ENGINE)
continue;
@@ -442,10 +454,18 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
goto free_engines;
}
- intel_context_set_gem(ce, ctx);
-
e->engines[engine->legacy_idx] = ce;
e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
+
+ if (engine->class == RENDER_CLASS)
+ sseu = rcs_sseu;
+
+ ret = intel_context_set_gem(ce, ctx, sseu);
+ if (ret) {
+ err = ERR_PTR(ret);
+ goto free_engines;
+ }
+
}
return e;
@@ -759,6 +779,7 @@ __create_context(struct drm_i915_private *i915,
{
struct i915_gem_context *ctx;
struct i915_gem_engines *e;
+ struct intel_sseu null_sseu = {};
int err;
int i;
@@ -776,7 +797,7 @@ __create_context(struct drm_i915_private *i915,
INIT_LIST_HEAD(>stale.engines);
mutex_init(>engines_mutex);
- e = default_engines(ctx);
+ e = default_engines(ctx, null_sseu);
if (IS_ERR(e)) {
err = PTR_ERR(e);
goto err_free;
@@ -1543,6 +1564,7 @@ set_engines__load_balance(struct i915_user_extension
__user *base, void *data)
struct intel_engine_cs *stack[16];
struct intel_engine_cs **siblings;
struct intel_context *ce;
+ struct intel_sseu null_sseu = {};
u16 num_siblings, idx;
unsigned int n;
int err;
@@ -1615,7 +1637,7 @@ set_engines__load_balance(struct i915_user_extension
__user *base, void *data)
goto out_siblings;
}
- intel_context_set_gem(ce, set->ctx);
+ intel_context_set_gem(ce, set->ctx, null_sseu);
if (cmpxchg(>engines->engines[idx], NULL, ce)) {
intel_context_put(ce);
@@ -1723,6 +1745,7 @@ set_engines(struct i915_gem_context *ctx,
struct drm_i915_private *i915 = ctx->i915;
struct i915_context_param_engines __user *user =
u64_to_user_ptr(args->value);
+ struct intel_sseu null_sseu = {};
struct set_engines set = { .ctx = ctx };
unsigned int num_engines, n;
u64 extensions;
@@ -1732,7 +1755,7 @@ set_engines(struct i915_gem_context *ctx,
if (!i915_gem_context_user_engines(ctx))
return 0;
- set.engines = default_engines(ctx);
+ set.engines = default_engines(ctx, null_sseu);
if (IS_ERR(set.engines))
return
[Intel-gfx] [PATCH 16/29] drm/i915/gem: Add an intermediate proto_context struct
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the other. While some params are fairly simple and setting
them on a live context is harmless such the context priority, others are
far trickier such as the VM or the set of engines. In order to swap out
the VM, for instance, we have to delay until all current in-flight work
is complete, swap in the new VM, and then continue. This leads to a
plethora of potential race conditions we'd really rather avoid.
Unfortunately, both methods of setting the VM and engine set are in
active use today so we can't simply disallow setting the VM or engine
set vial SET_CONTEXT_PARAM. In order to work around this wart, this
commit adds a proto-context struct which contains all the context create
parameters.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
.../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
3 files changed, 153 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fc471243aa769..10bff488444b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -191,6 +191,97 @@ static int validate_priority(struct drm_i915_private *i915,
return 0;
}
+static void proto_context_close(struct i915_gem_proto_context *pc)
+{
+ if (pc->vm)
+ i915_vm_put(pc->vm);
+ kfree(pc);
+}
+
+static int proto_context_set_persistence(struct drm_i915_private *i915,
+struct i915_gem_proto_context *pc,
+bool persist)
+{
+ if (persist) {
+ /*
+* Only contexts that are short-lived [that will expire or be
+* reset] are allowed to survive past termination. We require
+* hangcheck to ensure that the persistent requests are healthy.
+*/
+ if (!i915->params.enable_hangcheck)
+ return -EINVAL;
+
+ __set_bit(UCONTEXT_PERSISTENCE, >user_flags);
+ } else {
+ /* To cancel a context we use "preempt-to-idle" */
+ if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
+ return -ENODEV;
+
+ /*
+* If the cancel fails, we then need to reset, cleanly!
+*
+* If the per-engine reset fails, all hope is lost! We resort
+* to a full GPU reset in that unlikely case, but realistically
+* if the engine could not reset, the full reset does not fare
+* much better. The damage has been done.
+*
+* However, if we cannot reset an engine by itself, we cannot
+* cleanup a hanging persistent context without causing
+* colateral damage, and we should not pretend we can by
+* exposing the interface.
+*/
+ if (!intel_has_reset_engine(>gt))
+ return -ENODEV;
+
+ __clear_bit(UCONTEXT_PERSISTENCE, >user_flags);
+ }
+
+ return 0;
+}
+
+static struct i915_gem_proto_context *
+proto_context_create(struct drm_i915_private *i915, unsigned int flags)
+{
+ struct i915_gem_proto_context *pc, *err;
+
+ pc = kzalloc(sizeof(*pc), GFP_KERNEL);
+ if (!pc)
+ return ERR_PTR(-ENOMEM);
+
+ if (HAS_FULL_PPGTT(i915)) {
+ struct i915_ppgtt *ppgtt;
+
+ ppgtt = i915_ppgtt_create(>gt);
+ if (IS_ERR(ppgtt)) {
+ drm_dbg(>drm, "PPGTT setup failed (%ld)\n",
+ PTR_ERR(ppgtt));
+ err = ERR_CAST(ppgtt);
+ goto proto_close;
+ }
+ pc->vm = >vm;
+ }
+
+ pc->user_flags = 0;
+ __set_bit(UCONTEXT_BANNABLE, >user_flags);
+ __set_bit(UCONTEXT_RECOVERABLE, >user_flags);
+ proto_context_set_persistence(i915, pc, true);
+ pc->sched.priority = I915_PRIORITY_NORMAL;
+
+ if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
+ if (!HAS_EXECLISTS(i915)) {
+ err = ERR_PTR(-EINVAL);
+ goto proto_close;
+ }
+ pc->single_timeline = true;
+ }
+
+ return pc;
+
+proto_close:
+ proto_context_close(pc);
+ return err;
+}
+
static struct i915_address_space *
context_get_vm_rcu(struct i915_gem_context *ctx)
{
@@ -660,7 +751,8 @@ static int
[Intel-gfx] [PATCH 15/29] drm/i915: Add gem/i915_gem_context.h to the docs
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f38907..0529e5183982e 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -422,6 +422,8 @@ Batchbuffer Parsing
User Batchbuffer Execution
--
+.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+
.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
:doc: User command execution
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index df76767f0c41b..5f0673a2129f9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -30,19 +30,39 @@ struct i915_address_space;
struct intel_timeline;
struct intel_ring;
+/**
+ * struct i915_gem_engines - A set of engines
+ */
struct i915_gem_engines {
union {
+ /** @link: Link in i915_gem_context::stale::engines */
struct list_head link;
+
+ /** @rcu: RCU to use when freeing */
struct rcu_head rcu;
};
+
+ /** @fence: Fence used for delayed destruction of engines */
struct i915_sw_fence fence;
+
+ /** @ctx: i915_gem_context backpointer */
struct i915_gem_context *ctx;
+
+ /** @num_engines: Number of engines in this set */
unsigned int num_engines;
+
+ /** @engines: Array of engines */
struct intel_context *engines[];
};
+/**
+ * struct i915_gem_engines_iter - Iterator for an i915_gem_engines set
+ */
struct i915_gem_engines_iter {
+ /** @idx: Index into i915_gem_engines::engines */
unsigned int idx;
+
+ /** @engines: Engine set being iterated */
const struct i915_gem_engines *engines;
};
@@ -53,10 +73,10 @@ struct i915_gem_engines_iter {
* logical hardware state for a particular client.
*/
struct i915_gem_context {
- /** i915: i915 device backpointer */
+ /** @i915: i915 device backpointer */
struct drm_i915_private *i915;
- /** file_priv: owning file descriptor */
+ /** @file_priv: owning file descriptor */
struct drm_i915_file_private *file_priv;
/**
@@ -81,7 +101,9 @@ struct i915_gem_context {
* CONTEXT_USER_ENGINES flag is set).
*/
struct i915_gem_engines __rcu *engines;
- struct mutex engines_mutex; /* guards writes to engines */
+
+ /** @engines_mutex: guards writes to engines */
+ struct mutex engines_mutex;
/**
* @syncobj: Shared timeline syncobj
@@ -118,7 +140,7 @@ struct i915_gem_context {
*/
struct pid *pid;
- /** link: place with _i915_private.context_list */
+ /** @link: place with _i915_private.context_list */
struct list_head link;
/**
@@ -153,11 +175,13 @@ struct i915_gem_context {
#define CONTEXT_CLOSED 0
#define CONTEXT_USER_ENGINES 1
+ /** @mutex: guards everything that isn't engines or handles_vma */
struct mutex mutex;
+ /** @sched: scheduler parameters */
struct i915_sched_attr sched;
- /** guilty_count: How many times this context has caused a GPU hang. */
+ /** @guilty_count: How many times this context has caused a GPU hang. */
atomic_t guilty_count;
/**
* @active_count: How many times this context was active during a GPU
@@ -171,15 +195,17 @@ struct i915_gem_context {
unsigned long hang_timestamp[2];
#define CONTEXT_FAST_HANG_JIFFIES (120 * HZ) /* 3 hangs within 120s? Banned! */
- /** remap_slice: Bitmask of cache lines that need remapping */
+ /** @remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
/**
-* handles_vma: rbtree to look up our context specific obj/vma for
+* @handles_vma: rbtree to look up our context specific obj/vma for
* the user handle. (user handles are per fd, but the binding is
* per vm, which may be one per context or shared with the global GTT)
*/
struct radix_tree_root handles_vma;
+
+ /** @lut_mutex: Locks handles_vma */
struct mutex lut_mutex;
/**
@@ -191,8 +217,11 @@ struct i915_gem_context {
*/
char name[TASK_COMM_LEN + 8];
+ /** @stale: tracks stale engines to be destroyed */
struct {
+ /** @lock: guards engines */
spinlock_t lock;
+ /** @engines: list of stale engines */
struct list_head engines;
} stale;
};
[Intel-gfx] [PATCH 11/29] drm/i915/request: Remove the hook from await_execution
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm/i915/i915_request.h | 4 +-
3 files changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index efb2fa3522a42..7024adcd5cf15 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3473,8 +3473,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (in_fence) {
if (args->flags & I915_EXEC_FENCE_SUBMIT)
err = i915_request_await_execution(eb.request,
- in_fence,
- NULL);
+ in_fence);
else
err = i915_request_await_dma_fence(eb.request,
in_fence);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 970d8f4986bbe..53f23ce40dd63 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -49,7 +49,6 @@
struct execute_cb {
struct irq_work work;
struct i915_sw_fence *fence;
- void (*hook)(struct i915_request *rq, struct dma_fence *signal);
struct i915_request *signal;
};
@@ -180,17 +179,6 @@ static void irq_execute_cb(struct irq_work *wrk)
kmem_cache_free(global.slab_execute_cbs, cb);
}
-static void irq_execute_cb_hook(struct irq_work *wrk)
-{
- struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
-
- cb->hook(container_of(cb->fence, struct i915_request, submit),
->signal->fence);
- i915_request_put(cb->signal);
-
- irq_execute_cb(wrk);
-}
-
static __always_inline void
__notify_execute_cb(struct i915_request *rq, bool (*fn)(struct irq_work *wrk))
{
@@ -517,17 +505,12 @@ static bool __request_in_flight(const struct i915_request
*signal)
static int
__await_execution(struct i915_request *rq,
struct i915_request *signal,
- void (*hook)(struct i915_request *rq,
- struct dma_fence *signal),
gfp_t gfp)
{
struct execute_cb *cb;
- if (i915_request_is_active(signal)) {
- if (hook)
- hook(rq, >fence);
+ if (i915_request_is_active(signal))
return 0;
- }
cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
if (!cb)
@@ -537,12 +520,6 @@ __await_execution(struct i915_request *rq,
i915_sw_fence_await(cb->fence);
init_irq_work(>work, irq_execute_cb);
- if (hook) {
- cb->hook = hook;
- cb->signal = i915_request_get(signal);
- cb->work.func = irq_execute_cb_hook;
- }
-
/*
* Register the callback first, then see if the signaler is already
* active. This ensures that if we race with the
@@ -1253,7 +1230,7 @@ emit_semaphore_wait(struct i915_request *to,
goto await_fence;
/* Only submit our spinner after the signaler is running! */
- if (__await_execution(to, from, NULL, gfp))
+ if (__await_execution(to, from, gfp))
goto await_fence;
if (__emit_semaphore_wait(to, from, from->fence.seqno))
@@ -1284,16 +1261,14 @@ static int intel_timeline_sync_set_start(struct
intel_timeline *tl,
static int
__i915_request_await_execution(struct i915_request *to,
- struct i915_request *from,
- void (*hook)(struct i915_request *rq,
- struct dma_fence *signal))
+ struct i915_request *from)
{
int err;
GEM_BUG_ON(intel_context_is_barrier(from->context));
/* Submit both requests at the same time */
- err = __await_execution(to, from, hook, I915_FENCE_GFP);
+ err = __await_execution(to, from, I915_FENCE_GFP);
if (err)
return err;
@@ -1406,9 +1381,7 @@ i915_request_await_external(struct i915_request *rq,
struct dma_fence *fence)
int
i915_request_await_execution(struct i915_request *rq,
-struct dma_fence *fence,
-void (*hook)(struct i915_request *rq,
- struct dma_fence *signal))
+struct dma_fence *fence)
{
struct dma_fence **child =
unsigned int nchild = 1;
@@ -1441,8 +1414,7 @@ i915_request_await_execution(struct
[Intel-gfx] [PATCH 09/29] drm/i915/gem: Disallow bonding of virtual engines (v3)
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was originally added to handle cases where we may
have more than two video engines and media might want to load-balance
their bonded submits by, for instance, submitting to a balanced vcs0-1
as the primary and then vcs2-3 as the secondary. However, no such
hardware has shipped thus far and, if we ever want to enable such
use-cases in the future, we'll use the up-and-coming parallel submit API
which targets GuC submission.
This makes I915_CONTEXT_ENGINES_EXT_BOND a total no-op. We leave the
validation code in place in case we ever decide we want to do something
interesting with the bonding information.
v2 (Jason Ekstrand):
- Don't delete quite as much code.
v3 (Tvrtko Ursulin):
- Add some history to the commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 +-
.../drm/i915/gt/intel_execlists_submission.c | 69 --
.../drm/i915/gt/intel_execlists_submission.h | 4 -
drivers/gpu/drm/i915/gt/selftest_execlists.c | 229 --
4 files changed, 6 insertions(+), 314 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fed3538de9241..5e159fb526631 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1552,6 +1552,12 @@ set_engines__bond(struct i915_user_extension __user
*base, void *data)
}
virtual = set->engines->engines[idx]->engine;
+ if (intel_engine_is_virtual(virtual)) {
+ drm_dbg(>drm,
+ "Bonding with virtual engines not allowed\n");
+ return -EINVAL;
+ }
+
err = check_user_mbz(>flags);
if (err)
return err;
@@ -1592,18 +1598,6 @@ set_engines__bond(struct i915_user_extension __user
*base, void *data)
n, ci.engine_class, ci.engine_instance);
return -EINVAL;
}
-
- /*
-* A non-virtual engine has no siblings to choose between; and
-* a submit fence will always be directed to the one engine.
-*/
- if (intel_engine_is_virtual(virtual)) {
- err = intel_virtual_engine_attach_bond(virtual,
- master,
- bond);
- if (err)
- return err;
- }
}
return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 0e8c320927d15..14378b28169b7 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -181,18 +181,6 @@ struct virtual_engine {
int prio;
} nodes[I915_NUM_ENGINES];
- /*
-* Keep track of bonded pairs -- restrictions upon on our selection
-* of physical engines any particular request may be submitted to.
-* If we receive a submit-fence from a master engine, we will only
-* use one of sibling_mask physical engines.
-*/
- struct ve_bond {
- const struct intel_engine_cs *master;
- intel_engine_mask_t sibling_mask;
- } *bonds;
- unsigned int num_bonds;
-
/* And finally, which physical engines this virtual engine maps onto. */
unsigned int num_siblings;
struct intel_engine_cs *siblings[];
@@ -3307,7 +3295,6 @@ static void rcu_virtual_context_destroy(struct
work_struct *wrk)
intel_breadcrumbs_free(ve->base.breadcrumbs);
intel_engine_free_request_pool(>base);
- kfree(ve->bonds);
kfree(ve);
}
@@ -3560,33 +3547,13 @@ static void virtual_submit_request(struct i915_request
*rq)
spin_unlock_irqrestore(>base.active.lock, flags);
}
-static struct ve_bond *
-virtual_find_bond(struct virtual_engine *ve,
- const struct intel_engine_cs *master)
-{
- int i;
-
- for (i = 0; i < ve->num_bonds; i++) {
- if (ve->bonds[i].master == master)
- return >bonds[i];
- }
-
- return NULL;
-}
-
static void
virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
{
- struct virtual_engine *ve = to_virtual_engine(rq->engine);
intel_engine_mask_t allowed, exec;
- struct ve_bond *bond;
allowed = ~to_request(signal)->engine->mask;
- bond = virtual_find_bond(ve, to_request(signal)->engine);
- if
[Intel-gfx] [PATCH 08/29] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero data so it's not useful for discovering what engines
are in the context. It's also not a replacement for the recently
removed I915_CONTEXT_CLONE_ENGINES because it doesn't return any of the
balancing or bonding information.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 77 +
1 file changed, 1 insertion(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index aa792c9517e16..fed3538de9241 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1724,78 +1724,6 @@ set_engines(struct i915_gem_context *ctx,
return 0;
}
-static int
-get_engines(struct i915_gem_context *ctx,
- struct drm_i915_gem_context_param *args)
-{
- struct i915_context_param_engines __user *user;
- struct i915_gem_engines *e;
- size_t n, count, size;
- bool user_engines;
- int err = 0;
-
- e = __context_engines_await(ctx, _engines);
- if (!e)
- return -ENOENT;
-
- if (!user_engines) {
- i915_sw_fence_complete(>fence);
- args->size = 0;
- return 0;
- }
-
- count = e->num_engines;
-
- /* Be paranoid in case we have an impedance mismatch */
- if (!check_struct_size(user, engines, count, )) {
- err = -EINVAL;
- goto err_free;
- }
- if (overflows_type(size, args->size)) {
- err = -EINVAL;
- goto err_free;
- }
-
- if (!args->size) {
- args->size = size;
- goto err_free;
- }
-
- if (args->size < size) {
- err = -EINVAL;
- goto err_free;
- }
-
- user = u64_to_user_ptr(args->value);
- if (put_user(0, >extensions)) {
- err = -EFAULT;
- goto err_free;
- }
-
- for (n = 0; n < count; n++) {
- struct i915_engine_class_instance ci = {
- .engine_class = I915_ENGINE_CLASS_INVALID,
- .engine_instance = I915_ENGINE_CLASS_INVALID_NONE,
- };
-
- if (e->engines[n]) {
- ci.engine_class = e->engines[n]->engine->uabi_class;
- ci.engine_instance =
e->engines[n]->engine->uabi_instance;
- }
-
- if (copy_to_user(>engines[n], , sizeof(ci))) {
- err = -EFAULT;
- goto err_free;
- }
- }
-
- args->size = size;
-
-err_free:
- i915_sw_fence_complete(>fence);
- return err;
-}
-
static int
set_persistence(struct i915_gem_context *ctx,
const struct drm_i915_gem_context_param *args)
@@ -2126,10 +2054,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
ret = get_ppgtt(file_priv, ctx, args);
break;
- case I915_CONTEXT_PARAM_ENGINES:
- ret = get_engines(ctx, args);
- break;
-
case I915_CONTEXT_PARAM_PERSISTENCE:
args->size = 0;
args->value = i915_gem_context_is_persistent(ctx);
@@ -2137,6 +2061,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
+ case I915_CONTEXT_PARAM_ENGINES:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
ret = -EINVAL;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/29] drm/i915/gem: Return void from context_apply_all
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9a8a96e4346e4..6f1e5c2c5b113 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -718,32 +718,25 @@ __context_engines_await(const struct i915_gem_context
*ctx,
return engines;
}
-static int
+static void
context_apply_all(struct i915_gem_context *ctx,
- int (*fn)(struct intel_context *ce, void *data),
+ void (*fn)(struct intel_context *ce, void *data),
void *data)
{
struct i915_gem_engines_iter it;
struct i915_gem_engines *e;
struct intel_context *ce;
- int err = 0;
e = __context_engines_await(ctx, NULL);
- for_each_gem_engine(ce, e, it) {
- err = fn(ce, data);
- if (err)
- break;
- }
+ for_each_gem_engine(ce, e, it)
+ fn(ce, data);
i915_sw_fence_complete(>fence);
-
- return err;
}
-static int __apply_ppgtt(struct intel_context *ce, void *vm)
+static void __apply_ppgtt(struct intel_context *ce, void *vm)
{
i915_vm_put(ce->vm);
ce->vm = i915_vm_get(vm);
- return 0;
}
static struct i915_address_space *
@@ -783,10 +776,9 @@ static void __set_timeline(struct intel_timeline **dst,
intel_timeline_put(old);
}
-static int __apply_timeline(struct intel_context *ce, void *timeline)
+static void __apply_timeline(struct intel_context *ce, void *timeline)
{
__set_timeline(>timeline, timeline);
- return 0;
}
static void __assign_timeline(struct i915_gem_context *ctx,
@@ -1841,19 +1833,17 @@ set_persistence(struct i915_gem_context *ctx,
return __context_set_persistence(ctx, args->value);
}
-static int __apply_priority(struct intel_context *ce, void *arg)
+static void __apply_priority(struct intel_context *ce, void *arg)
{
struct i915_gem_context *ctx = arg;
if (!intel_engine_has_timeslices(ce->engine))
- return 0;
+ return;
if (ctx->sched.priority >= I915_PRIORITY_NORMAL)
intel_context_set_use_semaphores(ce);
else
intel_context_clear_use_semaphores(ce);
-
- return 0;
}
static int set_priority(struct i915_gem_context *ctx,
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/29] drm/i915: Drop the CONTEXT_CLONE API (v2)
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any real value (most of the stuff you can CLONE you can copy
in other ways), drop it.
There is one thing that this API allows you to clone which you cannot
clone via getparam/setparam: timelines. However, timelines are an
implementation detail of i915 and not really something that needs to be
exposed to userspace. Also, sharing timelines between contexts isn't
obviously useful and supporting it has the potential to complicate i915
internally. It also doesn't add any functionality that the client can't
get in other ways. If a client really wants a shared timeline, they can
use a syncobj and set it as an in and out fence on every submit.
v2 (Jason Ekstrand):
- More detailed commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
.../drm/i915/gt/intel_execlists_submission.c | 28 ---
.../drm/i915/gt/intel_execlists_submission.h | 3 -
include/uapi/drm/i915_drm.h | 16 +-
4 files changed, 6 insertions(+), 240 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6f1e5c2c5b113..97613e529aab3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1957,207 +1957,14 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return ctx_setparam(arg->fpriv, arg->ctx, );
}
-static int clone_engines(struct i915_gem_context *dst,
-struct i915_gem_context *src)
+static int invalid_ext(struct i915_user_extension __user *ext, void *data)
{
- struct i915_gem_engines *clone, *e;
- bool user_engines;
- unsigned long n;
-
- e = __context_engines_await(src, _engines);
- if (!e)
- return -ENOENT;
-
- clone = alloc_engines(e->num_engines);
- if (!clone)
- goto err_unlock;
-
- for (n = 0; n < e->num_engines; n++) {
- struct intel_engine_cs *engine;
-
- if (!e->engines[n]) {
- clone->engines[n] = NULL;
- continue;
- }
- engine = e->engines[n]->engine;
-
- /*
-* Virtual engines are singletons; they can only exist
-* inside a single context, because they embed their
-* HW context... As each virtual context implies a single
-* timeline (each engine can only dequeue a single request
-* at any time), it would be surprising for two contexts
-* to use the same engine. So let's create a copy of
-* the virtual engine instead.
-*/
- if (intel_engine_is_virtual(engine))
- clone->engines[n] =
- intel_execlists_clone_virtual(engine);
- else
- clone->engines[n] = intel_context_create(engine);
- if (IS_ERR_OR_NULL(clone->engines[n])) {
- __free_engines(clone, n);
- goto err_unlock;
- }
-
- intel_context_set_gem(clone->engines[n], dst);
- }
- clone->num_engines = n;
- i915_sw_fence_complete(>fence);
-
- /* Serialised by constructor */
- engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
- if (user_engines)
- i915_gem_context_set_user_engines(dst);
- else
- i915_gem_context_clear_user_engines(dst);
- return 0;
-
-err_unlock:
- i915_sw_fence_complete(>fence);
- return -ENOMEM;
-}
-
-static int clone_flags(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- dst->user_flags = src->user_flags;
- return 0;
-}
-
-static int clone_schedattr(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- dst->sched = src->sched;
- return 0;
-}
-
-static int clone_sseu(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
- struct i915_gem_engines *clone;
- unsigned long n;
- int err;
-
- /* no locking required; sole access under constructor*/
- clone = __context_engines_static(dst);
- if (e->num_engines != clone->num_engines) {
- err = -EINVAL;
- goto unlock;
- }
-
- for (n = 0; n < e->num_engines; n++) {
- struct intel_context *ce = e->engines[n];
-
- if
[Intel-gfx] [PATCH 07/29] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature. i965
was already in maintenance mode at the time and iris uses syncobj for
everything.
Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that. We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally. This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads. It won't crash in that case; it just doesn't guarantee any
ordering between those two submits. It also means that sync files
exported from different engines on a SINGLE_TIMELINE context will have
different fence contexts. This is visible to userspace if it looks at
the obj_name field of sync_fence_info.
Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance. One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make scheduler changes going
forward. Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline which may help us reduce locking.
v2 (Tvrtko Ursulin):
- Update the comment on i915_gem_context::syncobj to mention that it's
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
v2 (Jason Ekstrand):
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
v3 (Jason Ekstrand):
- Move the dma_fence_put() to before the error exit
v4 (Tvrtko Ursulin):
- Add a comment about fence contexts to the commit message
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 49 +--
.../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 ++
3 files changed, 40 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 97613e529aab3..aa792c9517e16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
#include
#include
+#include
+
#include "gt/gen6_ppgtt.h"
#include "gt/intel_context.h"
#include "gt/intel_context_param.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
- GEM_BUG_ON(ce->timeline);
- if (ctx->timeline)
- ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
@@ -351,9 +349,6 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
- if (ctx->timeline)
- intel_timeline_put(ctx->timeline);
-
put_pid(ctx->pid);
mutex_destroy(>mutex);
@@ -570,6 +565,9 @@ static void context_close(struct i915_gem_context *ctx)
if (vm)
i915_vm_close(vm);
+ if (ctx->syncobj)
+ drm_syncobj_put(ctx->syncobj);
+
ctx->file_priv = ERR_PTR(-EBADF);
/*
@@ -765,33 +763,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
}
-static void __set_timeline(struct intel_timeline **dst,
- struct intel_timeline *src)
-{
- struct intel_timeline *old = *dst;
-
- *dst = src ? intel_timeline_get(src) : NULL;
-
- if (old)
- intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
- __set_timeline(>timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
- __set_timeline(>timeline, timeline);
- context_apply_all(ctx, __apply_timeline, timeline);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
struct i915_gem_context *ctx;
+ int ret;
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
!HAS_EXECLISTS(i915))
@@ -820,16 +796,13 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
[Intel-gfx] [PATCH 03/29] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and Beignet patches never landed in their respective upstream
projects so this API has never been used. It's never been used in Mesa
or any other driver, either.
Dropping this API allows us to delete a small bit of code.
[1]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067030.html
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8
include/uapi/drm/i915_drm.h | 4
4 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ec999b7ca50f4..868c18c08a0b1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1920,15 +1920,6 @@ static int ctx_setparam(struct drm_i915_file_private
*fpriv,
int ret = 0;
switch (args->param) {
- case I915_CONTEXT_PARAM_NO_ZEROMAP:
- if (args->size)
- ret = -EINVAL;
- else if (args->value)
- set_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
- else
- clear_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
- break;
-
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
if (args->size)
ret = -EINVAL;
@@ -1978,6 +1969,7 @@ static int ctx_setparam(struct drm_i915_file_private
*fpriv,
ret = set_persistence(ctx, args);
break;
+ case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
@@ -2358,11 +2350,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
return -ENOENT;
switch (args->param) {
- case I915_CONTEXT_PARAM_NO_ZEROMAP:
- args->size = 0;
- args->value = test_bit(UCONTEXT_NO_ZEROMAP, >user_flags);
- break;
-
case I915_CONTEXT_PARAM_GTT_SIZE:
args->size = 0;
rcu_read_lock();
@@ -2410,6 +2397,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
args->value = i915_gem_context_is_persistent(ctx);
break;
+ case I915_CONTEXT_PARAM_NO_ZEROMAP:
case I915_CONTEXT_PARAM_BAN_PERIOD:
case I915_CONTEXT_PARAM_RINGSIZE:
default:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 340473aa70de0..5ae71ec936f7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -129,7 +129,6 @@ struct i915_gem_context {
* @user_flags: small set of booleans controlled by the user
*/
unsigned long user_flags;
-#define UCONTEXT_NO_ZEROMAP0
#define UCONTEXT_NO_ERROR_CAPTURE 1
#define UCONTEXT_BANNABLE 2
#define UCONTEXT_RECOVERABLE 3
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 297143511f99b..b812f313422a9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -290,7 +290,6 @@ struct i915_execbuffer {
struct intel_context *reloc_context;
u64 invalid_flags; /** Set of execobj.flags that are invalid */
- u32 context_flags; /** Set of execobj.flags to insert from the ctx */
u64 batch_len; /** Length of batch within object */
u32 batch_start_offset; /** Location within object of batch */
@@ -541,9 +540,6 @@ eb_validate_vma(struct i915_execbuffer *eb,
entry->flags |= EXEC_OBJECT_NEEDS_GTT |
__EXEC_OBJECT_NEEDS_MAP;
}
- if (!(entry->flags & EXEC_OBJECT_PINNED))
- entry->flags |= eb->context_flags;
-
return 0;
}
@@ -750,10 +746,6 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (rcu_access_pointer(ctx->vm))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
- eb->context_flags = 0;
- if (test_bit(UCONTEXT_NO_ZEROMAP, >user_flags))
- eb->context_flags |= __EXEC_OBJECT_NEEDS_BIAS;
-
return 0;
}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ad8f1a0f587f6..e527f5f7e0dea 100644
--- a/include/uapi/drm/i915_drm.h
+++
[Intel-gfx] [PATCH 04/29] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2)
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
bitstream (especially for decoding) you don't hang your desktop too
hard. But it's been stuck in limbo since forever, and this simplifies
things a bit in preparation for the proto-context work. If we decide to
actually make said uAPI a reality, we can do it through the proto-
context easily enough.
This does mean that we move from reading the request_timeout_ms param
once per engine when engines are created instead of once at context
creation. If someone changes request_timeout_ms between creating a
context and setting engines, it will mean that they get the new timeout.
If someone races setting request_timeout_ms and context creation, they
can theoretically end up with different timeouts. However, since both
of these are fairly harmless and require changing kernel params, we
don't care.
v2 (Tvrtko Ursulin):
- Add a comment about races with request_timeout_ms
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 44 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 4 --
drivers/gpu/drm/i915/gt/intel_context_param.h | 3 +-
3 files changed, 7 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 868c18c08a0b1..9a8a96e4346e4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -232,7 +232,12 @@ static void intel_context_set_gem(struct intel_context *ce,
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
- intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
+ if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
+ ctx->i915->params.request_timeout_ms) {
+ unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
+
+ intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
+ }
}
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -791,41 +796,6 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
}
-static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
-{
- return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
-}
-
-static int
-__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
-{
- int ret;
-
- ret = context_apply_all(ctx, __apply_watchdog,
- (void *)(uintptr_t)timeout_us);
- if (!ret)
- ctx->watchdog.timeout_us = timeout_us;
-
- return ret;
-}
-
-static void __set_default_fence_expiry(struct i915_gem_context *ctx)
-{
- struct drm_i915_private *i915 = ctx->i915;
- int ret;
-
- if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) ||
- !i915->params.request_timeout_ms)
- return;
-
- /* Default expiry for user fences. */
- ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000);
- if (ret)
- drm_notice(>drm,
- "Failed to configure default fence expiry! (%d)",
- ret);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
@@ -870,8 +840,6 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
intel_timeline_put(timeline);
}
- __set_default_fence_expiry(ctx);
-
trace_i915_context_create(ctx);
return ctx;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 5ae71ec936f7c..676592e27e7d2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -153,10 +153,6 @@ struct i915_gem_context {
*/
atomic_t active_count;
- struct {
- u64 timeout_us;
- } watchdog;
-
/**
* @hang_timestamp: The last time(s) this context caused a GPU hang
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_context_param.h
b/drivers/gpu/drm/i915/gt/intel_context_param.h
index dffedd983693d..0c69cb42d075c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_param.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_param.h
@@ -10,11 +10,10 @@
#include "intel_context.h"
-static inline int
+static inline void
intel_context_set_watchdog_us(struct intel_context *ce, u64 timeout_us)
{
ce->watchdog.timeout_us = timeout_us;
- return 0;
}
#endif /* INTEL_CONTEXT_PARAM_H */
--
2.31.1
[Intel-gfx] [PATCH 02/29] drm/i915: Stop storing the ring size in the ring pointer (v2)
Previously, we were storing the ring size in the ring pointer before it
was actually allocated. We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this patch adds a new ring_size field and makes everything use
that.
v2 (Daniel Vetter):
- Replace 512 * SZ_4K with SZ_2M
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 5 -
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++-
9 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 650364a0dae28..ec999b7ca50f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -211,8 +211,7 @@ static void intel_context_set_gem(struct intel_context *ce,
GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
RCU_INIT_POINTER(ce->gem_context, ctx);
- if (!test_bit(CONTEXT_ALLOC_BIT, >flags))
- ce->ring = __intel_context_ring_size(SZ_16K);
+ ce->ring_size = SZ_16K;
if (rcu_access_pointer(ctx->vm)) {
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 4033184f13b9f..bd63813c8a802 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -371,7 +371,8 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
- ce->ring = __intel_context_ring_size(SZ_4K);
+ ce->ring = NULL;
+ ce->ring_size = SZ_4K;
ewma_runtime_init(>runtime.avg);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index f83a73a2b39fc..b10cbe8fee992 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -175,11 +175,6 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce);
-static inline struct intel_ring *__intel_context_ring_size(u64 sz)
-{
- return u64_to_ptr(struct intel_ring, sz);
-}
-
static inline bool intel_context_is_barrier(const struct intel_context *ce)
{
return test_bit(CONTEXT_BARRIER_BIT, >flags);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index ed8c447a7346b..90026c1771055 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -82,6 +82,7 @@ struct intel_context {
spinlock_t signal_lock; /* protects signals, the list of requests */
struct i915_vma *state;
+ u32 ring_size;
struct intel_ring *ring;
struct intel_timeline *timeline;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index aafe2a4df4960..890b43b296a90 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -845,7 +845,7 @@ int lrc_alloc(struct intel_context *ce, struct
intel_engine_cs *engine)
if (IS_ERR(vma))
return PTR_ERR(vma);
- ring = intel_engine_create_ring(engine, (unsigned long)ce->ring);
+ ring = intel_engine_create_ring(engine, ce->ring_size);
if (IS_ERR(ring)) {
err = PTR_ERR(ring);
goto err_vma;
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 1081cd36a2bd3..01d9896dd4844 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -2793,7 +2793,7 @@ static int __live_preempt_ring(struct intel_engine_cs
*engine,
goto err_ce;
}
- tmp->ring = __intel_context_ring_size(ring_sz);
+ tmp->ring_size = ring_sz;
err = intel_context_pin(tmp);
if (err) {
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index e55a887d11e2b..f343fa5fd986f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -28,7 +28,7 @@ static struct intel_context *mocs_context_create(struct
intel_engine_cs *engine)
return ce;
/* We build
[Intel-gfx] [PATCH 01/29] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1. If the compute-runtime PR has sat open for a year, this clearly
isn't that important.
2. It's a very leaky API. Ring size is an implementation detail of the
current execlist scheduler and really only makes sense there. It
can't apply to the older ring-buffer scheduler on pre-execlist
hardware because that's shared across all contexts and it won't
apply to the GuC scheduler that's in the pipeline.
3. Having userspace set a ring size in bytes is a bad solution to the
problem of having too small a ring. There is no way that userspace
has the information to know how to properly set the ring size so
it's just going to detect the feature and always set it to the
maximum of 512K. This is what the compute-runtime PR does. The
scheduler in i915, on the other hand, does have the information to
make an informed choice. It could detect if the ring size is a
problem and grow it itself. Or, if that's too hard, we could just
increase the default size from 16K to 32K or even 64K instead of
relying on userspace to do it.
Let's drop this API for now and, if someone decides they really care
about solving this problem, they can do it properly.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 +--
drivers/gpu/drm/i915/gt/intel_context_param.c | 63 --
drivers/gpu/drm/i915/gt/intel_context_param.h | 3 -
include/uapi/drm/i915_drm.h | 20 +
5 files changed, 4 insertions(+), 168 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137bc..afa22338fa343 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,7 +88,6 @@ gt-y += \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
- gt/intel_context_param.o \
gt/intel_context_sseu.o \
gt/intel_engine_cs.o \
gt/intel_engine_heartbeat.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 188dee13e017d..650364a0dae28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1334,63 +1334,6 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
return err;
}
-static int __apply_ringsize(struct intel_context *ce, void *sz)
-{
- return intel_context_set_ring_size(ce, (unsigned long)sz);
-}
-
-static int set_ringsize(struct i915_gem_context *ctx,
- struct drm_i915_gem_context_param *args)
-{
- if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
- return -ENODEV;
-
- if (args->size)
- return -EINVAL;
-
- if (!IS_ALIGNED(args->value, I915_GTT_PAGE_SIZE))
- return -EINVAL;
-
- if (args->value < I915_GTT_PAGE_SIZE)
- return -EINVAL;
-
- if (args->value > 128 * I915_GTT_PAGE_SIZE)
- return -EINVAL;
-
- return context_apply_all(ctx,
-__apply_ringsize,
-__intel_context_ring_size(args->value));
-}
-
-static int __get_ringsize(struct intel_context *ce, void *arg)
-{
- long sz;
-
- sz = intel_context_get_ring_size(ce);
- GEM_BUG_ON(sz > INT_MAX);
-
- return sz; /* stop on first engine */
-}
-
-static int get_ringsize(struct i915_gem_context *ctx,
- struct drm_i915_gem_context_param *args)
-{
- int sz;
-
- if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
- return -ENODEV;
-
- if (args->size)
- return -EINVAL;
-
- sz = context_apply_all(ctx, __get_ringsize, NULL);
- if (sz < 0)
- return sz;
-
- args->value = sz;
- return 0;
-}
-
int
i915_gem_user_to_context_sseu(struct intel_gt *gt,
const struct drm_i915_gem_context_param_sseu
*user,
@@ -2036,11 +1979,8 @@ static int ctx_setparam(struct drm_i915_file_private
*fpriv,
ret = set_persistence(ctx, args);
break;
- case I915_CONTEXT_PARAM_RINGSIZE:
- ret = set_ringsize(ctx, args);
- break;
-
case I915_CONTEXT_PARAM_BAN_PERIOD:
+ case I915_CONTEXT_PARAM_RINGSIZE:
default:
ret = -EINVAL;
break;
@@ -2068,18 +2008,6 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return
[Intel-gfx] [PATCH 00/29] drm/i915/gem: ioctl clean-ups (v6)
Overview: - This patch series attempts to clean up some of the IOCTL mess we've created over the last few years. The most egregious bit being context mutability. In summary, this series: 1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP 2. Drops the entire CONTEXT_CLONE API 3. Implements SINGLE_TIMELINE with a syncobj instead of actually sharing intel_timeline between engines. 4. Adds a few sanity restrictions to the balancing/bonding API. 5. Implements a proto-ctx mechanism so that the engine set and VM can only be set early on in the lifetime of a context, before anything ever executes on it. This effectively makes the VM and engine set immutable. This series has been tested with IGT as well as the Iris, ANV, and the Intel media driver doing an 8K decode (this uses bonding/balancing). I've also done quite a bit of git archeology to ensure that nothing in here will break anything that's already shipped at some point in history. It's possible I've missed something, but I've dug quite a bit. Details and motivation: --- In very broad strokes, there's an effort going on right now within Intel to try and clean up and simplify i915 anywhere we can. We obviously don't want to break any shipping userspace but, as can be seen by this series, there's a lot i915 theoretically supports which userspace doesn't actually need. Some of this, like the two context params used here, were simply oversights where we went through the usual API review process and merged the i915 bits but the userspace bits never landed for some reason. Not all are so innocent, however. For instance, there's an entire context cloning API which allows one to create a context with certain parameters "cloned" from some other context. This entire API has never been used by any userspace except IGT and there were never patches to any other userspace to use it. It never should have landed. Also, when we added support for setting explicit engine sets and sharing VMs across contexts, people decided to do so via SET_CONTEXT_PARAM. While this allowed them to re-use existing API, it did so at the cost of making those states mutable which leads to a plethora of potential race conditions. There were even IGT tests merged to cover some of theses: - gem_vm_create@async-destroy and gem_vm_create@destroy-race which test swapping out the VM on a running context. - gem_ctx_persistence@replace* which test whether a client can escape a non-persistent context by submitting a hanging batch and then swapping out the engine set before the hang is detected. - api_intel_bb@bb-with-vm which tests the that intel_bb_assign_vm works properly. This API is never used by any other IGT test. There is also an entire deferred flush and set state framework in i915_gem_cotnext.c which exists for safely swapping out the VM while there is work in-flight on a context. So, clearly people knew that this API was inherently racy and difficult to implement but they landed it anyway. Why? The best explanation I've been given is because it makes the API more "unified" or "symmetric" for this stuff to go through SET_CONTEXT_PARAM. It's not because any userspace actually wants to be able to swap out the VM or the set of engines on a running context. That would be utterly insane. This patch series cleans up this particular mess by introducing the concept of a i915_gem_proto_context data structure which contains context creation information. When you initially call GEM_CONTEXT_CREATE, a proto-context in created instead of an actual context. Then, the first time something is done on the context besides SET_CONTEXT_PARAM, an actual context is created. This allows us to keep the old drivers which use SET_CONTEXT_PARAM to set up the engine set (see also media) while ensuring that, once you have an i915_gem_context, the VM and the engine set are immutable state. Eventually, there are more clean-ups I'd like to do on top of this which should make working with contexts inside i915 simpler and safer: 1. Move the GEM handle -> vma LUT from i915_gem_context into either i915_ppgtt or drm_i915_file_private depending on whether or not the hardware has a full PPGTT. 2. Move the delayed context destruction code into intel_context or a per-engine wrapper struct rather than i915_gem_context. 3. Get rid of the separation between context close and context destroy 4. Get rid of the RCU on i915_gem_context However, these should probably be done as a separate patch series as this one is already starting to get longish, especially if you consider the 89 IGT patches that go along with it. Test-with: 20210423033253.792669-1-ja...@jlekstrand.net Jason Ekstrand (29): drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE drm/i915: Stop storing the ring size in the ring pointer (v2) drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP drm/i915/gem: Set the watchdog timeout directly in
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies
== Series Details == Series: drm/i915/adlp: Add missing TBT AUX -> PW#2 power domain dependencies URL : https://patchwork.freedesktop.org/series/90631/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20215_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20215_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20215_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20215_full: ### IGT changes ### Possible regressions * igt@drm_read@fault-buffer: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb5/igt@drm_r...@fault-buffer.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb5/igt@drm_r...@fault-buffer.html * igt@i915_pm_sseu@full-enable: - shard-skl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl2/igt@i915_pm_s...@full-enable.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl2/igt@i915_pm_s...@full-enable.html Known issues Here are the changes found in Patchwork_20215_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk6/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk8/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][14] ([i915#2389]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-apl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-kbl4/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-glk: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-glk6/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-skl: NOTRUN -> [INCOMPLETE][20] ([i915#198] / [i915#3468]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20215/shard-skl10/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-skl: NOTRUN -> [INCOMPLETE][21] ([i915#3468]) [21]:
Re: [Intel-gfx] [PATCH 3/4] drm/shmem-helper: Switch to vmf_insert_pfn
Hi Daniel, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.13-rc3 next-20210527] [cannot apply to drm/drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/shmem-helpers-for-vgem/20210527-221432 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: h8300-randconfig-r031-20210526 (attached as .config) compiler: h8300-linux-gcc (GCC) 9.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 # https://github.com/0day-ci/linux/commit/cd68a984a14ba7e76552f5e75ee5ab6fd0cb2d05 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Daniel-Vetter/shmem-helpers-for-vgem/20210527-221432 git checkout cd68a984a14ba7e76552f5e75ee5ab6fd0cb2d05 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "vmf_insert_pfn" [drivers/gpu/drm/drm.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/ttm: Fix swapping dereferences of freed memory
On Thu, 2021-05-27 at 17:32 +0200, Christian König wrote:
> Am 27.05.21 um 17:05 schrieb Thomas Hellström:
> > On Thu, 2021-05-27 at 17:01 +0200, Thomas Hellström wrote:
> > > On Thu, 2021-05-27 at 16:54 +0200, Christian König wrote:
> > > > Am 27.05.21 um 16:19 schrieb Thomas Hellström:
> > > > > The swapping code was dereference bo->ttm pointers without
> > > > > having
> > > > > the
> > > > > dma-resv lock held. Also it might try to swap out unpopulated
> > > > > bos.
> > > > >
> > > > > Fix this by moving the bo->ttm dereference until we have the
> > > > > reservation
> > > > > lock. Check that the ttm_tt is populated after the
> > > > > swap_notify
> > > > > callback.
> > > > >
> > > > > Signed-off-by: Thomas Hellström
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/ttm/ttm_bo.c | 16 +++-
> > > > > drivers/gpu/drm/ttm/ttm_device.c | 8 +++-
> > > > > 2 files changed, 18 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > index 9f53506a82fc..86213d37657b 100644
> > > > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > @@ -1163,6 +1163,16 @@ int ttm_bo_swapout(struct
> > > > > ttm_buffer_object
> > > > > *bo, struct ttm_operation_ctx *ctx,
> > > > > if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
> > > > > , NULL))
> > > > > return -EBUSY;
> > > > >
> > > > > + dma_resv_assert_held(bo->base.resv);
> > > > > +
> > > > > + if (!bo->ttm ||
> > > > > + bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
> > > > > + bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED) {
> > > > > + if (locked)
> > > > > + dma_resv_unlock(bo->base.resv);
> > > > > + return -EBUSY;
> > > > > + }
> > > > > +
> > > > > if (!ttm_bo_get_unless_zero(bo)) {
> > > > > if (locked)
> > > > > dma_resv_unlock(bo->base.resv);
> > > > > @@ -1215,7 +1225,8 @@ int ttm_bo_swapout(struct
> > > > > ttm_buffer_object
> > > > > *bo, struct ttm_operation_ctx *ctx,
> > > > > if (bo->bdev->funcs->swap_notify)
> > > > > bo->bdev->funcs->swap_notify(bo);
> > > > >
> > > > > - ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
> > > > > + if (ttm_tt_is_populated(bo->ttm))
> > > > > + ret = ttm_tt_swapout(bo->bdev, bo->ttm,
> > > > > gfp_flags);
> > > > Exactly that is what I won't recommend. We would try to swap
> > > > out
> > > > the
> > > > same BO over and over again with that.
> > > But we wouldn't since the BO is taken off the LRU and never re-
> > > added,
> > >
> > >
> > In fact, we'd probably might want to take the !bo->ttm bos off the
> > LRU
> > as well..
>
> No, we don't want to take any BOs of the LRU unless they are pinned.
>
> Adding a TT object or populating it doesn't necessarily put the BO
> back
> to the LRU.
OK, but swapped bos are also taken off the LRU list so these
unpopulated bos are just taking the same path. Only difference to
swapped is that they don't get read back on re-populate, but typically
cleared.
But what would be the point of keeping swapped-out bos on the LRU
list?, particularly when we're iterating under a spinlock?
Shouldn't we try to re-add to LRU (if not already on an LRU) just
before populating? There aren't really that many calls in core TTM.
/Thomas
>
> Christian.
>
> >
> > /Thomas
> >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
Without wait for vblank, CRC mismatch is seen
between big and small CRC on few Gen11 systems.
Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
Signed-off-by: Vidya Srinivas
---
tests/kms_big_fb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
index b2027b6b9d1b..7d78ff829d41 100644
--- a/tests/kms_big_fb.c
+++ b/tests/kms_big_fb.c
@@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
static bool test_plane(data_t *data)
{
igt_plane_t *plane = data->plane;
+ igt_display_t *display = >display;
struct igt_fb *small_fb = >small_fb;
struct igt_fb *big_fb = >big_fb;
int w = data->big_fb_width - small_fb->width;
@@ -337,16 +338,17 @@ static bool test_plane(data_t *data)
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, big_fb);
igt_fb_set_position(big_fb, plane, x, y);
igt_fb_set_size(big_fb, plane, small_fb->width,
small_fb->height);
+
igt_plane_set_size(plane, data->width, data->height);
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, NULL);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_flip: Some Gen11 systems are not able to get RTC WAKE work well. SUSPEND_TEST_NONE goes to RTC Wake. Instead change it to SUSPEND_TEST_PLATFORM.
Change-Id: I80930185a8799578bbec0123a389074af1edfb5d Signed-off-by: Vidya Srinivas --- tests/kms_flip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 8f736652be90..8afac88c9b15 100755 --- a/tests/kms_flip.c +++ b/tests/kms_flip.c @@ -835,7 +835,8 @@ static bool run_test_step(struct test_output *o, unsigned int *events) if (o->flags & TEST_SUSPEND) igt_system_suspend_autoresume(SUSPEND_STATE_MEM, - SUSPEND_TEST_NONE); + is_i915_device(drm_fd)? + SUSPEND_TEST_PLATFORM:SUSPEND_TEST_NONE); if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > 0) igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, _reply) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)
On Thu, May 27, 2021 at 4:49 AM Christian König wrote: > > Am 26.05.21 um 19:42 schrieb Jason Ekstrand: > > On Wed, May 26, 2021 at 6:02 AM Christian König > > wrote: > >> Regarding that, why do we actually use a syncfile and not a drm_syncobj > >> here? > > A sync file is a userspace handle to a dma_fence which is exactly what > > we're grabbing from the dma-buf so it's a better match. A syncobj, on > > the other hand, is a container for fences. If we really want it in a > > syncobj (which we may), we can use another ioctl to stuff it in there. > > The only thing making this work in terms of syncobj would save us is a > > little ioctl overhead. In my Mesa patches, we do stuff it in a > > syncobj but, instead of acting on the syncobj directly, we go through > > vkSemaphoreImportFd() which is way more convenient for generic WSI > > code. > > Yeah, that is a really good argument. > > > It also works nicer because a sync_file is a pretty generic construct > > but a syncobj is a DRM construct. This lets us do the export in an > > entirely driver-generic way without even having access to a DRM fd. > > It all happens as an ioctl on the dma-buf. > > Well that's an even better argument and I think the killer argument here. Cool. > We should probably mention that on the commit message as a single > sentence somewhere. Happy to do so. How does this sound: By making this an ioctl on the dma-buf itself, it allows this new functionality to be used in an entirely driver-agnostic way without having access to a DRM fd. This makes it ideal for use in driver-generic code in Mesa or in a client such as a compositor where the DRM fd may be hard to reach. > BTW: You replied exclusively to me. Was that intentionally? I don't > think so :) Oops... I've re-added the whole lot in this reply. --Jason > Regards, > Christian. > > > > > On Wed, May 26, 2021 at 8:23 AM Christian König > > wrote: > > > >> Am 26.05.21 um 15:12 schrieb Daniel Stone: > >>> On Wed, 26 May 2021 at 13:46, Christian König > >>> wrote: > Am 26.05.21 um 13:31 schrieb Daniel Stone: > > How would we insert a syncobj+val into a resv though? Like, if we pass > > an unmaterialised syncobj+val here to insert into the resv, then an > > implicit-only media user (or KMS) goes to sync against the resv, what > > happens? > Well this is for exporting, not importing. So we don't need to worry > about that. > > It's just my thinking because the drm_syncobj is the backing object on > VkSemaphore implementations these days, isn't it? > >>> Yeah, I can see that to an extent. But then binary vs. timeline > >>> syncobjs are very different in use (which is unfortunate tbh), and > >>> then we have an asymmetry between syncobj export & sync_file import. > >>> > >>> You're right that we do want a syncobj though. > > I'm not convinced. Some people seem to think that we have a direct > > progression of superiority: sync_file < syncobj < timeline syncobj. I > > don't think this is true. They each serve different purposes. A > > sync_file is a handle to a single immutable fence operation (a > > dma_fence*). A syncobj is a container for a fence and is, by > > definition, mutable (a dma_fence**). A timeline syncobj is a > > construct that lets us implement VK_KHR_timeline_semaphore with only > > immutable finite-time (not future) fences. > > > > From a WSI protocol PoV, it's sometimes nicer to pass a container > > object once and then pass a serial or a simple "I just updated it" > > signal every time instead of a new FD. It certainly makes all the > > "who closes this, again?" semantics easier. But we shouldn't think of > > syncobj as being better than sync_file. With binary syncobj, it > > really is the difference between passing a dma_fence* vs. a > > dma_fence**. Sometimes you want one and sometimes you want the other. > > The real pity, IMO, is that the uAPI is scattered everywhere. > > > >>> This is probably not > >>> practical due to smashing uAPI to bits, but if we could wind the clock > >>> back a couple of years, I suspect the interface we want is that export > >>> can either export a sync_file or a binary syncobj, and further that > >>> binary syncobjs could transparently act as timeline semaphores by > >>> mapping any value (either wait or signal) to the binary signal. In > >>> hindsight, we should probably just never have had binary syncobj. Oh > >>> well. > >> Well the later is the case IIRC. Don't ask me for the detail semantics, > >> but in general the drm_syncobj in timeline mode is compatible to the > >> binary mode. > >> > >> The sync_file is also import/exportable to a certain drm_syncobj > >> timeline point (or as binary signal). So no big deal, we are all > >> compatible here :) > >> > >> I just thought that it might be more appropriate to return a drm_syncobj > >> directly instead of a sync_file. > > Maybe. I'm not convinced that's better. In the current Mesa WSI > > code, it'd actually be
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
Without wait for vblank, CRC mismatch is seen
between big and small CRC on few Gen11 systems.
Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
Signed-off-by: Vidya Srinivas
---
tests/kms_big_fb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
index b2027b6b9d1b..7d78ff829d41 100644
--- a/tests/kms_big_fb.c
+++ b/tests/kms_big_fb.c
@@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
static bool test_plane(data_t *data)
{
igt_plane_t *plane = data->plane;
+ igt_display_t *display = >display;
struct igt_fb *small_fb = >small_fb;
struct igt_fb *big_fb = >big_fb;
int w = data->big_fb_width - small_fb->width;
@@ -337,16 +338,17 @@ static bool test_plane(data_t *data)
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, big_fb);
igt_fb_set_position(big_fb, plane, x, y);
igt_fb_set_size(big_fb, plane, small_fb->width,
small_fb->height);
+
igt_plane_set_size(plane, data->width, data->height);
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, NULL);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/ttm: Fix swapping dereferences of freed memory
Am 27.05.21 um 17:05 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:01 +0200, Thomas Hellström wrote:
On Thu, 2021-05-27 at 16:54 +0200, Christian König wrote:
Am 27.05.21 um 16:19 schrieb Thomas Hellström:
The swapping code was dereference bo->ttm pointers without having
the
dma-resv lock held. Also it might try to swap out unpopulated
bos.
Fix this by moving the bo->ttm dereference until we have the
reservation
lock. Check that the ttm_tt is populated after the swap_notify
callback.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 16 +++-
drivers/gpu/drm/ttm/ttm_device.c | 8 +++-
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 9f53506a82fc..86213d37657b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1163,6 +1163,16 @@ int ttm_bo_swapout(struct
ttm_buffer_object
*bo, struct ttm_operation_ctx *ctx,
if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
, NULL))
return -EBUSY;
+ dma_resv_assert_held(bo->base.resv);
+
+ if (!bo->ttm ||
+ bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
+ bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED) {
+ if (locked)
+ dma_resv_unlock(bo->base.resv);
+ return -EBUSY;
+ }
+
if (!ttm_bo_get_unless_zero(bo)) {
if (locked)
dma_resv_unlock(bo->base.resv);
@@ -1215,7 +1225,8 @@ int ttm_bo_swapout(struct ttm_buffer_object
*bo, struct ttm_operation_ctx *ctx,
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
- ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
+ if (ttm_tt_is_populated(bo->ttm))
+ ret = ttm_tt_swapout(bo->bdev, bo->ttm,
gfp_flags);
Exactly that is what I won't recommend. We would try to swap out
the
same BO over and over again with that.
But we wouldn't since the BO is taken off the LRU and never re-added,
In fact, we'd probably might want to take the !bo->ttm bos off the LRU
as well..
No, we don't want to take any BOs of the LRU unless they are pinned.
Adding a TT object or populating it doesn't necessarily put the BO back
to the LRU.
Christian.
/Thomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_flip: Some Gen11 systems are not able to get RTC WAKE work well. SUSPEND_TEST_NONE goes to RTC Wake. Instead change it to SUSPEND_TEST_PLATFORM.
Change-Id: I80930185a8799578bbec0123a389074af1edfb5d Signed-off-by: Vidya Srinivas --- tests/kms_flip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 64907c2c17a5..42a3048cc11a 100755 --- a/tests/kms_flip.c +++ b/tests/kms_flip.c @@ -835,7 +835,8 @@ static bool run_test_step(struct test_output *o, unsigned int *events) if (o->flags & TEST_SUSPEND) igt_system_suspend_autoresume(SUSPEND_STATE_MEM, - SUSPEND_TEST_NONE); + is_i915_device(drm_fd)? + SUSPEND_TEST_PLATFORM:SUSPEND_TEST_NONE); if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > 0) igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, _reply) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce i915_sched_engine object
== Series Details == Series: Introduce i915_sched_engine object URL : https://patchwork.freedesktop.org/series/90630/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10138_full -> Patchwork_20214_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20214_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20214_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20214_full: ### IGT changes ### Possible regressions * igt@gem_request_retire@retire-vma-not-inactive: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-iclb5/igt@gem_request_ret...@retire-vma-not-inactive.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-iclb4/igt@gem_request_ret...@retire-vma-not-inactive.html Known issues Here are the changes found in Patchwork_20214_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-kbl2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_parallel@fds@rcs0: - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([i915#1895]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-iclb2/igt@gem_exec_parallel@f...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-iclb1/igt@gem_exec_parallel@f...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2389]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][9] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-kbl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@big-copy: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#307]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk2/igt@gem_mmap_...@big-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-glk9/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-skl: [PASS][12] -> [INCOMPLETE][13] ([i915#198] / [i915#3468]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-skl10/igt@gem_mmap_...@cpuset-basic-small-copy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-skl9/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-apl: NOTRUN -> [INCOMPLETE][14] ([i915#3468]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-apl6/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html - shard-glk: [PASS][15] -> [INCOMPLETE][16] ([i915#2055] / [i915#3468]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-glk8/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-glk5/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([i915#3468] / [i915#750]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10138/shard-tglb7/igt@gem_mmap_...@cpuset-medium-copy-xy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-tglb1/igt@gem_mmap_...@cpuset-medium-copy-xy.html - shard-glk: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-glk4/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-skl: NOTRUN -> [INCOMPLETE][20] ([i915#198] / [i915#3468]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20214/shard-skl5/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-skl: NOTRUN -> [INCOMPLETE][21] ([i915#3468]) [21]:
[Intel-gfx] [PATCH] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
Without wait for vblank, CRC mismatch is seen between
big and small CRC on some Gen11 systems
Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
Signed-off-by: Vidya Srinivas
---
tests/kms_big_fb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
index b2027b6b9d1b..7d78ff829d41 100644
--- a/tests/kms_big_fb.c
+++ b/tests/kms_big_fb.c
@@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
static bool test_plane(data_t *data)
{
igt_plane_t *plane = data->plane;
+ igt_display_t *display = >display;
struct igt_fb *small_fb = >small_fb;
struct igt_fb *big_fb = >big_fb;
int w = data->big_fb_width - small_fb->width;
@@ -337,16 +338,17 @@ static bool test_plane(data_t *data)
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, big_fb);
igt_fb_set_position(big_fb, plane, x, y);
igt_fb_set_size(big_fb, plane, small_fb->width,
small_fb->height);
+
igt_plane_set_size(plane, data->width, data->height);
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, NULL);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/ttm: Fix swapping dereferences of freed memory
Am 27.05.21 um 17:01 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 16:54 +0200, Christian König wrote:
Am 27.05.21 um 16:19 schrieb Thomas Hellström:
The swapping code was dereference bo->ttm pointers without having
the
dma-resv lock held. Also it might try to swap out unpopulated bos.
Fix this by moving the bo->ttm dereference until we have the
reservation
lock. Check that the ttm_tt is populated after the swap_notify
callback.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 16 +++-
drivers/gpu/drm/ttm/ttm_device.c | 8 +++-
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 9f53506a82fc..86213d37657b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1163,6 +1163,16 @@ int ttm_bo_swapout(struct ttm_buffer_object
*bo, struct ttm_operation_ctx *ctx,
if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
, NULL))
return -EBUSY;
+ dma_resv_assert_held(bo->base.resv);
+
+ if (!bo->ttm ||
+ bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
+ bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED) {
+ if (locked)
+ dma_resv_unlock(bo->base.resv);
+ return -EBUSY;
+ }
+
if (!ttm_bo_get_unless_zero(bo)) {
if (locked)
dma_resv_unlock(bo->base.resv);
@@ -1215,7 +1225,8 @@ int ttm_bo_swapout(struct ttm_buffer_object
*bo, struct ttm_operation_ctx *ctx,
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
- ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
+ if (ttm_tt_is_populated(bo->ttm))
+ ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
Exactly that is what I won't recommend. We would try to swap out the
same BO over and over again with that.
But we wouldn't since the BO is taken off the LRU and never re-added,
Well then that would be a bug in itself.
Why not move that to the check above as well?
Because the BO may become unpopulated in swap_notify(), i915, like
vmwgfx, sometimes sets up gpu bindings from system, and when we get a
notification from user-space that those are purgeable, we don't want to
purge immediately but wait for a potential swapout.
Uff, good point. But then we need to check that at both locations I think.
Because populating the TT object currently doesn't put the BO back on
the LRU eventually.
Christian.
/Thomas
Christian.
out:
/*
@@ -1225,6 +1236,9 @@ int ttm_bo_swapout(struct ttm_buffer_object
*bo, struct ttm_operation_ctx *ctx,
if (locked)
dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
+
+ /* Don't break locking rules. */
+ WARN_ON(ret == -EBUSY);
return ret;
}
diff --git a/drivers/gpu/drm/ttm/ttm_device.c
b/drivers/gpu/drm/ttm/ttm_device.c
index 460953dcad11..eaa7487ae404 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -143,14 +143,12 @@ int ttm_device_swapout(struct ttm_device
*bdev, struct ttm_operation_ctx *ctx,
for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
list_for_each_entry(bo, >lru[j], lru)
{
- uint32_t num_pages;
+ pgoff_t num_pages;
- if (!bo->ttm ||
- bo->ttm->page_flags &
TTM_PAGE_FLAG_SG ||
- bo->ttm->page_flags &
TTM_PAGE_FLAG_SWAPPED)
+ if (!READ_ONCE(bo->ttm))
continue;
- num_pages = bo->ttm->num_pages;
+ num_pages = bo->base.size >>
PAGE_SHIFT;
ret = ttm_bo_swapout(bo, ctx,
gfp_flags);
/* ttm_bo_swapout has dropped the
lru_lock */
if (!ret)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [RFC] tests/kms_flip: Some Gen11 systems are not able to get RTC WAKE work well. SUSPEND_TEST_NONE goes to RTC Wake. Instead change it to SUSPEND_TEST_PLATFORM.
Change-Id: I80930185a8799578bbec0123a389074af1edfb5d Signed-off-by: Vidya Srinivas --- tests/kms_flip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 64907c2c17a5..4d45dd77e9d9 100755 --- a/tests/kms_flip.c +++ b/tests/kms_flip.c @@ -835,7 +835,7 @@ static bool run_test_step(struct test_output *o, unsigned int *events) if (o->flags & TEST_SUSPEND) igt_system_suspend_autoresume(SUSPEND_STATE_MEM, - SUSPEND_TEST_NONE); + SUSPEND_TEST_PLATFORM); if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > 0) igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, _reply) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH 4/4] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
Hello Juha-Pekka,
I am sorry, this is not needed.
Thank you so much.
Regards
Vidya
-Original Message-
From: Juha-Pekka Heikkila
Sent: Thursday, May 27, 2021 8:40 PM
To: Srinivas, Vidya ;
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Cc: Lin, Charlton
Subject: Re: [igt-dev] [PATCH 4/4] [RFC] tests/kms_big_fb: Wait for vblank
before collecting CRC
On 27.5.2021 17.31, Vidya Srinivas wrote:
> Without wait for vblank, CRC mismatch is seen between big and small
> CRC on some intel Gen11 platforms.
>
> Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_big_fb.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index
> b2027b6b9d1b..da682593429b 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
> static bool test_plane(data_t *data)
> {
> igt_plane_t *plane = data->plane;
> + igt_display_t *display = >display;
> struct igt_fb *small_fb = >small_fb;
> struct igt_fb *big_fb = >big_fb;
> int w = data->big_fb_width - small_fb->width; @@ -269,6 +270,7 @@
> static bool test_plane(data_t *data)
> { w / 3, h * 3 / 4, },
> { w, h, },
> };
> + bool check_platform_intel = is_i915_device(data->drm_fd);
You will not need to do this. This test start with
drm_open_driver_master(DRIVER_INTEL)
hence will always be only on intel device.
>
> if (!igt_plane_has_format_mod(plane, data->format, data->modifier))
> return false;
> @@ -336,17 +338,19 @@ static bool test_plane(data_t *data)
>
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> -
> + if (check_platform_intel)
> + igt_wait_for_vblank(data->drm_fd,
> +display->pipes[data->pipe].crtc_offset);
Above this line there's flip to different framebuffer and below this line
there's restart of crc collection before get any crc. If there's need to wait a
vblank at this place to get matching crcs the actual bug is somewhere else.
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, big_fb);
> igt_fb_set_position(big_fb, plane, x, y);
> igt_fb_set_size(big_fb, plane, small_fb->width,
> small_fb->height);
> +
> igt_plane_set_size(plane, data->width, data->height);
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> + if (check_platform_intel)
> + igt_wait_for_vblank(data->drm_fd,
> +display->pipes[data->pipe].crtc_offset);
Here it's the same story as above.
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, NULL);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function
On 27/05/2021 15:35, Matthew Brost wrote:
On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
On 26/05/2021 19:10, Matthew Brost wrote:
[snip]
+static int ct_send_nb(struct intel_guc_ct *ct,
+ const u32 *action,
+ u32 len,
+ u32 flags)
+{
+ struct intel_guc_ct_buffer *ctb = >ctbs.send;
+ unsigned long spin_flags;
+ u32 fence;
+ int ret;
+
+ spin_lock_irqsave(>lock, spin_flags);
+
+ ret = ctb_has_room(ctb, len + 1);
+ if (unlikely(ret))
+ goto out;
+
+ fence = ct_get_next_fence(ct);
+ ret = ct_write(ct, action, len, fence, flags);
+ if (unlikely(ret))
+ goto out;
+
+ intel_guc_notify(ct_to_guc(ct));
+
+out:
+ spin_unlock_irqrestore(>lock, spin_flags);
+
+ return ret;
+}
+
static int ct_send(struct intel_guc_ct *ct,
const u32 *action,
u32 len,
@@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
u32 response_buf_size,
u32 *status)
{
+ struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct ct_request request;
unsigned long flags;
u32 fence;
@@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
+ might_sleep();
Sleep is just cond_resched below or there is more?
Yes, the cond_resched.
+ /*
+* We use a lazy spin wait loop here as we believe that if the CT
+* buffers are sized correctly the flow control condition should be
+* rare.
+*/
+retry:
spin_lock_irqsave(>ctbs.send.lock, flags);
+ if (unlikely(!ctb_has_room(ctb, len + 1))) {
+ spin_unlock_irqrestore(>ctbs.send.lock, flags);
+ cond_resched();
+ goto retry;
+ }
If this patch is about adding a non-blocking send function, and below we can
see that it creates a fork:
intel_guc_ct_send:
...
if (flags & INTEL_GUC_SEND_NB)
return ct_send_nb(ct, action, len, flags);
ret = ct_send(ct, action, len, response_buf, response_buf_size,
);
Then why is there a change in ct_send here, which is not the new
non-blocking path?
There is not a change to ct_send(), just to intel_guc_ct_send.
I was doing by the diff which says:
static int ct_send(struct intel_guc_ct *ct,
const u32 *action,
u32 len,
@@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
u32 response_buf_size,
u32 *status)
{
+ struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct ct_request request;
unsigned long flags;
u32 fence;
@@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
+ might_sleep();
+ /*
+* We use a lazy spin wait loop here as we believe that if the CT
+* buffers are sized correctly the flow control condition should be
+* rare.
+*/
+retry:
spin_lock_irqsave(>ctbs.send.lock, flags);
+ if (unlikely(!ctb_has_room(ctb, len + 1))) {
+ spin_unlock_irqrestore(>ctbs.send.lock, flags);
+ cond_resched();
+ goto retry;
+ }
So it looks like a change to ct_send to me. Is that wrong?
What about this part - is the patch changing the blocking ct_send or not,
and if it is why?
Yes, ct_send() changes. Sorry for the confusion.
This function needs to be updated to account for the H2G space and
backoff if no space is available.
Since this one is the sleeping path, it probably can and needs to be
smarter than having a cond_resched busy loop added. Like sleep and get
woken up when there is space. Otherwise it can degenerate to busy
looping via contention with the non-blocking path.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH 4/4] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
On 27.5.2021 17.31, Vidya Srinivas wrote:
Without wait for vblank, CRC mismatch is seen
between big and small CRC on some intel Gen11 platforms.
Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
Signed-off-by: Vidya Srinivas
---
tests/kms_big_fb.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
index b2027b6b9d1b..da682593429b 100644
--- a/tests/kms_big_fb.c
+++ b/tests/kms_big_fb.c
@@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
static bool test_plane(data_t *data)
{
igt_plane_t *plane = data->plane;
+ igt_display_t *display = >display;
struct igt_fb *small_fb = >small_fb;
struct igt_fb *big_fb = >big_fb;
int w = data->big_fb_width - small_fb->width;
@@ -269,6 +270,7 @@ static bool test_plane(data_t *data)
{ w / 3, h * 3 / 4, },
{ w, h, },
};
+ bool check_platform_intel = is_i915_device(data->drm_fd);
You will not need to do this. This test start with
drm_open_driver_master(DRIVER_INTEL)
hence will always be only on intel device.
if (!igt_plane_has_format_mod(plane, data->format, data->modifier))
return false;
@@ -336,17 +338,19 @@ static bool test_plane(data_t *data)
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
-
+ if (check_platform_intel)
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
Above this line there's flip to different framebuffer and below this
line there's restart of crc collection before get any crc. If there's
need to wait a vblank at this place to get matching crcs the actual bug
is somewhere else.
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, big_fb);
igt_fb_set_position(big_fb, plane, x, y);
igt_fb_set_size(big_fb, plane, small_fb->width,
small_fb->height);
+
igt_plane_set_size(plane, data->width, data->height);
igt_display_commit2(>display, data->display.is_atomic ?
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
-
+ if (check_platform_intel)
+ igt_wait_for_vblank(data->drm_fd,
display->pipes[data->pipe].crtc_offset);
Here it's the same story as above.
igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
igt_plane_set_fb(plane, NULL);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
