[Intel-gfx] ✗ Fi.CI.IGT: failure for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8825_full -> Patchwork_18290_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18290_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18290_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_18290_full: ### IGT changes ### Possible regressions * igt@gem_ctx_ringsize@active@bcs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-skl6/igt@gem_ctx_ringsize@act...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-skl6/igt@gem_ctx_ringsize@act...@bcs0.html * igt@gem_partial_pwrite_pread@reads-uncached: - shard-glk: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-glk3/igt@gem_partial_pwrite_pr...@reads-uncached.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-glk3/igt@gem_partial_pwrite_pr...@reads-uncached.html * igt@perf@blocking: - shard-hsw: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-hsw1/igt@p...@blocking.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-hsw4/igt@p...@blocking.html * igt@prime_busy@before@vecs0: - shard-hsw: [PASS][7] -> [FAIL][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-hsw2/igt@prime_busy@bef...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-hsw2/igt@prime_busy@bef...@vecs0.html New tests - New tests have been introduced between CI_DRM_8825_full and Patchwork_18290_full: ### New IGT tests (9) ### * igt@perf@closed-fd-and-unmapped-access: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.29] s * igt@perf@invalid-map-oa-buffer: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.18] s * igt@perf@map-oa-buffer: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.32] s * igt@perf@non-privileged-access-vaddr: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.29] s * igt@perf@non-privileged-map-oa-buffer: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.24] s * igt@perf@oa-regs-not-whitelisted: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 0.22] s * igt@perf@oa-regs-whitelisted: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 0.27] s * igt@perf@triggered-oa-reports-paranoid-0: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 3.40] s * igt@perf@triggered-oa-reports-paranoid-1: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 3.46] s Known issues Here are the changes found in Patchwork_18290_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-glk9/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@kms_addfb_basic@size-max: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +61 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-skl7/igt@kms_addfb_ba...@size-max.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-skl10/igt@kms_addfb_ba...@size-max.html * igt@kms_cursor_crc@pipe-a-cursor-alpha-opaque: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-alpha-opaque.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-alpha-opaque.html - shard-apl: [PASS][15] -> [FAIL][16] ([i915#1635] / [i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-alpha-opaque.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-alpha-opaque.html - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/shard-skl2/igt@kms_cursor_...@pipe-a-cursor-alpha-opaque.html [18]:
[Intel-gfx] ✓ Fi.CI.BAT: success for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : success == Summary == CI Bug Log - changes from CI_DRM_8825 -> Patchwork_18290 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/index.html Known issues Here are the changes found in Patchwork_18290 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-bsw-n3050/igt@i915_pm_...@module-reload.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][5] ([i915#1684]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-icl-y/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - fi-tgl-u2: [DMESG-FAIL][7] ([i915#1233]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [DMESG-WARN][9] ([i915#2203]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html Warnings * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8825/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233 [i915#1684]: https://gitlab.freedesktop.org/drm/intel/issues/1684 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (42 -> 35) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * IGT: IGT_5755 -> IGTPW_4832 * Linux: CI_DRM_8825 -> Patchwork_18290 CI-20190529: 20190529 CI_DRM_8825: 0f1296eaac7727fda784e6796248016f06525035 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_4832: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4832/index.html IGT_5755: e9ef5db4cd286fb4bf151a24efcd7a62a4df18f1 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18290: 135906ef2e3388ec83705088f3cd89c0f8b9a826 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 135906ef2e33 drm/i915/perf: Map OA buffer to user space for gen12 performance query a489828d3eb3 drm/i915/perf: Whitelist OA counter and buffer registers bdf3913ee216 drm/i915/perf: Whitelist OA report trigger registers 7f2ac7c626be drm/i915/perf: Ensure observation logic is not clock gated == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18290/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_perf.c:3281: warning: Function parameter or member 'cmd' not described in 'i915_perf_oa_buffer_info_locked' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80156/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggered reports within oa buffer.
Triggering reports into the OA buffer is achieved by writing into a
a trigger register. Optionally an unused counter/register is set with a
marker value such that a triggered report can be identified in the OA
buffer. Reports are usually triggered at the start and end of work that
is measured.
Since OA buffer is large and queries can be frequent, an efficient way
to look for triggered reports is required. By knowing the current head
and tail offsets into the OA buffer, it is easier to determine the
locality of the reports of interest.
Current perf OA interface does not expose head/tail information to the
user and it filters out invalid reports before sending data to user.
Also considering limited size of user buffer used during a query,
creating a 1:1 copy of the OA buffer at the user space added undesired
complexity.
The solution was to map the OA buffer to user space provided
(1) that it is accessed from a privileged user.
(2) OA report filtering is not used.
These 2 conditions would satisfy the safety criteria that the current
perf interface addresses.
To enable the query:
- Add an ioctl to expose head and tail to the user
- Add an ioctl to return size and offset of the OA buffer
- Map the OA buffer to the user space
v2:
- Improve commit message (Chris)
- Do not mmap based on gem object filp. Instead, use perf_fd and support
mmap syscall (Chris)
- Pass non-zero offset in mmap to enforce the right object is
mapped (Chris)
- Do not expose gpu_address (Chris)
- Verify start and length of vma for page alignment (Lionel)
- Move SQNTL config out (Lionel)
v3: (Chris)
- Omit redundant checks
- Return VM_FAULT_SIGBUS is old stream is closed
- Maintain reference counts to stream in vm_open and vm_close
- Use switch to identify object to be mapped
v4: Call kref_put on closing perf fd (Chris)
v5:
- Strip access to OA buffer from unprivileged child of a privileged
parent. Use VM_DONTCOPY
- Enforce MAP_PRIVATE by checking for VM_MAYSHARE
v6:
(Chris)
- Use len of -1 in unmap_mapping_range
- Don't use stream->oa_buffer.vma->obj in vm_fault_oa
- Use kernel block comment style
- do_mmap gets a reference to the file and puts it in do_munmap, so
no need to maintain a reference to i915_perf_stream. Hence, remove
vm_open/vm_close and stream->closed hooks/checks.
(Umesh)
- Do not allow mmap if SAMPLE_OA_REPORT is not set during
i915_perf_open_ioctl.
- Drop ioctl returning head/tail since this information is already
whitelisted. Remove hooks to read head register.
v7: (Chris)
- unmap before destroy
- change ioctl argument struct
v8: Documentation and more checks (Chris)
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 +
drivers/gpu/drm/i915/i915_perf.c | 125 ++-
include/uapi/drm/i915_drm.h | 33 ++
4 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b23368529a40..7c4b9b0c334b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -204,7 +204,7 @@ compute_partial_view(const struct drm_i915_gem_object *obj,
return view;
}
-static vm_fault_t i915_error_to_vmf_fault(int err)
+vm_fault_t i915_error_to_vmf_fault(int err)
{
switch (err) {
default:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index efee9e0d2508..1190a3a228ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
+vm_fault_t i915_error_to_vmf_fault(int err);
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 562154d3fd49..e2b02a9a4645 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,10 +192,12 @@
*/
#include
+#include
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_mman.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
@@ -3265,6 +3267,43 @@ static long i915_perf_config_locked(struct
i915_perf_stream *stream,
return ret;
}
+#define I915_PERF_OA_BUFFER_MMAP_OFFSET 1
+
+/**
+ * i915_perf_oa_buffer_info_locked - size and offset of the OA buffer
+ * @stream: i915 perf stream
+ * @arg: pointer to
[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer
- Fixes a memory corruption due to addition of OA whitelist on demand. - Spinlock when applying whitelist This cover letter is included to trigger "Test-with" an IGT patch. Tests - https://patchwork.freedesktop.org/series/80113/ Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200730230002.55737-1-umesh.nerlige.rama...@intel.com Piotr Maciejewski (1): drm/i915/perf: Ensure observation logic is not clock gated Umesh Nerlige Ramappa (3): drm/i915/perf: Whitelist OA report trigger registers drm/i915/perf: Whitelist OA counter and buffer registers drm/i915/perf: Map OA buffer to user space for gen12 performance query drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 129 -- drivers/gpu/drm/i915/gt/intel_workarounds.h | 7 + .../gpu/drm/i915/gt/intel_workarounds_types.h | 5 + drivers/gpu/drm/i915/i915_perf.c | 224 +- drivers/gpu/drm/i915/i915_perf_types.h| 6 + drivers/gpu/drm/i915/i915_reg.h | 10 + include/uapi/drm/i915_drm.h | 33 +++ 10 files changed, 392 insertions(+), 28 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.
Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is checked and the whitelist is
enabled accordingly. On closing the perf fd, the whitelist is removed.
This ensures that the access to the whitelist is gated by
perf_stream_paranoid.
v2:
- Move related change to this patch (Lionel)
- Bump up perf revision (Lionel)
v3: Pardon whitelisted registers for selftest (Umesh)
v4: Document supported gens for the feature (Lionel)
v5: Whitelist registers only if perf_stream_paranoid is set to 0 (Jon)
v6: Move oa whitelist array to i915_perf (Chris)
v7: Fix OA writing beyond the wal->list memory (CI)
v8: Protect write to engine whitelist registers
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 129 ++
drivers/gpu/drm/i915/gt/intel_workarounds.h | 7 +
.../gpu/drm/i915/gt/intel_workarounds_types.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 76 ++-
drivers/gpu/drm/i915/i915_perf_types.h| 6 +
6 files changed, 198 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c400aaa2287b..180fc0cdb289 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -406,6 +406,8 @@ struct intel_engine_cs {
struct i915_wa_list ctx_wa_list;
struct i915_wa_list wa_list;
struct i915_wa_list whitelist;
+ /* lock protects write to engine force_to_nonpriv registers */
+ spinlock_t lock;
u32 irq_keep_mask; /* always keep these interrupts */
u32 irq_enable_mask; /* bitmask to enable ring interrupt */
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index cef1c122696f..98520e774481 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -60,12 +60,23 @@ static void wa_init_start(struct i915_wa_list *wal, const
char *name, const char
#define WA_LIST_CHUNK (1 << 4)
+/*
+ * Some of the i915 code like perf OA tries to whitelist registers on demand.
+ * Such code adds to the wal->list, but that would not work because the list
+ * is compacted below by wa_init_finish. While _wa_add does have code to grow
+ * the list, it does not seem to take the compaction into consideration. Leave
+ * 8 entries free during the compaction until a better mechanism can be put in
+ * place.
+ */
+#define WA_LIST_DYNAMIC_ENTRIES 8
+
static void wa_init_finish(struct i915_wa_list *wal)
{
/* Trim unused entries. */
if (!IS_ALIGNED(wal->count, WA_LIST_CHUNK)) {
+ size_t size = wal->count + WA_LIST_DYNAMIC_ENTRIES;
struct i915_wa *list = kmemdup(wal->list,
- wal->count * sizeof(*list),
+ size * sizeof(*list),
GFP_KERNEL);
if (list) {
@@ -81,10 +92,50 @@ static void wa_init_finish(struct i915_wa_list *wal)
wal->wa_count, wal->name, wal->engine_name);
}
+static int _wa_index(struct i915_wa_list *wal, i915_reg_t reg)
+{
+ unsigned int addr = i915_mmio_reg_offset(reg);
+ int start = 0, end = wal->count;
+
+ /* addr and wal->list[].reg, both include the R/W flags */
+ while (start < end) {
+ int mid = start + (end - start) / 2;
+
+ if (i915_mmio_reg_offset(wal->list[mid].reg) < addr)
+ start = mid + 1;
+ else if (i915_mmio_reg_offset(wal->list[mid].reg) > addr)
+ end = mid;
+ else
+ return mid;
+ }
+
+ return -1;
+}
+
+static void _wa_remove(struct i915_wa_list *wal, i915_reg_t reg, u32 flags)
+{
+ int index;
+ struct i915_wa *wa = wal->list;
+
+ reg.reg |= flags;
+
+ index = _wa_index(wal, reg);
+ if (index < 0)
+ return;
+
+ memset(wa + index, 0, sizeof(*wa));
+
+ while (index < wal->count - 1) {
+ swap(wa[index], wa[index + 1]);
+ index++;
+ }
+
+ wal->count--;
+}
+
static void _wa_add(struct i915_wa_list *wal, const struct i915_wa *wa)
{
- unsigned int addr = i915_mmio_reg_offset(wa->reg);
- unsigned int start = 0, end = wal->count;
+ int index;
const unsigned int grow = WA_LIST_CHUNK;
struct i915_wa *wa_;
@@ -106,30 +157,23 @@ static void _wa_add(struct i915_wa_list *wal, const
struct i915_wa *wa)
[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)
v4: Use intel_uncore_rmw and REG_BIT (Chris)
Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c6f6370283cf..a43bf4cd337a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2493,6 +2493,12 @@ gen12_enable_metric_set(struct i915_perf_stream *stream,
(period_exponent <<
GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
: 0);
+ /*
+* Initialize Super Queue Internal Cnt Register
+* Set PMON Enable in order to collect valid metrics.
+*/
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, 0, GEN12_SQCNT1_PMON_ENABLE);
+
/*
* Update all contexts prior writing the mux configurations as we need
* to make sure all slices/subslices are ON before writing to NOA
@@ -2552,6 +2558,9 @@ static void gen12_disable_metric_set(struct
i915_perf_stream *stream)
/* Make sure we disable noa to save power. */
intel_uncore_rmw(uncore, RPM_CONFIG1, GEN10_GT_NOA_ENABLE, 0);
+
+ /* Reset PMON Enable to save power. */
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, GEN12_SQCNT1_PMON_ENABLE, 0);
}
static void gen7_oa_enable(struct i915_perf_stream *stream)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5eae593ee784..5e09acbd1406 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -696,6 +696,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define OABUFFER_SIZE_16M (7 << 3)
#define GEN12_OA_TLB_INV_CR _MMIO(0xceec)
+#define GEN12_SQCNT1 _MMIO(0x8718)
+#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
/* Gen12 OAR unit */
#define GEN12_OAR_OACONTROL _MMIO(0x2960)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
specific registers.
v2:
- Bump up the perf revision (Lionel)
- Use indexing for counters (Lionel)
- Fix selftest for oa ticking register (Umesh)
v3: Pardon whitelisted registers for selftest (Umesh)
v4:
- Document whitelisted registers (Lionel)
- Fix live isolated whitelist for OA regs (Umesh)
v5:
- Free up whitelist slots. Remove GPU_TICKS and A20 counter (Piotr)
- Whitelist registers only if perf_stream_paranoid is set to 0 (Jon)
v6: Move oa whitelist array to i915_perf (Chris)
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 18 +-
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7443654ef842..562154d3fd49 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1350,11 +1350,19 @@ free_noa_wait(struct i915_perf_stream *stream)
static struct i915_whitelist_reg gen9_oa_wl_regs[] = {
{ OAREPORTTRIG2, RING_FORCE_TO_NONPRIV_ACCESS_RW },
{ OAREPORTTRIG6, RING_FORCE_TO_NONPRIV_ACCESS_RW },
+ { OA_PERF_COUNTER_A(18), RING_FORCE_TO_NONPRIV_ACCESS_RW |
+RING_FORCE_TO_NONPRIV_RANGE_4 },
+ { GEN8_OASTATUS, RING_FORCE_TO_NONPRIV_ACCESS_RD |
+RING_FORCE_TO_NONPRIV_RANGE_4 },
};
static struct i915_whitelist_reg gen12_oa_wl_regs[] = {
{ GEN12_OAG_OAREPORTTRIG2, RING_FORCE_TO_NONPRIV_ACCESS_RW },
{ GEN12_OAG_OAREPORTTRIG6, RING_FORCE_TO_NONPRIV_ACCESS_RW },
+ { GEN12_OAG_PERF_COUNTER_A(18), RING_FORCE_TO_NONPRIV_ACCESS_RW |
+ RING_FORCE_TO_NONPRIV_RANGE_4 },
+ { GEN12_OAG_OASTATUS, RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4 },
};
static void intel_engine_apply_oa_whitelist(struct i915_perf_stream *stream)
@@ -4511,8 +4519,16 @@ int i915_perf_ioctl_version(void)
*into the OA buffer. This applies only to gen8+. The feature can
*only be accessed if perf_stream_paranoid is set to 0 by privileged
*user.
+*
+* 7: Whitelist below OA registers for user to identify the location of
+*triggered reports in the OA buffer. This applies only to gen8+.
+*The feature can only be accessed if perf_stream_paranoid is set to
+*0 by privileged user.
+*
+*- OA buffer head/tail/status/buffer registers for read only
+*- OA counters A18, A19, A20 for read/write
*/
- return 6;
+ return 7;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e09acbd1406..497f75e70f8a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -974,6 +974,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define OAREPORTTRIG8_NOA_SELECT_6_SHIFT24
#define OAREPORTTRIG8_NOA_SELECT_7_SHIFT28
+/* Performance counters registers */
+#define OA_PERF_COUNTER_A(idx) _MMIO(0x2800 + 8 * (idx))
+#define OA_PERF_COUNTER_A_UPPER(idx) _MMIO(0x2800 + 8 * (idx) + 4)
+
+/* Gen12 Performance counters registers */
+#define GEN12_OAG_PERF_COUNTER_A(idx) _MMIO(0xD980 + 8 * (idx))
+#define GEN12_OAG_PERF_COUNTER_A_UPPER(idx) _MMIO(0xD980 + 8 * (idx) + 4)
+
/* Same layout as OASTARTTRIGX */
#define GEN12_OAG_OASTARTTRIG1 _MMIO(0xd900)
#define GEN12_OAG_OASTARTTRIG2 _MMIO(0xd904)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8823_full -> Patchwork_18289_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18289_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18289_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_18289_full: ### IGT changes ### Possible regressions * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-d-planes: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-tglb8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-d-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-tglb2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-d-planes.html Known issues Here are the changes found in Patchwork_18289_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-glk6/igt@gem_exec_whis...@basic-fds-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-glk1/igt@gem_exec_whis...@basic-fds-all.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([i915#1635] / [i915#2119]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-apl7/igt@i915_selftest@m...@contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-apl6/igt@i915_selftest@m...@contexts.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-glk5/igt@kms_big...@x-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_cursor_legacy@flip-vs-cursor-toggle: - shard-skl: [PASS][9] -> [FAIL][10] ([IGT#5]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +17 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-skl10/igt@kms_flip_til...@flip-changes-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-skl2/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-glk3/igt@kms_frontbuffer_track...@fbc-badstride.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-glk2/igt@kms_frontbuffer_track...@fbc-badstride.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-mmap-cpu: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/shard-skl1/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/shard-skl3/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18288_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18288_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18288_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_18288_full: ### IGT changes ### Possible regressions * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-iclb7/igt@gem_ctx_isolation@preservation...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-iclb3/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_exec_parallel@contexts@vcs1: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb1/igt@gem_exec_parallel@conte...@vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-tglb8/igt@gem_exec_parallel@conte...@vcs1.html * igt@runner@aborted: - shard-tglb: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-tglb8/igt@run...@aborted.html New tests - New tests have been introduced between CI_DRM_8822_full and Patchwork_18288_full: ### New IGT tests (9) ### * igt@perf@closed-fd-and-unmapped-access: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.29] s * igt@perf@invalid-map-oa-buffer: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.15] s * igt@perf@map-oa-buffer: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.30] s * igt@perf@non-privileged-access-vaddr: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 0.29] s * igt@perf@non-privileged-map-oa-buffer: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 0.24] s * igt@perf@oa-regs-not-whitelisted: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 0.21] s * igt@perf@oa-regs-whitelisted: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 0.26] s * igt@perf@triggered-oa-reports-paranoid-0: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 3.77] s * igt@perf@triggered-oa-reports-paranoid-1: - Statuses : 6 pass(s) 2 skip(s) - Exec time: [0.0, 3.56] s Known issues Here are the changes found in Patchwork_18288_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@render: - shard-skl: [PASS][6] -> [FAIL][7] ([i915#1528]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-skl1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html * igt@gem_exec_fence@parallel@bcs0: - shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#118] / [i915#95]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk4/igt@gem_exec_fence@paral...@bcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-glk7/igt@gem_exec_fence@paral...@bcs0.html * igt@kms_addfb_basic@size-max: - shard-skl: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) +64 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl3/igt@kms_addfb_ba...@size-max.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-skl8/igt@kms_addfb_ba...@size-max.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][12] -> [DMESG-FAIL][13] ([i915#118] / [i915#95]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk1/igt@kms_big...@linear-64bpp-rotate-0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#1635] / [i915#1982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-apl7/igt@kms_big...@y-tiled-64bpp-rotate-0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/shard-apl3/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-alpha-opaque: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#54]) [16]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool
== Series Details == Series: drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool URL : https://patchwork.freedesktop.org/series/80147/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18287_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18287_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18287_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_18287_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl7/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-skl8/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_18287_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@bcs0: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#1528]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html * igt@gem_exec_whisper@basic-normal: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk7/igt@gem_exec_whis...@basic-normal.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-glk2/igt@gem_exec_whis...@basic-normal.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk1/igt@kms_big...@linear-64bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl2/igt@kms_flip@flip-vs-susp...@c-dp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +13 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl4/igt@kms_flip_til...@flip-changes-tiling.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-skl7/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk7/igt@kms_frontbuffer_track...@fbc-badstride.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-glk2/igt@kms_frontbuffer_track...@fbc-badstride.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-cpu.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-iclb2/igt@kms_psr@psr2_basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-iclb4/igt@kms_psr@psr2_basic.html * igt@kms_setmode@basic: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#31]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl4/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/shard-kbl2/igt@kms_setm...@basic.html * igt@kms_universal_plane@universal-plane-gen9-features-pipe-a: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl3/igt@kms_universal_pl...@universal-plane-gen9-features-pipe-a.html [22]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: timeline semaphore support
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80146/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18286_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18286_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18286_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_18286_full:
### IGT changes ###
Possible regressions
* {igt@gem_exec_fence@syncobj-backward-timeline-chain-engines} (NEW):
- shard-glk: NOTRUN -> [DMESG-WARN][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-glk7/igt@gem_exec_fe...@syncobj-backward-timeline-chain-engines.html
- shard-iclb: NOTRUN -> [DMESG-WARN][2] +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-iclb7/igt@gem_exec_fe...@syncobj-backward-timeline-chain-engines.html
* {igt@gem_exec_fence@syncobj-stationary-timeline-chain-engines} (NEW):
- shard-tglb: NOTRUN -> [DMESG-WARN][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-tglb6/igt@gem_exec_fe...@syncobj-stationary-timeline-chain-engines.html
* {igt@gem_exec_fence@syncobj-timeline-wait} (NEW):
- shard-tglb: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-tglb7/igt@gem_exec_fe...@syncobj-timeline-wait.html
- shard-skl: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-skl7/igt@gem_exec_fe...@syncobj-timeline-wait.html
- shard-glk: NOTRUN -> [FAIL][6] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-glk1/igt@gem_exec_fe...@syncobj-timeline-wait.html
* igt@gem_exec_schedule@smoketest-all:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb3/igt@gem_exec_sched...@smoketest-all.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-tglb8/igt@gem_exec_sched...@smoketest-all.html
* {igt@syncobj_timeline@device-submit-unordered} (NEW):
- shard-snb: NOTRUN -> [DMESG-WARN][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-snb5/igt@syncobj_timel...@device-submit-unordered.html
- shard-kbl: NOTRUN -> [DMESG-WARN][10] +2 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-kbl3/igt@syncobj_timel...@device-submit-unordered.html
- shard-hsw: NOTRUN -> [DMESG-WARN][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-hsw8/igt@syncobj_timel...@device-submit-unordered.html
- shard-skl: NOTRUN -> [DMESG-WARN][12] +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-skl8/igt@syncobj_timel...@device-submit-unordered.html
* {igt@syncobj_timeline@reset-during-wait-for-submit} (NEW):
- shard-kbl: NOTRUN -> [FAIL][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/shard-kbl3/igt@syncobj_timel...@reset-during-wait-for-submit.html
New tests
-
New tests have been introduced between CI_DRM_8822_full and
Patchwork_18286_full:
### New IGT tests (132) ###
* igt@gem_exec_fence@invalid-timeline-fence-array:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.01] s
* igt@gem_exec_fence@syncobj-backward-timeline-chain-engines:
- Statuses : 6 dmesg-warn(s) 2 skip(s)
- Exec time: [0.0, 0.30] s
* igt@gem_exec_fence@syncobj-stationary-timeline-chain-engines:
- Statuses : 6 dmesg-warn(s) 2 skip(s)
- Exec time: [0.0, 0.29] s
* igt@gem_exec_fence@syncobj-timeline-chain-engines:
- Statuses : 6 pass(s) 2 skip(s)
- Exec time: [0.0, 0.24] s
* igt@gem_exec_fence@syncobj-timeline-export:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.01] s
* igt@gem_exec_fence@syncobj-timeline-invalid-flags:
- Statuses : 8 pass(s)
- Exec time: [0.0, 0.00] s
* igt@gem_exec_fence@syncobj-timeline-invalid-wait:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.02] s
* igt@gem_exec_fence@syncobj-timeline-repeat:
- Statuses : 7 pass(s)
- Exec time: [0.22, 3.10] s
* igt@gem_exec_fence@syncobj-timeline-signal:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.02] s
* igt@gem_exec_fence@syncobj-timeline-unused-fence:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.01] s
* igt@gem_exec_fence@syncobj-timeline-wait:
- Statuses : 4 fail(s) 4 pass(s)
-
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
On 31/07/2020 17:32, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-07-31 14:45:52) Introduces a new parameters to execbuf so that we can specify syncobj handles as well as timeline points. v2: Reuse i915_user_extension_fn v3: Check that the chained extension is only present once (Chris) v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel) v5: Use BIT_ULL (Chris) v6: Fix issue with already signaled timeline points, dma_fence_chain_find_seqno() setting fence to NULL (Chris) v7: Report ENOENT with invalid syncobj handle (Lionel) v8: Check for out of order timeline point insertion (Chris) v9: After explanations on https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html drop the ordering check from v8 (Lionel) v10: Set first extension enum item to 1 (Jason) The other unaddressed issue here is that we do not need to arbitrarily limit the caller to only a single extension. The code to handle multiple invocations is actually smaller... -Chris You mean an application could send multiple DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES items in the chain of extensions? That's somewhat different than how the current fences are handled. If other extension want to support that, that's up to them. We don't have any use for multiple arrays of timeline fences for a given execbuf in our userspace driver. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
On 31/07/2020 17:30, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-07-31 14:45:52)
- drm_syncobj_replace_fence(syncobj, fence);
+ if (eb->fences[n].chain_fence) {
+ drm_syncobj_add_point(syncobj,
eb->fences[n].chain_fence,
+ fence, eb->fences[n].value);
This function remains not acceptable. It is trivial to write an igt test
that causes the DRM_ERROR. A user controllable error message is still
not allowed. If you do not have such a test in your igt series, then that
too is lacking.
-Chris
As far as I remember there are IGT tests for this (*unordered* subtests).
So CI should report a fairlure. The IGT test itself won't fail though.
I thought we removed that DRM_ERROR a while ago.
I'll send a patch to remove it. Thanks.
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes and improvements for Xen pvdrm
== Series Details == Series: Fixes and improvements for Xen pvdrm URL : https://patchwork.freedesktop.org/series/80141/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18285_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18285_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@madvise: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk4/igt@gem_exec_cre...@madvise.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-glk3/igt@gem_exec_cre...@madvise.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync@wb: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#2119]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-iclb5/igt@gem_userptr_blits@invalid-mmap-offset-uns...@wb.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-iclb8/igt@gem_userptr_blits@invalid-mmap-offset-uns...@wb.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#300]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@2x-plain-flip-fb-recreate@ab-vga1-hdmi-a1: - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-hsw6/igt@kms_flip@2x-plain-flip-fb-recre...@ab-vga1-hdmi-a1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-hsw8/igt@kms_flip@2x-plain-flip-fb-recre...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl8/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-skl8/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl2/igt@kms_flip@flip-vs-susp...@c-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-kbl3/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +9 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl4/igt@kms_flip_til...@flip-changes-tiling.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-skl7/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-1p-indfb-fliptrack: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl2/igt@kms_frontbuffer_track...@fbc-1p-indfb-fliptrack.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-kbl7/igt@kms_frontbuffer_track...@fbc-1p-indfb-fliptrack.html * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk7/igt@kms_frontbuffer_track...@fbc-badstride.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-glk8/igt@kms_frontbuffer_track...@fbc-badstride.html - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb2/igt@kms_frontbuffer_track...@fbc-badstride.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-tglb6/igt@kms_frontbuffer_track...@fbc-badstride.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl4/igt@kms_...@bpc-switch.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/shard-skl3/igt@kms_...@bpc-switch.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][25] -> [FAIL][26] ([fdo#108145] / [i915#265]) [25]:
Re: [Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
Quoting Tvrtko Ursulin (2020-07-31 17:06:08)
>
> On 31/07/2020 16:21, Chris Wilson wrote:
> > Quoting Chris Wilson (2020-07-31 16:12:32)
> >> Quoting Tvrtko Ursulin (2020-07-31 16:06:55)
> >>>
> >>> On 30/07/2020 10:37, Chris Wilson wrote:
> @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
> {
> struct intel_breadcrumbs *b = container_of(work, typeof(*b),
> irq_work);
> const ktime_t timestamp = ktime_get();
> + struct llist_node *signal, *sn;
> struct intel_context *ce, *cn;
> struct list_head *pos, *next;
> - LIST_HEAD(signal);
> +
> + signal = NULL;
> + if (unlikely(!llist_empty(>signaled_requests)))
> + signal = llist_del_all(>signaled_requests);
>
> spin_lock(>irq_lock);
>
> - if (list_empty(>signalers))
> + if (!signal && list_empty(>signalers))
> >>>
> >>> The only open from previous round was on this change. If I understood
> >>> your previous reply correctly, checking this or not simply controls the
> >>> disarm point and is not related to this patch. With the check added now
> >>> we would disarm later, because even already signaled requests would keep
> >>> it armed. I would prefer this was a separate patch if you could possibly
> >>> be convinced.
> >>
> >> I considered that since we add to the lockless list and then queue the
> >> irq work, that is a path that is not driven by the interrupt and so
> >> causing an issue with the idea of the interrupt shadow. Having a simple
> >> test I thought was a positive side-effect to filter out the early
> >> irq_work.
> >
> > How about a compromise and I sell the patch with a comment:
> > /*
> > * Keep the irq armed until the interrupt after all listeners are
> > gone.
> > *
> > * Enabling/disabling the interrupt is rather costly, roughly a
> > couple
> > * of hundred microseconds. If we are proactive and enable/disable
> > * the interrupt around every request that wants a breadcrumb, we
> > * quickly drown in the extra orders of magnitude of latency
> > imposed
> > * on request submission.
> > *
> > * So we try to be lazy, and keep the interrupts enabled until no
> > * more listeners appear within a breadcrumb interrupt interval
> > (that
> > * is until a request completes that no one cares about). The
> > * observation is that listeners come in batches, and will often
> > * listen to a bunch of requests in succession.
> > *
> > * We also try to avoid raising too many interrupts, as they may
> > * be generated by userspace batches and it is unfortunately rather
> > * too easy to drown the CPU under a flood of GPU interrupts. Thus
> > * whenever no one appears to be listening, we turn off the
> > interrupts.
> > * Fewer interrupts should conserve power -- at the very least,
> > fewer
> > * interrupt draw less ire from other users of the system and tools
> > * like powertop.
> >*/
>
> It really feels like it should be a separate patch.
>
> I am not sure at the moment how exactly the hysteresis this would apply
> would look like. The end point is driven by the requests on the signaled
> list, but that is also driven by the timing of listeners adding
> themselves versus the request completion. For instance maybe if we want
> a hysteresis we won't something more deterministic and explicit. Maybe
> tied directly to the user interrupt following no more listeners. Like
> simply disarm on the second irq work after all b->signalers have gone. I
> just can't picture the state or b->signaled_requests in relation to all
> dynamic actions.
Which is kind of the point. b->signaled_requests doesn't have a
relationship with the interrupt delivery. So we are changing the
behaviour by kicking the irq_work after adding to b->signaled_requests
independently of the interrupts, hence why we shouldn't be making that
change incidently in the patch.
It is about conserving existing behaviour.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake
== Series Details == Series: series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake URL : https://patchwork.freedesktop.org/series/80139/ State : success == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18284_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_18284_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18284_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_18284_full: ### IGT changes ### Warnings * igt@gem_exec_reloc@basic-concurrent16: - shard-hsw: [TIMEOUT][1] ([i915#1958] / [i915#2119]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-hsw7/igt@gem_exec_re...@basic-concurrent16.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-hsw2/igt@gem_exec_re...@basic-concurrent16.html Known issues Here are the changes found in Patchwork_18284_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#198]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl9/igt@gem_ctx_isolation@preservation...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-skl4/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_eio@in-flight-contexts-10ms: - shard-hsw: [PASS][5] -> [TIMEOUT][6] ([i915#1958] / [i915#1976] / [i915#2119]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-hsw1/igt@gem_...@in-flight-contexts-10ms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-hsw4/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#1930]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-glk8/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-fds: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk8/igt@gem_exec_whis...@basic-fds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-glk4/igt@gem_exec_whis...@basic-fds.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb5/igt@gem_huc_c...@huc-copy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-iclb3/igt@i915_pm...@dc6-psr.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk1/igt@kms_big...@x-tiled-64bpp-rotate-0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-random: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-apl7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/shard-apl1/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html *
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3)
== Series Details == Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3) URL : https://patchwork.freedesktop.org/series/80045/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8822_full -> Patchwork_18283_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18283_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18283_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_18283_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb1/igt@gem_exec_whis...@basic-contexts-forked-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-tglb3/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_partial_pwrite_pread@reads-display: - shard-glk: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk2/igt@gem_partial_pwrite_pr...@reads-display.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-glk6/igt@gem_partial_pwrite_pr...@reads-display.html * igt@runner@aborted: - shard-tglb: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-tglb3/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18283_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_endless@dispatch@rcs0: - shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([i915#1958] / [i915#2119]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb8/igt@gem_exec_endless@dispa...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-tglb8/igt@gem_exec_endless@dispa...@rcs0.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#1930]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-glk5/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-normal: - shard-glk: [PASS][10] -> [DMESG-WARN][11] ([i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-glk7/igt@gem_exec_whis...@basic-normal.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-glk1/igt@gem_exec_whis...@basic-normal.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-tglb: [PASS][12] -> [INCOMPLETE][13] ([i915#456] / [i915#750]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-tglb6/igt@i915_pm_...@system-suspend-execbuf.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-tglb6/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-iclb: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-iclb8/igt@kms_big...@linear-64bpp-rotate-180.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-iclb3/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#1635] / [i915#1982]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-apl7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-apl7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-wc-ytiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1: - shard-skl: [PASS][20] -> [FAIL][21] ([i915#79]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1: - shard-glk:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : success == Summary == CI Bug Log - changes from CI_DRM_8823 -> Patchwork_18289 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/index.html Known issues Here are the changes found in Patchwork_18289 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_module_load@reload: - fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-bsw-n3050/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-bsw-n3050/igt@i915_module_l...@reload.html * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [PASS][5] -> [INCOMPLETE][6] ([i915#2089]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-icl-y: [PASS][7] -> [DMESG-FAIL][8] ([i915#2111]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-icl-y/igt@i915_selftest@live@gt_pm.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-icl-y/igt@i915_selftest@live@gt_pm.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Possible fixes * igt@i915_module_load@reload: - fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-bsw-kefka/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-bsw-kefka/igt@i915_module_l...@reload.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [DMESG-WARN][15] ([i915#2203]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html Warnings * igt@kms_force_connector_basic@prune-stale-modes: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8823/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18289/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089 [i915#2111]: https://gitlab.freedesktop.org/drm/intel/issues/2111 [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (43 -> 36) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs URL : https://patchwork.freedesktop.org/series/80150/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Remove requirement for holding
i915_request.lock for breadcrumbs
URL : https://patchwork.freedesktop.org/series/80150/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8bec68a2d4fc drm/i915: Remove requirement for holding i915_request.lock for
breadcrumbs
1c838e1ab0e5 drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs
56cf2c2ab202 drm/i915/gt: Only transfer the virtual context to the new engine
if active
-:28: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#28:
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
-:28: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6d06779e8672 ("drm/i915: Load
balancing across a virtual engine")'
#28:
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
total: 1 errors, 1 warnings, 0 checks, 81 lines checked
b955f79361d3 drm/i915/gt: Distinguish the virtual breadcrumbs from the irq
breadcrumbs
-:214: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#214:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 513 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
On 31/07/2020 16:21, Chris Wilson wrote:
Quoting Chris Wilson (2020-07-31 16:12:32)
Quoting Tvrtko Ursulin (2020-07-31 16:06:55)
On 30/07/2020 10:37, Chris Wilson wrote:
@@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+ struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- LIST_HEAD(signal);
+
+ signal = NULL;
+ if (unlikely(!llist_empty(>signaled_requests)))
+ signal = llist_del_all(>signaled_requests);
spin_lock(>irq_lock);
- if (list_empty(>signalers))
+ if (!signal && list_empty(>signalers))
The only open from previous round was on this change. If I understood
your previous reply correctly, checking this or not simply controls the
disarm point and is not related to this patch. With the check added now
we would disarm later, because even already signaled requests would keep
it armed. I would prefer this was a separate patch if you could possibly
be convinced.
I considered that since we add to the lockless list and then queue the
irq work, that is a path that is not driven by the interrupt and so
causing an issue with the idea of the interrupt shadow. Having a simple
test I thought was a positive side-effect to filter out the early
irq_work.
How about a compromise and I sell the patch with a comment:
/*
* Keep the irq armed until the interrupt after all listeners are gone.
*
* Enabling/disabling the interrupt is rather costly, roughly a couple
* of hundred microseconds. If we are proactive and enable/disable
* the interrupt around every request that wants a breadcrumb, we
* quickly drown in the extra orders of magnitude of latency imposed
* on request submission.
*
* So we try to be lazy, and keep the interrupts enabled until no
* more listeners appear within a breadcrumb interrupt interval (that
* is until a request completes that no one cares about). The
* observation is that listeners come in batches, and will often
* listen to a bunch of requests in succession.
*
* We also try to avoid raising too many interrupts, as they may
* be generated by userspace batches and it is unfortunately rather
* too easy to drown the CPU under a flood of GPU interrupts. Thus
* whenever no one appears to be listening, we turn off the interrupts.
* Fewer interrupts should conserve power -- at the very least, fewer
* interrupt draw less ire from other users of the system and tools
* like powertop.
*/
It really feels like it should be a separate patch.
I am not sure at the moment how exactly the hysteresis this would apply
would look like. The end point is driven by the requests on the signaled
list, but that is also driven by the timing of listeners adding
themselves versus the request completion. For instance maybe if we want
a hysteresis we won't something more deterministic and explicit. Maybe
tied directly to the user interrupt following no more listeners. Like
simply disarm on the second irq work after all b->signalers have gone. I
just can't picture the state or b->signaled_requests in relation to all
dynamic actions.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs
On the virtual engines, we only use the intel_breadcrumbs for tracking
signaling of stale breadcrumbs from the irq_workers. They do not have
any associated interrupt handling, active requests are passed to a
physical engine and associated breadcrumb interrupt handler. This causes
issues for us as we need to ensure that we do not actually try and
enable interrupts and the powermanagement required for them on the
virtual engine, as they will never be disabled. Instead, let's
specify the physical engine used for interrupt handler on a particular
breadcrumb.
v2: Drop b->irq_armed = true mocking for no interrupt HW
Fixes: 4fe6abb8f513 ("drm/i915/gt: Ignore irq enabling on the virtual engines")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 76 ++-
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 36 +
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 47
drivers/gpu/drm/i915/gt/intel_engine.h| 17 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 31 +---
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_reset.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 1 +
drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++-
drivers/gpu/drm/i915/i915_irq.c | 1 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/i915_request.h | 4 -
16 files changed, 162 insertions(+), 95 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fbdc465a5870..2ffd47a86656 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -28,6 +28,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
+#include "intel_breadcrumbs.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -55,30 +56,28 @@ static void irq_disable(struct intel_engine_cs *engine)
static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(>irq_lock);
+ if (!b->irq_engine || !b->irq_armed)
+ return;
+
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
- irq_disable(engine);
+ irq_disable(b->irq_engine);
WRITE_ONCE(b->irq_armed, false);
- intel_gt_pm_put_async(engine->gt);
+ intel_gt_pm_put_async(b->irq_engine->gt);
}
-void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
+void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
{
- struct intel_breadcrumbs *b = >breadcrumbs;
unsigned long flags;
if (!READ_ONCE(b->irq_armed))
return;
spin_lock_irqsave(>irq_lock, flags);
- if (b->irq_armed)
- __intel_breadcrumbs_disarm_irq(b);
+ __intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(>irq_lock, flags);
}
@@ -133,13 +132,8 @@ __dma_fence_signal__notify(struct dma_fence *fence,
static void add_retire(struct intel_breadcrumbs *b, struct intel_timeline *tl)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
- if (unlikely(intel_engine_is_virtual(engine)))
- engine = intel_virtual_engine_get_sibling(engine, 0);
-
- intel_engine_add_retire(engine, tl);
+ if (b->irq_engine)
+ intel_engine_add_retire(b->irq_engine, tl);
}
static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
@@ -164,7 +158,7 @@ static void signal_irq_work(struct irq_work *work)
spin_lock(>irq_lock);
- if (b->irq_armed && list_empty(>signalers))
+ if (list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
list_splice_init(>signaled_requests, );
@@ -222,14 +216,12 @@ static void signal_irq_work(struct irq_work *work)
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(>irq_lock);
- if (b->irq_armed)
+
+ if (!b->irq_engine || b->irq_armed)
return;
- if (!intel_gt_pm_get_if_awake(engine->gt))
+ if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
return;
/*
@@ -249,37 +241,49 @@ static void __intel_breadcrumbs_arm_irq(struct
[Intel-gfx] [CI 1/4] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
Since the breadcrumb enabling/cancelling itself is serialised by the
breadcrumbs.irq_lock, with a bit of care we can remove the outer
serialisation with i915_request.lock for concurrent
dma_fence_enable_signaling(). This has the important side-effect of
eliminating the nested i915_request.lock within request submission.
The challenge in serialisation is around the unsubmission where we take
an active request that wants a breadcrumb on the signaling engine and
put it to sleep. We do not want a concurrent
dma_fence_enable_signaling() to attach a breadcrumb as we unsubmit, so
we must mark the request as no longer active before serialising with the
concurrent enable-signaling.
On retire, we serialise with the concurrent enable-signaling, but
instead of clearing ACTIVE, we mark it as SIGNALED.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 130 +---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ---
drivers/gpu/drm/i915/i915_request.c | 39 +++---
3 files changed, 100 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 91786310c114..3d211a0c2b5a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -220,17 +220,17 @@ static void signal_irq_work(struct irq_work *work)
}
}
-static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
+static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
struct intel_engine_cs *engine =
container_of(b, struct intel_engine_cs, breadcrumbs);
lockdep_assert_held(>irq_lock);
if (b->irq_armed)
- return true;
+ return;
if (!intel_gt_pm_get_if_awake(engine->gt))
- return false;
+ return;
/*
* The breadcrumb irq will be disarmed on the interrupt after the
@@ -250,8 +250,6 @@ static bool __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
if (!b->irq_enabled++)
irq_enable(engine);
-
- return true;
}
void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine)
@@ -310,57 +308,99 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
}
-bool i915_request_enable_breadcrumb(struct i915_request *rq)
+static void insert_breadcrumb(struct i915_request *rq,
+ struct intel_breadcrumbs *b)
{
- lockdep_assert_held(>lock);
+ struct intel_context *ce = rq->context;
+ struct list_head *pos;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
- return true;
+ if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
+ return;
- if (test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
- struct intel_breadcrumbs *b = >engine->breadcrumbs;
- struct intel_context *ce = rq->context;
- struct list_head *pos;
+ __intel_breadcrumbs_arm_irq(b);
- spin_lock(>irq_lock);
+ /*
+* We keep the seqno in retirement order, so we can break
+* inside intel_engine_signal_breadcrumbs as soon as we've
+* passed the last completed request (or seen a request that
+* hasn't event started). We could walk the timeline->requests,
+* but keeping a separate signalers_list has the advantage of
+* hopefully being much smaller than the full list and so
+* provides faster iteration and detection when there are no
+* more interrupts required for this context.
+*
+* We typically expect to add new signalers in order, so we
+* start looking for our insertion point from the tail of
+* the list.
+*/
+ list_for_each_prev(pos, >signals) {
+ struct i915_request *it =
+ list_entry(pos, typeof(*it), signal_link);
- if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
- goto unlock;
+ if (i915_seqno_passed(rq->fence.seqno, it->fence.seqno))
+ break;
+ }
+ list_add(>signal_link, pos);
+ if (pos == >signals) /* catch transitions from empty list */
+ list_move_tail(>signal_link, >signalers);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
- if (!__intel_breadcrumbs_arm_irq(b))
- goto unlock;
+ set_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+}
- /*
-* We keep the seqno in retirement order, so we can break
-* inside intel_engine_signal_breadcrumbs as soon as we've
-* passed the last completed request (or seen a request that
-* hasn't event started). We could walk the timeline->requests,
-* but keeping a separate
[Intel-gfx] [CI 3/4] drm/i915/gt: Only transfer the virtual context to the new engine if active
One more complication of preempt-to-busy with respect to the virtual
engine is that we may have retired the last request along the virtual
engine at the same time as preparing to submit the completed request to
a new engine. That submit will be shortcircuited, but not before we have
updated the context with the new register offsets and marked the virtual
engine as bound to the new engine (by calling swap on ve->siblings[]).
As we may have just retired the completed request, we may also be in the
middle of calling virtual_context_exit() to turn off the power management
associated with the virtual engine, and that in turn walks the
ve->siblings[]. If we happen to call swap() on the array as we walk, we
will call intel_engine_pm_put() twice on the same engine.
In this patch, we prevent this by only updating the bound engine after a
successful submission which weeds out the already completed requests.
Alternatively, we could walk a non-volatile array for the pm, such as
using the engine->mask. The small advantage to performing the update
after the submit is that we then only have to do a swap for active
requests.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: "Nayana, Venkata Ramana"
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 65 ++---
1 file changed, 40 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 94c0942934ff..f1267fa95234 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1805,6 +1805,33 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static void virtual_xfer_context(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
+{
+ unsigned int n;
+
+ if (likely(engine == ve->siblings[0]))
+ return;
+
+ GEM_BUG_ON(READ_ONCE(ve->context.inflight));
+ if (!intel_engine_has_relative_mmio(engine))
+ virtual_update_register_offsets(ve->context.lrc_reg_state,
+ engine);
+
+ /*
+* Move the bound engine to the top of the list for
+* future execution. We then kick this tasklet first
+* before checking others, so that we preferentially
+* reuse this set of bound registers.
+*/
+ for (n = 1; n < ve->num_siblings; n++) {
+ if (ve->siblings[n] == engine) {
+ swap(ve->siblings[n], ve->siblings[0]);
+ break;
+ }
+ }
+}
+
#define for_each_waiter(p__, rq__) \
list_for_each_entry_lockless(p__, \
&(rq__)->sched.waiters_list, \
@@ -2253,35 +2280,23 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
GEM_BUG_ON(!(rq->execution_mask & engine->mask));
WRITE_ONCE(rq->engine, engine);
- if (engine != ve->siblings[0]) {
- u32 *regs = ve->context.lrc_reg_state;
- unsigned int n;
-
- GEM_BUG_ON(READ_ONCE(ve->context.inflight));
-
- if (!intel_engine_has_relative_mmio(engine))
- virtual_update_register_offsets(regs,
- engine);
-
+ if (__i915_request_submit(rq)) {
/*
-* Move the bound engine to the top of the list
-* for future execution. We then kick this
-* tasklet first before checking others, so that
-* we preferentially reuse this set of bound
-* registers.
+* Only after we confirm that we will submit
+* this request (i.e. it has not already
+* completed), do we want to update the context.
+*
+* This serves two purposes. It avoids
+* unnecessary work if we are resubmitting an
+* already completed request after timeslicing.
+* But more importantly, it prevents us altering
+* ve->siblings[] on an idle context, where
+* we may be using ve->siblings[] in
+* virtual_context_enter / virtual_context_exit.
*/
- for (n = 1; n < ve->num_siblings; n++) {
-
[Intel-gfx] [CI 2/4] drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs
After staring at the breadcrumb enabling/cancellation and coming to the
conclusion that the cause of the mysterious stale breadcrumbs must the
act of submitting a completed requests, we can then redirect those
completed requests onto a dedicated signaled_list at the time of
construction and so eliminate intel_engine_transfer_stale_breadcrumbs().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 50 -
drivers/gpu/drm/i915/gt/intel_engine.h | 3 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
drivers/gpu/drm/i915/i915_request.c | 5 +--
4 files changed, 21 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 3d211a0c2b5a..fbdc465a5870 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -142,16 +142,16 @@ static void add_retire(struct intel_breadcrumbs *b,
struct intel_timeline *tl)
intel_engine_add_retire(engine, tl);
}
-static void __signal_request(struct i915_request *rq, struct list_head
*signals)
+static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
{
- GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags));
clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
if (!__dma_fence_signal(>fence))
- return;
+ return false;
i915_request_get(rq);
list_add_tail(>signal_link, signals);
+ return true;
}
static void signal_irq_work(struct irq_work *work)
@@ -278,32 +278,6 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
spin_unlock_irqrestore(>irq_lock, flags);
}
-void intel_engine_transfer_stale_breadcrumbs(struct intel_engine_cs *engine,
-struct intel_context *ce)
-{
- struct intel_breadcrumbs *b = >breadcrumbs;
- unsigned long flags;
-
- spin_lock_irqsave(>irq_lock, flags);
- if (!list_empty(>signals)) {
- struct i915_request *rq, *next;
-
- /* Queue for executing the signal callbacks in the irq_work */
- list_for_each_entry_safe(rq, next, >signals, signal_link) {
- GEM_BUG_ON(rq->engine != engine);
- GEM_BUG_ON(!__request_completed(rq));
-
- __signal_request(rq, >signaled_requests);
- }
-
- INIT_LIST_HEAD(>signals);
- list_del_init(>signal_link);
-
- irq_work_queue(>irq_work);
- }
- spin_unlock_irqrestore(>irq_lock, flags);
-}
-
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
{
}
@@ -317,6 +291,17 @@ static void insert_breadcrumb(struct i915_request *rq,
if (test_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
+ /*
+* If the request is already completed, we can transfer it
+* straight onto a signaled list, and queue the irq worker for
+* its signal completion.
+*/
+ if (__request_completed(rq)) {
+ if (__signal_request(rq, >signaled_requests))
+ irq_work_queue(>irq_work);
+ return;
+ }
+
__intel_breadcrumbs_arm_irq(b);
/*
@@ -344,8 +329,11 @@ static void insert_breadcrumb(struct i915_request *rq,
if (pos == >signals) /* catch transitions from empty list */
list_move_tail(>signal_link, >signalers);
GEM_BUG_ON(!check_signal_order(ce, rq));
-
set_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+
+ /* Check after attaching to irq, interrupt may have already fired. */
+ if (__request_completed(rq))
+ irq_work_queue(>irq_work);
}
bool i915_request_enable_breadcrumb(struct i915_request *rq)
@@ -401,7 +389,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
spin_unlock(>irq_lock);
- return !__request_completed(rq);
+ return true;
}
void i915_request_cancel_breadcrumb(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index a9249a23903a..faf00a353e25 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -237,9 +237,6 @@ intel_engine_signal_breadcrumbs(struct intel_engine_cs
*engine)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-void intel_engine_transfer_stale_breadcrumbs(struct intel_engine_cs *engine,
-struct intel_context *ce);
-
void intel_engine_print_breadcrumbs(struct intel_engine_cs *engine,
struct drm_printer *p);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
Re: [Intel-gfx] [PATCH 17/21] drm/i915/gt: Protect context lifetime with RCU
On 31/07/2020 16:24, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-07-31 16:15:43) On 30/07/2020 10:37, Chris Wilson wrote: Allow a brief period for continued access to a dead intel_context by deferring the release of the struct until after an RCU grace period. As we are using a dedicated slab cache for the contexts, we can defer the release of the slab pages via RCU, with the caveat that individual structs may be reused from the freelist within an RCU grace period. To handle that, we have to avoid clearing members of the zombie struct. What was the motivation? I wanted a window where the pointer was kept alive by RCU after we called intel_context_put() so I could keep using spinlock for a bit. If you look closely, you might spot that isn't used any more, but I liked the ctor so kept it around. In this case I think it is better to avoid changes which can introduce potential bugs. (And added bonus time saved on review. :) Regards, Tvrtko ___ 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/selftests: Drop stale timeline constructor assert
== Series Details == Series: drm/i915/selftests: Drop stale timeline constructor assert URL : https://patchwork.freedesktop.org/series/80138/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8821_full -> Patchwork_18282_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18282_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18282_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_18282_full: ### IGT changes ### Possible regressions * igt@kms_flip@busy-flip@b-edp1: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-tglb6/igt@kms_flip@busy-f...@b-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-tglb8/igt@kms_flip@busy-f...@b-edp1.html Known issues Here are the changes found in Patchwork_18282_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][3] -> [SKIP][4] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-tglb2/igt@gem_huc_c...@huc-copy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_softpin@invalid: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +19 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl8/igt@gem_soft...@invalid.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-skl5/igt@gem_soft...@invalid.html * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#72]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-glk2/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-glk1/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#52] / [i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-ytiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-skl6/igt@kms_draw_...@draw-method-xrgb-mmap-wc-ytiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-suspend@b-vga1: - shard-snb: [PASS][13] -> [INCOMPLETE][14] ([i915#82]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-snb4/igt@kms_flip@flip-vs-susp...@b-vga1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-snb1/igt@kms_flip@flip-vs-susp...@b-vga1.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-blt.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl2/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-skl2/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html Possible fixes *
Re: [Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
On 31/07/2020 16:12, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-31 16:06:55)
On 30/07/2020 10:37, Chris Wilson wrote:
@@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+ struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- LIST_HEAD(signal);
+
+ signal = NULL;
+ if (unlikely(!llist_empty(>signaled_requests)))
+ signal = llist_del_all(>signaled_requests);
spin_lock(>irq_lock);
- if (list_empty(>signalers))
+ if (!signal && list_empty(>signalers))
The only open from previous round was on this change. If I understood
your previous reply correctly, checking this or not simply controls the
disarm point and is not related to this patch. With the check added now
we would disarm later, because even already signaled requests would keep
it armed. I would prefer this was a separate patch if you could possibly
be convinced.
I considered that since we add to the lockless list and then queue the
irq work, that is a path that is not driven by the interrupt and so
causing an issue with the idea of the interrupt shadow. Having a simple
test I thought was a positive side-effect to filter out the early
irq_work.
I don't really follow. I look at it like this: No active signalers so we
can disarm. What is the purpose of keeping the interrupt enabled if all
that is on list are already completed requests? They will get signaled
in the very same run of signal_irq_work so I don't see a connection with
lockless list and keeping the interrupts on for longer.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/21] drm/i915/gt: Protect context lifetime with RCU
Quoting Tvrtko Ursulin (2020-07-31 16:15:43) > > On 30/07/2020 10:37, Chris Wilson wrote: > > Allow a brief period for continued access to a dead intel_context by > > deferring the release of the struct until after an RCU grace period. > > As we are using a dedicated slab cache for the contexts, we can defer > > the release of the slab pages via RCU, with the caveat that individual > > structs may be reused from the freelist within an RCU grace period. To > > handle that, we have to avoid clearing members of the zombie struct. > > What was the motivation? I wanted a window where the pointer was kept alive by RCU after we called intel_context_put() so I could keep using spinlock for a bit. If you look closely, you might spot that isn't used any more, but I liked the ctor so kept it around. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Allow privileged user to map the OA buffer
== Series Details ==
Series: Allow privileged user to map the OA buffer
URL : https://patchwork.freedesktop.org/series/80148/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18288
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/index.html
Known issues
Here are the changes found in Patchwork_18288 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@i915_module_load@reload:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][13] ([i915#1233]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][19] ([i915#2203]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Warnings
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18288/fi-kbl-x1275/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:
Re: [Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
Quoting Chris Wilson (2020-07-31 16:12:32)
> Quoting Tvrtko Ursulin (2020-07-31 16:06:55)
> >
> > On 30/07/2020 10:37, Chris Wilson wrote:
> > > @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
> > > {
> > > struct intel_breadcrumbs *b = container_of(work, typeof(*b),
> > > irq_work);
> > > const ktime_t timestamp = ktime_get();
> > > + struct llist_node *signal, *sn;
> > > struct intel_context *ce, *cn;
> > > struct list_head *pos, *next;
> > > - LIST_HEAD(signal);
> > > +
> > > + signal = NULL;
> > > + if (unlikely(!llist_empty(>signaled_requests)))
> > > + signal = llist_del_all(>signaled_requests);
> > >
> > > spin_lock(>irq_lock);
> > >
> > > - if (list_empty(>signalers))
> > > + if (!signal && list_empty(>signalers))
> >
> > The only open from previous round was on this change. If I understood
> > your previous reply correctly, checking this or not simply controls the
> > disarm point and is not related to this patch. With the check added now
> > we would disarm later, because even already signaled requests would keep
> > it armed. I would prefer this was a separate patch if you could possibly
> > be convinced.
>
> I considered that since we add to the lockless list and then queue the
> irq work, that is a path that is not driven by the interrupt and so
> causing an issue with the idea of the interrupt shadow. Having a simple
> test I thought was a positive side-effect to filter out the early
> irq_work.
How about a compromise and I sell the patch with a comment:
/*
* Keep the irq armed until the interrupt after all listeners are gone.
*
* Enabling/disabling the interrupt is rather costly, roughly a couple
* of hundred microseconds. If we are proactive and enable/disable
* the interrupt around every request that wants a breadcrumb, we
* quickly drown in the extra orders of magnitude of latency imposed
* on request submission.
*
* So we try to be lazy, and keep the interrupts enabled until no
* more listeners appear within a breadcrumb interrupt interval (that
* is until a request completes that no one cares about). The
* observation is that listeners come in batches, and will often
* listen to a bunch of requests in succession.
*
* We also try to avoid raising too many interrupts, as they may
* be generated by userspace batches and it is unfortunately rather
* too easy to drown the CPU under a flood of GPU interrupts. Thus
* whenever no one appears to be listening, we turn off the interrupts.
* Fewer interrupts should conserve power -- at the very least, fewer
* interrupt draw less ire from other users of the system and tools
* like powertop.
*/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/21] drm/i915/gt: Protect context lifetime with RCU
On 30/07/2020 10:37, Chris Wilson wrote:
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.
What was the motivation?
Regards,
Tvrtko
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 330 +---
drivers/gpu/drm/i915/i915_active.c | 10 +
drivers/gpu/drm/i915/i915_active.h | 2 +
drivers/gpu/drm/i915/i915_utils.h | 7 +
4 files changed, 202 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 52db2bde44a3..4e7924640ffa 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -22,7 +22,7 @@ static struct i915_global_context {
static struct intel_context *intel_context_alloc(void)
{
- return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+ return kmem_cache_alloc(global.slab_ce, GFP_KERNEL);
}
void intel_context_free(struct intel_context *ce)
@@ -30,6 +30,177 @@ void intel_context_free(struct intel_context *ce)
kmem_cache_free(global.slab_ce, ce);
}
+static int __context_pin_state(struct i915_vma *vma)
+{
+ unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
+ int err;
+
+ err = i915_ggtt_pin(vma, 0, bias | PIN_HIGH);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>active);
+ if (err)
+ goto err_unpin;
+
+ /*
+* And mark it as a globally pinned object to let the shrinker know
+* it cannot reclaim the object until we release it.
+*/
+ i915_vma_make_unshrinkable(vma);
+ vma->obj->mm.dirty = true;
+
+ return 0;
+
+err_unpin:
+ i915_vma_unpin(vma);
+ return err;
+}
+
+static void __context_unpin_state(struct i915_vma *vma)
+{
+ i915_vma_make_shrinkable(vma);
+ i915_active_release(>active);
+ __i915_vma_unpin(vma);
+}
+
+static int __ring_active(struct intel_ring *ring)
+{
+ int err;
+
+ err = intel_ring_pin(ring);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>vma->active);
+ if (err)
+ goto err_pin;
+
+ return 0;
+
+err_pin:
+ intel_ring_unpin(ring);
+ return err;
+}
+
+static void __ring_retire(struct intel_ring *ring)
+{
+ i915_active_release(>vma->active);
+ intel_ring_unpin(ring);
+}
+
+__i915_active_call
+static void __intel_context_retire(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+
+ CE_TRACE(ce, "retire runtime: { total:%lluns, avg:%lluns }\n",
+intel_context_get_total_runtime_ns(ce),
+intel_context_get_avg_runtime_ns(ce));
+
+ set_bit(CONTEXT_VALID_BIT, >flags);
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+
+ intel_context_put(ce);
+}
+
+static int __intel_context_active(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ intel_context_get(ce);
+
+ err = __ring_active(ce->ring);
+ if (err)
+ goto err_put;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+err_put:
+ intel_context_put(ce);
+ return err;
+}
+
+static void __intel_context_ctor(void *arg)
+{
+ struct intel_context *ce = arg;
+
+ INIT_LIST_HEAD(>signal_link);
+ INIT_LIST_HEAD(>signals);
+
+ atomic_set(>pin_count, 0);
+ mutex_init(>pin_mutex);
+
+ ce->active_count = 0;
+ i915_active_init(>active,
+__intel_context_active, __intel_context_retire);
+
+ ce->inflight = NULL;
+ ce->lrc_reg_state = NULL;
+ ce->lrc.desc = 0;
+}
+
+static void
+__intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
+{
+ GEM_BUG_ON(!engine->cops);
+ GEM_BUG_ON(!engine->gt->vm);
+
+ kref_init(>ref);
+ i915_active_reinit(>active);
+ mutex_reinit(>pin_mutex);
+
+ ce->engine = engine;
+ ce->ops = engine->cops;
+ ce->sseu = engine->sseu;
+
+ ce->wa_bb_page = 0;
+
Re: [Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
Quoting Tvrtko Ursulin (2020-07-31 16:06:55)
>
> On 30/07/2020 10:37, Chris Wilson wrote:
> > @@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
> > {
> > struct intel_breadcrumbs *b = container_of(work, typeof(*b),
> > irq_work);
> > const ktime_t timestamp = ktime_get();
> > + struct llist_node *signal, *sn;
> > struct intel_context *ce, *cn;
> > struct list_head *pos, *next;
> > - LIST_HEAD(signal);
> > +
> > + signal = NULL;
> > + if (unlikely(!llist_empty(>signaled_requests)))
> > + signal = llist_del_all(>signaled_requests);
> >
> > spin_lock(>irq_lock);
> >
> > - if (list_empty(>signalers))
> > + if (!signal && list_empty(>signalers))
>
> The only open from previous round was on this change. If I understood
> your previous reply correctly, checking this or not simply controls the
> disarm point and is not related to this patch. With the check added now
> we would disarm later, because even already signaled requests would keep
> it armed. I would prefer this was a separate patch if you could possibly
> be convinced.
I considered that since we add to the lockless list and then queue the
irq work, that is a path that is not driven by the interrupt and so
causing an issue with the idea of the interrupt shadow. Having a simple
test I thought was a positive side-effect to filter out the early
irq_work.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_perf.c:3281: warning: Function parameter or member 'cmd' not described in 'i915_perf_oa_buffer_info_locked' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/21] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
On 30/07/2020 10:37, Chris Wilson wrote:
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 30 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h | 6 +++-
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fc6f0223d2c8..6a278bf0fc6b 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -174,16 +174,13 @@ static void add_retire(struct intel_breadcrumbs *b,
struct intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
}
-static bool __signal_request(struct i915_request *rq, struct list_head *signals)
+static bool __signal_request(struct i915_request *rq)
{
- clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
-
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
- list_add_tail(>signal_link, signals);
return true;
}
@@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+ struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- LIST_HEAD(signal);
+
+ signal = NULL;
+ if (unlikely(!llist_empty(>signaled_requests)))
+ signal = llist_del_all(>signaled_requests);
spin_lock(>irq_lock);
- if (list_empty(>signalers))
+ if (!signal && list_empty(>signalers))
The only open from previous round was on this change. If I understood
your previous reply correctly, checking this or not simply controls the
disarm point and is not related to this patch. With the check added now
we would disarm later, because even already signaled requests would keep
it armed. I would prefer this was a separate patch if you could possibly
be convinced.
Regards,
Tvrtko
__intel_breadcrumbs_disarm_irq(b);
- list_splice_init(>signaled_requests, );
-
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
GEM_BUG_ON(list_empty(>signals));
@@ -218,7 +217,11 @@ static void signal_irq_work(struct irq_work *work)
* spinlock as the callback chain may end up adding
* more signalers to the same context or engine.
*/
- __signal_request(rq, );
+ clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+ if (__signal_request(rq)) {
+ rq->signal_node.next = signal;
+ signal = >signal_node;
+ }
}
/*
@@ -238,9 +241,9 @@ static void signal_irq_work(struct irq_work *work)
spin_unlock(>irq_lock);
- list_for_each_safe(pos, next, ) {
+ llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
- list_entry(pos, typeof(*rq), signal_link);
+ llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
spin_lock(>lock);
@@ -264,7 +267,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
spin_lock_init(>irq_lock);
INIT_LIST_HEAD(>signalers);
- INIT_LIST_HEAD(>signaled_requests);
+ init_llist_head(>signaled_requests);
init_irq_work(>irq_work, signal_irq_work);
@@ -327,7 +330,8 @@ static void insert_breadcrumb(struct i915_request *rq,
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq, >signaled_requests))
+ if (__signal_request(rq) &&
+ llist_add(>signal_node, >signaled_requests))
irq_work_queue(>irq_work);
return;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index 8e53b9942695..3fa19820b37a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,7 +35,7 @@ struct intel_breadcrumbs {
struct intel_engine_cs *irq_engine;
struct list_head signalers;
- struct list_head signaled_requests;
+ struct llist_head signaled_requests;
struct irq_work irq_work; /* for use from inside irq_lock */
diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h
index 16b721080195..874af6db6103 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -176,7 +176,11 @@ struct i915_request {
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Allow privileged user to map the OA buffer
== Series Details == Series: Allow privileged user to map the OA buffer URL : https://patchwork.freedesktop.org/series/80148/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5b0cda02e636 drm/i915/perf: Ensure observation logic is not clock gated c203e309db25 drm/i915/perf: Whitelist OA report trigger registers d6cb11d40b08 drm/i915/perf: Whitelist OA counter and buffer registers e7339aa045d6 drm/i915/perf: Map OA buffer to user space for gen12 performance query -:142: ERROR:CODE_INDENT: code indent should use tabs where possible #142: FILE: drivers/gpu/drm/i915/i915_perf.c:3278: +^I^I^I^I ^I unsigned int cmd,$ -:142: WARNING:SPACE_BEFORE_TAB: please, no space before tabs #142: FILE: drivers/gpu/drm/i915/i915_perf.c:3278: +^I^I^I^I ^I unsigned int cmd,$ -:142: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #142: FILE: drivers/gpu/drm/i915/i915_perf.c:3278: +static int i915_perf_oa_buffer_info_locked(struct i915_perf_stream *stream, + unsigned int cmd, -:323: ERROR:TRAILING_WHITESPACE: trailing whitespace #323: FILE: include/uapi/drm/i915_drm.h:2070: + * read-only mmapping is allowed. $ -:326: ERROR:TRAILING_WHITESPACE: trailing whitespace #326: FILE: include/uapi/drm/i915_drm.h:2073: + * format as specified by user config. The buffer provides reports that have $ total: 3 errors, 1 warnings, 1 checks, 225 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool
== Series Details ==
Series: drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT
pool
URL : https://patchwork.freedesktop.org/series/80147/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18287
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/index.html
Known issues
Here are the changes found in Patchwork_18287 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][1] ([i915#1888]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-bsw-kefka: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][7] ([i915#2203]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 36)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8822 -> Patchwork_18287
CI-20190529: 20190529
CI_DRM_8822: 26bcf5c3ceadd2c69181a320c4363f58ae34be46 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5755: e9ef5db4cd286fb4bf151a24efcd7a62a4df18f1 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18287: db6b41901a6923a26df21b6f42dea8341a084e64 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
db6b41901a69 drm/i915/gt: Decouple obj<->fence reference cycles on freeing the
GT pool
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18287/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query
Quoting Umesh Nerlige Ramappa (2020-07-31 15:46:43)
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
> implementation for query, but Gen12+ requires a new approach for query
> based on triggered reports within oa buffer.
>
> Triggering reports into the OA buffer is achieved by writing into a
> a trigger register. Optionally an unused counter/register is set with a
> marker value such that a triggered report can be identified in the OA
> buffer. Reports are usually triggered at the start and end of work that
> is measured.
>
> Since OA buffer is large and queries can be frequent, an efficient way
> to look for triggered reports is required. By knowing the current head
> and tail offsets into the OA buffer, it is easier to determine the
> locality of the reports of interest.
>
> Current perf OA interface does not expose head/tail information to the
> user and it filters out invalid reports before sending data to user.
> Also considering limited size of user buffer used during a query,
> creating a 1:1 copy of the OA buffer at the user space added undesired
> complexity.
>
> The solution was to map the OA buffer to user space provided
>
> (1) that it is accessed from a privileged user.
> (2) OA report filtering is not used.
>
> These 2 conditions would satisfy the safety criteria that the current
> perf interface addresses.
>
> To enable the query:
> - Add an ioctl to expose head and tail to the user
> - Add an ioctl to return size and offset of the OA buffer
> - Map the OA buffer to the user space
>
> v2:
> - Improve commit message (Chris)
> - Do not mmap based on gem object filp. Instead, use perf_fd and support
> mmap syscall (Chris)
> - Pass non-zero offset in mmap to enforce the right object is
> mapped (Chris)
> - Do not expose gpu_address (Chris)
> - Verify start and length of vma for page alignment (Lionel)
> - Move SQNTL config out (Lionel)
>
> v3: (Chris)
> - Omit redundant checks
> - Return VM_FAULT_SIGBUS is old stream is closed
> - Maintain reference counts to stream in vm_open and vm_close
> - Use switch to identify object to be mapped
>
> v4: Call kref_put on closing perf fd (Chris)
> v5:
> - Strip access to OA buffer from unprivileged child of a privileged
> parent. Use VM_DONTCOPY
> - Enforce MAP_PRIVATE by checking for VM_MAYSHARE
>
> v6:
> (Chris)
> - Use len of -1 in unmap_mapping_range
> - Don't use stream->oa_buffer.vma->obj in vm_fault_oa
> - Use kernel block comment style
> - do_mmap gets a reference to the file and puts it in do_munmap, so
> no need to maintain a reference to i915_perf_stream. Hence, remove
> vm_open/vm_close and stream->closed hooks/checks.
> (Umesh)
> - Do not allow mmap if SAMPLE_OA_REPORT is not set during
> i915_perf_open_ioctl.
> - Drop ioctl returning head/tail since this information is already
> whitelisted. Remove hooks to read head register.
>
> v7: (Chris)
> - unmap before destroy
> - change ioctl argument struct
>
> v8: Documentation and more checks (Chris)
>
> Signed-off-by: Piotr Maciejewski
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> +#define I915_PERF_OA_BUFFER_MMAP_OFFSET 1
> +
> +/**
> + * i915_perf_oa_buffer_info_locked - size and offset of the OA buffer
> + * @stream: i915 perf stream
> + * @arg: pointer to oa buffer info filled by this function.
> + */
> +static int i915_perf_oa_buffer_info_locked(struct i915_perf_stream *stream,
> + unsigned int cmd,
> + unsigned long arg)
> +{
> + struct drm_i915_perf_oa_buffer_info info;
> + void __user *output = (void __user *)arg;
> +
> + if (i915_perf_stream_paranoid && !perfmon_capable()) {
> + DRM_DEBUG("Insufficient privileges to access OA buffer
> info\n");
> + return -EACCES;
> + }
> +
> + if (_IOC_SIZE(cmd) != sizeof(info))
> + return -EINVAL;
For total pedantry, we could check cmd & (IOC_IN | IOC_OUT) as well :)
> +
> + if (copy_from_user(, output, sizeof(info)))
> + return -EFAULT;
> +
> + if (info.type || info.flags || info.rsvd)
> + return -EINVAL;
> +
> + info.size = stream->oa_buffer.vma->size;
> + info.offset = I915_PERF_OA_BUFFER_MMAP_OFFSET * PAGE_SIZE;
> +
> + if (copy_to_user(output, , sizeof(info)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> /**
> * i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
> * @stream: An i915 perf stream
> @@ -3290,6 +3329,8 @@ static long i915_perf_ioctl_locked(struct
> i915_perf_stream *stream,
> return 0;
> case I915_PERF_IOCTL_CONFIG:
> return i915_perf_config_locked(stream, arg);
> + case I915_PERF_IOCTL_GET_OA_BUFFER_INFO:
> + return
Re: [Intel-gfx] [PATCH 13/21] drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs
On 30/07/2020 10:37, Chris Wilson wrote:
On the virtual engines, we only use the intel_breadcrumbs for tracking
signaling of stale breadcrumbs from the irq_workers. They do not have
any associated interrupt handling, active requests are passed to a
physical engine and associated breadcrumb interrupt handler. This causes
issues for us as we need to ensure that we do not actually try and
enable interrupts and the powermanagement required for them on the
virtual engine, as they will never be disabled. Instead, let's
specify the physical engine used for interrupt handler on a particular
breadcrumb.
v2: Drop b->irq_armed = true mocking for no interrupt HW
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 76 ++-
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 36 +
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 47
drivers/gpu/drm/i915/gt/intel_engine.h| 17 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 31 +---
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_reset.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 1 +
drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++-
drivers/gpu/drm/i915/i915_irq.c | 1 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/i915_request.h | 4 -
16 files changed, 162 insertions(+), 95 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fbdc465a5870..2ffd47a86656 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -28,6 +28,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
+#include "intel_breadcrumbs.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -55,30 +56,28 @@ static void irq_disable(struct intel_engine_cs *engine)
static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(>irq_lock);
+ if (!b->irq_engine || !b->irq_armed)
+ return;
+
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
- irq_disable(engine);
+ irq_disable(b->irq_engine);
WRITE_ONCE(b->irq_armed, false);
- intel_gt_pm_put_async(engine->gt);
+ intel_gt_pm_put_async(b->irq_engine->gt);
}
-void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
+void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
{
- struct intel_breadcrumbs *b = >breadcrumbs;
unsigned long flags;
if (!READ_ONCE(b->irq_armed))
return;
spin_lock_irqsave(>irq_lock, flags);
- if (b->irq_armed)
- __intel_breadcrumbs_disarm_irq(b);
+ __intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(>irq_lock, flags);
}
@@ -133,13 +132,8 @@ __dma_fence_signal__notify(struct dma_fence *fence,
static void add_retire(struct intel_breadcrumbs *b, struct intel_timeline *tl)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
- if (unlikely(intel_engine_is_virtual(engine)))
- engine = intel_virtual_engine_get_sibling(engine, 0);
-
- intel_engine_add_retire(engine, tl);
+ if (b->irq_engine)
+ intel_engine_add_retire(b->irq_engine, tl);
}
static bool __signal_request(struct i915_request *rq, struct list_head *signals)
@@ -164,7 +158,7 @@ static void signal_irq_work(struct irq_work *work)
spin_lock(>irq_lock);
- if (b->irq_armed && list_empty(>signalers))
+ if (list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
list_splice_init(>signaled_requests, );
@@ -222,14 +216,12 @@ static void signal_irq_work(struct irq_work *work)
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(>irq_lock);
- if (b->irq_armed)
+
+ if (!b->irq_engine || b->irq_armed)
return;
- if (!intel_gt_pm_get_if_awake(engine->gt))
+ if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
return;
/*
@@ -249,37 +241,49 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
*/
if
[Intel-gfx] [PATCH 2/4] drm/i915/perf: Whitelist OA report trigger registers
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.
Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is checked and the whitelist is
enabled accordingly. On closing the perf fd, the whitelist is removed.
This ensures that the access to the whitelist is gated by
perf_stream_paranoid.
v2:
- Move related change to this patch (Lionel)
- Bump up perf revision (Lionel)
v3: Pardon whitelisted registers for selftest (Umesh)
v4: Document supported gens for the feature (Lionel)
v5: Whitelist registers only if perf_stream_paranoid is set to 0 (Jon)
v6: Move oa whitelist array to i915_perf (Chris)
v7: Fix OA writing beyond the wal->list memory (CI)
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 122 ++
drivers/gpu/drm/i915/gt/intel_workarounds.h | 7 +
.../gpu/drm/i915/gt/intel_workarounds_types.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 76 ++-
drivers/gpu/drm/i915/i915_perf_types.h| 6 +
5 files changed, 189 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index cef1c122696f..08ddacbf2667 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -60,12 +60,23 @@ static void wa_init_start(struct i915_wa_list *wal, const
char *name, const char
#define WA_LIST_CHUNK (1 << 4)
+/*
+ * Some of the i915 code like perf OA tries to whitelist registers on demand.
+ * Such code adds to the wal->list, but that would not work because the list
+ * is compacted below by wa_init_finish. While _wa_add does have code to grow
+ * the list, it does not seem to take the compaction into consideration. Leave
+ * 8 entries free during the compaction until a better mechanism can be put in
+ * place.
+ */
+#define WA_LIST_DYNAMIC_ENTRIES 8
+
static void wa_init_finish(struct i915_wa_list *wal)
{
/* Trim unused entries. */
if (!IS_ALIGNED(wal->count, WA_LIST_CHUNK)) {
+ size_t size = wal->count + WA_LIST_DYNAMIC_ENTRIES;
struct i915_wa *list = kmemdup(wal->list,
- wal->count * sizeof(*list),
+ size * sizeof(*list),
GFP_KERNEL);
if (list) {
@@ -81,10 +92,50 @@ static void wa_init_finish(struct i915_wa_list *wal)
wal->wa_count, wal->name, wal->engine_name);
}
+static int _wa_index(struct i915_wa_list *wal, i915_reg_t reg)
+{
+ unsigned int addr = i915_mmio_reg_offset(reg);
+ int start = 0, end = wal->count;
+
+ /* addr and wal->list[].reg, both include the R/W flags */
+ while (start < end) {
+ int mid = start + (end - start) / 2;
+
+ if (i915_mmio_reg_offset(wal->list[mid].reg) < addr)
+ start = mid + 1;
+ else if (i915_mmio_reg_offset(wal->list[mid].reg) > addr)
+ end = mid;
+ else
+ return mid;
+ }
+
+ return -1;
+}
+
+static void _wa_remove(struct i915_wa_list *wal, i915_reg_t reg, u32 flags)
+{
+ int index;
+ struct i915_wa *wa = wal->list;
+
+ reg.reg |= flags;
+
+ index = _wa_index(wal, reg);
+ if (index < 0)
+ return;
+
+ memset(wa + index, 0, sizeof(*wa));
+
+ while (index < wal->count - 1) {
+ swap(wa[index], wa[index + 1]);
+ index++;
+ }
+
+ wal->count--;
+}
+
static void _wa_add(struct i915_wa_list *wal, const struct i915_wa *wa)
{
- unsigned int addr = i915_mmio_reg_offset(wa->reg);
- unsigned int start = 0, end = wal->count;
+ int index;
const unsigned int grow = WA_LIST_CHUNK;
struct i915_wa *wa_;
@@ -106,30 +157,23 @@ static void _wa_add(struct i915_wa_list *wal, const
struct i915_wa *wa)
wal->list = list;
}
- while (start < end) {
- unsigned int mid = start + (end - start) / 2;
-
- if (i915_mmio_reg_offset(wal->list[mid].reg) < addr) {
- start = mid + 1;
- } else if (i915_mmio_reg_offset(wal->list[mid].reg) > addr) {
- end = mid;
- } else {
- wa_ = >list[mid];
-
- if ((wa->clr | wa_->clr) && !(wa->clr & ~wa_->clr)) {
- DRM_ERROR("Discarding overwritten w/a for reg
%04x (clear: %08x, set: %08x)\n",
- i915_mmio_reg_offset(wa_->reg),
- wa_->clr, wa_->set);
+
[Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)
v4: Use intel_uncore_rmw and REG_BIT (Chris)
Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c6f6370283cf..a43bf4cd337a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2493,6 +2493,12 @@ gen12_enable_metric_set(struct i915_perf_stream *stream,
(period_exponent <<
GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
: 0);
+ /*
+* Initialize Super Queue Internal Cnt Register
+* Set PMON Enable in order to collect valid metrics.
+*/
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, 0, GEN12_SQCNT1_PMON_ENABLE);
+
/*
* Update all contexts prior writing the mux configurations as we need
* to make sure all slices/subslices are ON before writing to NOA
@@ -2552,6 +2558,9 @@ static void gen12_disable_metric_set(struct
i915_perf_stream *stream)
/* Make sure we disable noa to save power. */
intel_uncore_rmw(uncore, RPM_CONFIG1, GEN10_GT_NOA_ENABLE, 0);
+
+ /* Reset PMON Enable to save power. */
+ intel_uncore_rmw(uncore, GEN12_SQCNT1, GEN12_SQCNT1_PMON_ENABLE, 0);
}
static void gen7_oa_enable(struct i915_perf_stream *stream)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5eae593ee784..5e09acbd1406 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -696,6 +696,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define OABUFFER_SIZE_16M (7 << 3)
#define GEN12_OA_TLB_INV_CR _MMIO(0xceec)
+#define GEN12_SQCNT1 _MMIO(0x8718)
+#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
/* Gen12 OAR unit */
#define GEN12_OAR_OACONTROL _MMIO(0x2960)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Allow privileged user to map the OA buffer
Fixes a memory corruption due to addition of OA whitelist on demand. This cover letter is included to trigger "Test-with" an IGT patch. Tests - https://patchwork.freedesktop.org/series/80113/ Signed-off-by: Umesh Nerlige Ramappa Test-with: 20200730230002.55737-1-umesh.nerlige.rama...@intel.com Piotr Maciejewski (1): drm/i915/perf: Ensure observation logic is not clock gated Umesh Nerlige Ramappa (3): drm/i915/perf: Whitelist OA report trigger registers drm/i915/perf: Whitelist OA counter and buffer registers drm/i915/perf: Map OA buffer to user space for gen12 performance query drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 122 -- drivers/gpu/drm/i915/gt/intel_workarounds.h | 7 + .../gpu/drm/i915/gt/intel_workarounds_types.h | 5 + drivers/gpu/drm/i915/i915_perf.c | 224 +- drivers/gpu/drm/i915/i915_perf_types.h| 6 + drivers/gpu/drm/i915/i915_reg.h | 10 + include/uapi/drm/i915_drm.h | 33 +++ 9 files changed, 383 insertions(+), 28 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/perf: Whitelist OA counter and buffer registers
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
specific registers.
v2:
- Bump up the perf revision (Lionel)
- Use indexing for counters (Lionel)
- Fix selftest for oa ticking register (Umesh)
v3: Pardon whitelisted registers for selftest (Umesh)
v4:
- Document whitelisted registers (Lionel)
- Fix live isolated whitelist for OA regs (Umesh)
v5:
- Free up whitelist slots. Remove GPU_TICKS and A20 counter (Piotr)
- Whitelist registers only if perf_stream_paranoid is set to 0 (Jon)
v6: Move oa whitelist array to i915_perf (Chris)
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 18 +-
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7443654ef842..562154d3fd49 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1350,11 +1350,19 @@ free_noa_wait(struct i915_perf_stream *stream)
static struct i915_whitelist_reg gen9_oa_wl_regs[] = {
{ OAREPORTTRIG2, RING_FORCE_TO_NONPRIV_ACCESS_RW },
{ OAREPORTTRIG6, RING_FORCE_TO_NONPRIV_ACCESS_RW },
+ { OA_PERF_COUNTER_A(18), RING_FORCE_TO_NONPRIV_ACCESS_RW |
+RING_FORCE_TO_NONPRIV_RANGE_4 },
+ { GEN8_OASTATUS, RING_FORCE_TO_NONPRIV_ACCESS_RD |
+RING_FORCE_TO_NONPRIV_RANGE_4 },
};
static struct i915_whitelist_reg gen12_oa_wl_regs[] = {
{ GEN12_OAG_OAREPORTTRIG2, RING_FORCE_TO_NONPRIV_ACCESS_RW },
{ GEN12_OAG_OAREPORTTRIG6, RING_FORCE_TO_NONPRIV_ACCESS_RW },
+ { GEN12_OAG_PERF_COUNTER_A(18), RING_FORCE_TO_NONPRIV_ACCESS_RW |
+ RING_FORCE_TO_NONPRIV_RANGE_4 },
+ { GEN12_OAG_OASTATUS, RING_FORCE_TO_NONPRIV_ACCESS_RD |
+ RING_FORCE_TO_NONPRIV_RANGE_4 },
};
static void intel_engine_apply_oa_whitelist(struct i915_perf_stream *stream)
@@ -4511,8 +4519,16 @@ int i915_perf_ioctl_version(void)
*into the OA buffer. This applies only to gen8+. The feature can
*only be accessed if perf_stream_paranoid is set to 0 by privileged
*user.
+*
+* 7: Whitelist below OA registers for user to identify the location of
+*triggered reports in the OA buffer. This applies only to gen8+.
+*The feature can only be accessed if perf_stream_paranoid is set to
+*0 by privileged user.
+*
+*- OA buffer head/tail/status/buffer registers for read only
+*- OA counters A18, A19, A20 for read/write
*/
- return 6;
+ return 7;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e09acbd1406..497f75e70f8a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -974,6 +974,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define OAREPORTTRIG8_NOA_SELECT_6_SHIFT24
#define OAREPORTTRIG8_NOA_SELECT_7_SHIFT28
+/* Performance counters registers */
+#define OA_PERF_COUNTER_A(idx) _MMIO(0x2800 + 8 * (idx))
+#define OA_PERF_COUNTER_A_UPPER(idx) _MMIO(0x2800 + 8 * (idx) + 4)
+
+/* Gen12 Performance counters registers */
+#define GEN12_OAG_PERF_COUNTER_A(idx) _MMIO(0xD980 + 8 * (idx))
+#define GEN12_OAG_PERF_COUNTER_A_UPPER(idx) _MMIO(0xD980 + 8 * (idx) + 4)
+
/* Same layout as OASTARTTRIGX */
#define GEN12_OAG_OASTARTTRIG1 _MMIO(0xd900)
#define GEN12_OAG_OASTARTTRIG2 _MMIO(0xd904)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggered reports within oa buffer.
Triggering reports into the OA buffer is achieved by writing into a
a trigger register. Optionally an unused counter/register is set with a
marker value such that a triggered report can be identified in the OA
buffer. Reports are usually triggered at the start and end of work that
is measured.
Since OA buffer is large and queries can be frequent, an efficient way
to look for triggered reports is required. By knowing the current head
and tail offsets into the OA buffer, it is easier to determine the
locality of the reports of interest.
Current perf OA interface does not expose head/tail information to the
user and it filters out invalid reports before sending data to user.
Also considering limited size of user buffer used during a query,
creating a 1:1 copy of the OA buffer at the user space added undesired
complexity.
The solution was to map the OA buffer to user space provided
(1) that it is accessed from a privileged user.
(2) OA report filtering is not used.
These 2 conditions would satisfy the safety criteria that the current
perf interface addresses.
To enable the query:
- Add an ioctl to expose head and tail to the user
- Add an ioctl to return size and offset of the OA buffer
- Map the OA buffer to the user space
v2:
- Improve commit message (Chris)
- Do not mmap based on gem object filp. Instead, use perf_fd and support
mmap syscall (Chris)
- Pass non-zero offset in mmap to enforce the right object is
mapped (Chris)
- Do not expose gpu_address (Chris)
- Verify start and length of vma for page alignment (Lionel)
- Move SQNTL config out (Lionel)
v3: (Chris)
- Omit redundant checks
- Return VM_FAULT_SIGBUS is old stream is closed
- Maintain reference counts to stream in vm_open and vm_close
- Use switch to identify object to be mapped
v4: Call kref_put on closing perf fd (Chris)
v5:
- Strip access to OA buffer from unprivileged child of a privileged
parent. Use VM_DONTCOPY
- Enforce MAP_PRIVATE by checking for VM_MAYSHARE
v6:
(Chris)
- Use len of -1 in unmap_mapping_range
- Don't use stream->oa_buffer.vma->obj in vm_fault_oa
- Use kernel block comment style
- do_mmap gets a reference to the file and puts it in do_munmap, so
no need to maintain a reference to i915_perf_stream. Hence, remove
vm_open/vm_close and stream->closed hooks/checks.
(Umesh)
- Do not allow mmap if SAMPLE_OA_REPORT is not set during
i915_perf_open_ioctl.
- Drop ioctl returning head/tail since this information is already
whitelisted. Remove hooks to read head register.
v7: (Chris)
- unmap before destroy
- change ioctl argument struct
v8: Documentation and more checks (Chris)
Signed-off-by: Piotr Maciejewski
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 +
drivers/gpu/drm/i915/i915_perf.c | 125 ++-
include/uapi/drm/i915_drm.h | 33 ++
4 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b23368529a40..7c4b9b0c334b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -204,7 +204,7 @@ compute_partial_view(const struct drm_i915_gem_object *obj,
return view;
}
-static vm_fault_t i915_error_to_vmf_fault(int err)
+vm_fault_t i915_error_to_vmf_fault(int err)
{
switch (err) {
default:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index efee9e0d2508..1190a3a228ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct
drm_i915_gem_object *obj);
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
+vm_fault_t i915_error_to_vmf_fault(int err);
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 562154d3fd49..8af7cc2d523a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,10 +192,12 @@
*/
#include
+#include
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_mman.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
@@ -3265,6 +3267,43 @@ static long i915_perf_config_locked(struct
i915_perf_stream *stream,
return ret;
}
+#define I915_PERF_OA_BUFFER_MMAP_OFFSET 1
+
+/**
+ * i915_perf_oa_buffer_info_locked - size and offset of the OA buffer
+ * @stream: i915 perf stream
+ * @arg: pointer to oa buffer info filled by
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini()
== Series Details == Series: series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80136/ State : success == Summary == CI Bug Log - changes from CI_DRM_8821_full -> Patchwork_18281_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18281_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-all: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-glk9/igt@gem_exec_whis...@basic-queues-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-glk9/igt@gem_exec_whis...@basic-queues-all.html * igt@gem_softpin@invalid: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl8/igt@gem_soft...@invalid.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-skl5/igt@gem_soft...@invalid.html * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-ytiled: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#108145] / [i915#52] / [i915#54]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl9/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-ytiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-skl2/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-ytiled.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#699]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl4/igt@kms_flip_til...@flip-changes-tiling-y.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-skl8/igt@kms_flip_til...@flip-changes-tiling-y.html * igt@kms_frontbuffer_tracking@psr-shrfb-scaledprimary: - shard-tglb: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-tglb6/igt@kms_frontbuffer_track...@psr-shrfb-scaledprimary.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-tglb8/igt@kms_frontbuffer_track...@psr-shrfb-scaledprimary.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][11] -> [DMESG-FAIL][12] ([fdo#108145] / [i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-iclb5/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#31]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-kbl6/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-kbl2/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-kbl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@perf@stress-open-close: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#1635] / [i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-apl3/igt@p...@stress-open-close.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-apl6/igt@p...@stress-open-close.html Possible fixes * igt@drm_read@empty-nonblock: - shard-snb: [TIMEOUT][21] ([i915#1958] / [i915#2119]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-snb6/igt@drm_r...@empty-nonblock.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-snb5/igt@drm_r...@empty-nonblock.html * igt@gem_exec_parallel@basic@vcs1: - shard-tglb: [INCOMPLETE][23] -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/shard-tglb7/igt@gem_exec_parallel@ba...@vcs1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/shard-tglb1/igt@gem_exec_parallel@ba...@vcs1.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [FAIL][25]
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool
== Series Details == Series: drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool URL : https://patchwork.freedesktop.org/series/80147/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: timeline semaphore support
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80146/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18286
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/index.html
Known issues
Here are the changes found in Patchwork_18286 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-bsw-n3050: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-n3050/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-bsw-n3050/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][9] ([i915#2203]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18286/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 36)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* IGT: IGT_5755 -> IGTPW_4837
* Linux: CI_DRM_8822 -> Patchwork_18286
CI-20190529: 20190529
CI_DRM_8822: 26bcf5c3ceadd2c69181a320c4363f58ae34be46 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4837: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4837/index.html
IGT_5755: e9ef5db4cd286fb4bf151a24efcd7a62a4df18f1 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18286: 13d5e473be67c7c8a3d4ee5ce2b13a742362e54f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
13d5e473be67 drm/i915: peel dma-fence-chains wait fences
6ce048ef3ae9 drm/i915: add syncobj timeline support
1d1036f097fd drm/i915: introduce a mechanism to extend execbuf2
== Logs ==
For more details
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Quoting Lionel Landwerlin (2020-07-31 14:45:52) > Introduces a new parameters to execbuf so that we can specify syncobj > handles as well as timeline points. > > v2: Reuse i915_user_extension_fn > > v3: Check that the chained extension is only present once (Chris) > > v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel) > > v5: Use BIT_ULL (Chris) > > v6: Fix issue with already signaled timeline points, > dma_fence_chain_find_seqno() setting fence to NULL (Chris) > > v7: Report ENOENT with invalid syncobj handle (Lionel) > > v8: Check for out of order timeline point insertion (Chris) > > v9: After explanations on > https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html > drop the ordering check from v8 (Lionel) > > v10: Set first extension enum item to 1 (Jason) The other unaddressed issue here is that we do not need to arbitrarily limit the caller to only a single extension. The code to handle multiple invocations is actually smaller... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Quoting Lionel Landwerlin (2020-07-31 14:45:52)
> - drm_syncobj_replace_fence(syncobj, fence);
> + if (eb->fences[n].chain_fence) {
> + drm_syncobj_add_point(syncobj,
> eb->fences[n].chain_fence,
> + fence, eb->fences[n].value);
This function remains not acceptable. It is trivial to write an igt test
that causes the DRM_ERROR. A user controllable error message is still
not allowed. If you do not have such a test in your igt series, then that
too is lacking.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool
Quoting Chris Wilson (2020-07-31 15:12:45) > Make sure that the obj->base.resv does not hold a reference to a fence > that itself has an active reference on the object. There is no automatic The active reference is pruned. I was thinking of other reference cycles that may exist, but I do not think apply to the users of the buffer pool. There is still an advantage here in that the pruning of that reference may be delayed, so a kick here could release the memory faster. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: timeline semaphore support
== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80146/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: timeline semaphore support
== Series Details == Series: drm/i915: timeline semaphore support URL : https://patchwork.freedesktop.org/series/80146/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1d1036f097fd drm/i915: introduce a mechanism to extend execbuf2 -:377: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #377: FILE: include/uapi/drm/i915_drm.h:1204: +#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_USE_EXTENSIONS<<1)) ^ total: 0 errors, 0 warnings, 1 checks, 333 lines checked 6ce048ef3ae9 drm/i915: add syncobj timeline support -:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #25: https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html -:308: CHECK:LINE_SPACING: Please don't use multiple blank lines #308: FILE: include/uapi/drm/i915_drm.h:628: + + total: 0 errors, 1 warnings, 1 checks, 291 lines checked 13d5e473be67 drm/i915: peel dma-fence-chains wait fences ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Decouple obj<->fence reference cycles on freeing the GT pool
Make sure that the obj->base.resv does not hold a reference to a fence
that itself has an active reference on the object. There is no automatic
pruning, so we must decouple such reference cycles (just in case they
exist) before discarding the pool->obj.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 4b7671ac5dca..6411ebdf9468 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -31,9 +31,18 @@ bucket_for_size(struct intel_gt_buffer_pool *pool, size_t sz)
return >cache_list[n];
}
+static void dma_resv_prune(struct dma_resv *resv)
+{
+ dma_resv_lock(resv, NULL);
+ dma_resv_add_excl_fence(resv, NULL);
+ dma_resv_unlock(resv);
+}
+
static void node_free(struct intel_gt_buffer_pool_node *node)
{
+ dma_resv_prune(node->obj->base.resv);
i915_gem_object_put(node->obj);
+
i915_active_fini(>active);
kfree_rcu(node, rcu);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
v4: Rebase
Move array fence parsing in i915_gem_do_execbuffer()
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 131 +++---
include/uapi/drm/i915_drm.h | 26 +++-
2 files changed, 103 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b7a86cdec9b5..5aac474c058f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -26,6 +26,7 @@
#include "i915_gem_ioctls.h"
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
struct eb_vma {
struct i915_vma *vma;
@@ -281,6 +282,13 @@ struct i915_execbuffer {
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
struct eb_vma_array *array;
+
+ struct i915_eb_fence {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ } *fences;
+ u32 n_fences;
+
+ u64 extension_flags; /** Available extensions parameters */
};
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
@@ -1622,7 +1630,8 @@ static int i915_gem_check_execbuffer(struct
drm_i915_gem_execbuffer2 *exec)
return -EINVAL;
/* Kernel clipping was a DRI1 misfeature */
- if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+ if (!(exec->flags & (I915_EXEC_FENCE_ARRAY |
+I915_EXEC_USE_EXTENSIONS))) {
if (exec->num_cliprects || exec->cliprects_ptr)
return -EINVAL;
}
@@ -2189,41 +2198,41 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
{
while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
kvfree(fences);
}
-static struct drm_syncobj **
+static int
get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+ struct i915_execbuffer *eb)
{
const unsigned long nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
- struct drm_syncobj **fences;
+ struct i915_eb_fence *fences;
unsigned long n;
int err;
if (!(args->flags & I915_EXEC_FENCE_ARRAY))
- return NULL;
+ return 0;
/* Check multiplication overflow for access_ok() and kvmalloc_array() */
BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
if (nfences > min_t(unsigned long,
ULONG_MAX / sizeof(*user),
SIZE_MAX / sizeof(*fences)))
- return ERR_PTR(-EINVAL);
+ return -EINVAL;
user = u64_to_user_ptr(args->cliprects_ptr);
if (!access_ok(user, nfences * sizeof(*user)))
- return ERR_PTR(-EFAULT);
+ return -EFAULT;
fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_KERNEL);
if (!fences)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
for (n = 0; n < nfences; n++) {
struct drm_i915_gem_exec_fence fence;
@@ -2239,7 +2248,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
goto err;
}
- syncobj = drm_syncobj_find(file, fence.handle);
+ syncobj = drm_syncobj_find(eb->file, fence.handle);
if (!syncobj) {
DRM_DEBUG("Invalid syncobj handle provided\n");
err = -ENOENT;
@@ -2249,38 +2258,31 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+ fences[n].syncobj = ptr_pack_bits(syncobj, fence.flags, 2);
}
- return fences;
+ eb->fences = fences;
+ eb->n_fences = nfences;
+
+ return 0;
err:
__free_fence_array(fences, n);
- return ERR_PTR(err);
-}
-
-static void
-put_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_syncobj **fences)
-{
- if (fences)
- __free_fence_array(fences, args->num_cliprects);
+ return err;
}
static int
-await_fence_array(struct i915_execbuffer *eb,
-
[Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Rebase
Signed-off-by: Lionel Landwerlin
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 167 +-
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 39
4 files changed, 203 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 5aac474c058f..652f3b30a374 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -285,6 +285,8 @@ struct i915_execbuffer {
struct i915_eb_fence {
struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ u64 value;
+ struct dma_fence_chain *chain_fence;
} *fences;
u32 n_fences;
@@ -2200,14 +2202,121 @@ eb_pin_engine(struct i915_execbuffer *eb,
static void
__free_fence_array(struct i915_eb_fence *fences, unsigned int n)
{
- while (n--)
+ while (n--) {
drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
static int
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct i915_execbuffer *eb)
+get_timeline_fence_array(const struct
drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences,
+struct i915_execbuffer *eb)
+{
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fence *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return -EINVAL;
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return -EFAULT;
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return -EFAULT;
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return -ENOMEM;
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence fence;
+ struct drm_syncobj *syncobj;
+ u64 point;
+
+ if (__copy_from_user(, user_fences++, sizeof(fence))) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ if (fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+ err = -EINVAL;
+ goto err;
+ }
+
+ if (__get_user(point, user_values++)) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ syncobj = drm_syncobj_find(eb->file, fence.handle);
+ if (!syncobj) {
+ DRM_DEBUG("Invalid syncobj handle provided\n");
+ err = -ENOENT;
+ goto err;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point != 0 && fence.flags & I915_EXEC_FENCE_SIGNAL) {
+ /*
+* Waiting and signaling the same point (when point !=
+* 0) would break the timeline.
+*/
+ if (fence.flags & I915_EXEC_FENCE_WAIT) {
+ DRM_DEBUG("Tring
[Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notification.
v2: Also deal with chains where the last node is not a dma-fence-chain
Signed-off-by: Lionel Landwerlin
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 652f3b30a374..01e22b303e34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2390,6 +2390,7 @@ await_fence_array(struct i915_execbuffer *eb)
for (n = 0; n < eb->n_fences; n++) {
struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
struct dma_fence *fence;
unsigned int flags;
@@ -2410,7 +2411,43 @@ await_fence_array(struct i915_execbuffer *eb)
continue;
}
- err = i915_request_await_dma_fence(eb->request, fence);
+ chain = to_dma_fence_chain(fence);
+ if (chain) {
+ struct dma_fence *iter;
+
+ /*
+* If we're dealing with a dma-fence-chain, peel the
+* chain by adding all of the unsignaled fences
+* (dma_fence_chain_for_each does that for us) the
+* chain points to.
+*
+* This enables us to identify waits on i915 fences
+* and allows for faster engine-to-engine
+* synchronization using HW semaphores.
+*/
+ dma_fence_chain_for_each(iter, fence) {
+ struct dma_fence_chain *iter_chain =
+ to_dma_fence_chain(iter);
+
+ /*
+* It is possible that the last item in the
+* chain is not a dma_fence_chain.
+*/
+ if (iter_chain) {
+ err =
i915_request_await_dma_fence(eb->request,
+
iter_chain->fence);
+ } else {
+ err =
i915_request_await_dma_fence(eb->request, iter);
+ }
+ if (err < 0) {
+ dma_fence_put(iter);
+ break;
+ }
+ }
+ } else {
+ err = i915_request_await_dma_fence(eb->request, fence);
+ }
+
dma_fence_put(fence);
if (err < 0)
return err;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: timeline semaphore support
Hi all, Reviewed series, just getting a CI run with the CI. Cheers, Test-with: 20200731134120.156288-1-lionel.g.landwer...@intel.com Lionel Landwerlin (3): drm/i915: introduce a mechanism to extend execbuf2 drm/i915: add syncobj timeline support drm/i915: peel dma-fence-chains wait fences .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 333 +++--- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_getparam.c | 1 + include/uapi/drm/i915_drm.h | 65 +++- 4 files changed, 342 insertions(+), 60 deletions(-) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/66] drm/i915: Always defer fenced work to the worker
On 7/31/20 3:28 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-31 10:03:59) On 7/15/20 1:50 PM, Chris Wilson wrote: Currently, if an error is raised we always call the cleanup locally [and skip the main work callback]. However, some future users Could you add an example of those future users? In the next (or two) patch, the code needs to do the error cleanup from process context. Since the error paths should be relatively infrequent, and more often than not raised synchronously, I didn't see a reason to build in a flag to say whether or not the release-on-error could be performed immediately from the interrupt context. The example in this series is that even if an error is thrown, we have committed changes to the ppGTT layout (in particular marking PTE to be evicted) and so we must complete unbinding the old pages from the ppGTT, otherwise they may remain accessible. Thanks. I was mostly thinking if this or something similar could be added to the commit message to aid in understanding why the change is needed. /Thomas -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes and improvements for Xen pvdrm
== Series Details ==
Series: Fixes and improvements for Xen pvdrm
URL : https://patchwork.freedesktop.org/series/80141/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18285
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/index.html
Known issues
Here are the changes found in Patchwork_18285 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [PASS][3] -> [INCOMPLETE][4] ([i915#2089])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-kbl-r: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-r/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-kbl-r/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][21] ([i915#2203]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24] +1
similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18285/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +2 similar issues
[25]:
Re: [Intel-gfx] [PATCH 18/66] drm/i915: Always defer fenced work to the worker
Quoting Thomas Hellström (Intel) (2020-07-31 10:03:59) > > On 7/15/20 1:50 PM, Chris Wilson wrote: > > Currently, if an error is raised we always call the cleanup locally > > [and skip the main work callback]. However, some future users > Could you add an example of those future users? In the next (or two) patch, the code needs to do the error cleanup from process context. Since the error paths should be relatively infrequent, and more often than not raised synchronously, I didn't see a reason to build in a flag to say whether or not the release-on-error could be performed immediately from the interrupt context. The example in this series is that even if an error is thrown, we have committed changes to the ppGTT layout (in particular marking PTE to be evicted) and so we must complete unbinding the old pages from the ppGTT, otherwise they may remain accessible. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/66] drm/i915/gem: Bind the fence async for execbuf
On 7/28/20 5:08 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-27 19:19:19) On 7/15/20 1:51 PM, Chris Wilson wrote: It is illegal to wait on an another vma while holding the vm->mutex, as that easily leads to ABBA deadlocks (we wait on a second vma that waits on us to release the vm->mutex). So while the vm->mutex exists, move the waiting outside of the lock into the async binding pipeline. Why is it we don't just move the fence binding to a separate loop after unlocking the vm->mutex in eb_reserve_vm()? That is what is done. The work is called immediately when possible. Just the loop may be deferred if the what we need to unbind are still active OK, then Reviewed-by: Thomas Hellström -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes and improvements for Xen pvdrm
== Series Details ==
Series: Fixes and improvements for Xen pvdrm
URL : https://patchwork.freedesktop.org/series/80141/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7d48f149439c xen/gntdev: Fix dmabuf import with non-zero sgt offset
-:10: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id '37ccb44d0b00', maybe
rebased or not pulled?
#10:
Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dma-buf import functionality")
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
c9e3448681cf drm/xen-front: Fix misused IS_ERR_OR_NULL checks
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#14:
133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
total: 0 errors, 1 warnings, 0 checks, 50 lines checked
3efddbd31e3b drm/xen-front: Add YUYV to supported formats
e17f2c5fcaec xen: Sync up with the canonical protocol definition in Xen
-:108: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#108: FILE: include/xen/interface/io/displif.h:522:
+ uint32_t data_ofs;
-:150: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#150: FILE: include/xen/interface/io/displif.h:782:
+ uint32_t buffer_sz;
-:186: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#186: FILE: include/xen/interface/io/displif.h:833:
+ uint32_t edid_sz;
-:207: WARNING:TABSTOP: Statements should start on a tabstop
#207: FILE: include/xen/interface/io/displif.h:899:
+ struct xendispl_get_edid_resp get_edid;
-:208: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u8' over 'uint8_t'
#208: FILE: include/xen/interface/io/displif.h:900:
+ uint8_t reserved1[56];
total: 0 errors, 1 warnings, 4 checks, 157 lines checked
62e66d848083 drm/xen-front: Pass dumb buffer data offset to the backend
b9a322b906d6 drm/xen-front: Add support for EDID based configuration
-:253: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#253: FILE: drivers/gpu/drm/xen/xen_drm_front_cfg.h:39:
+int xen_drm_front_cfg_tail(struct xen_drm_front_info *front_info,
+ struct xen_drm_front_cfg
*cfg);
-:256: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#256: FILE: drivers/gpu/drm/xen/xen_drm_front_cfg.h:42:
+void xen_drm_front_cfg_free(struct xen_drm_front_info *front_info,
+ struct
xen_drm_front_cfg *cfg);
total: 0 errors, 0 warnings, 2 checks, 293 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/66] drm/i915/gem: Asynchronous GTT unbinding
On 7/15/20 1:51 PM, Chris Wilson wrote: It is reasonably common for userspace (even modern drivers like iris) to reuse an active address for a new buffer. This would cause the application to stall under its mutex (originally struct_mutex) until the old batches were idle and it could synchronously remove the stale PTE. However, we can queue up a job that waits on the signal for the old nodes to complete and upon those signals, remove the old nodes replacing them with the new ones for the batch. This is still CPU driven, but in theory we can do the GTT patching from the GPU. The job itself has a completion signal allowing the execbuf to wait upon the rebinding, and also other observers to coordinate with the common VM activity. Letting userspace queue up more work, lets it do more stuff without blocking other clients. In turn, we take care not to let it too much concurrent work, creating a small number of queues for each context to limit the number of concurrent tasks. The implementation relies on only scheduling one unbind operation per vma as we use the unbound vma->node location to track the stale PTE. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1402 Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Andi Shyti Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake
== Series Details ==
Series: series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for
Tiger Lake
URL : https://patchwork.freedesktop.org/series/80139/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18284
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/index.html
Known issues
Here are the changes found in Patchwork_18284 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-byt-j1900/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-byt-j1900/igt@debugfs_test@read_all_entries.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18284/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[24]:
[Intel-gfx] [PATCH 1/6] xen/gntdev: Fix dmabuf import with non-zero sgt offset
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dma-buf import functionality")
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 75d3bb948bf3..b1b6eebafd5d 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -613,6 +613,14 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
goto fail_detach;
}
+ /* Check that we have zero offset. */
+ if (sgt->sgl->offset) {
+ ret = ERR_PTR(-EINVAL);
+ pr_debug("DMA buffer has %d bytes offset, user-space expects
0\n",
+sgt->sgl->offset);
+ goto fail_unmap;
+ }
+
/* Check number of pages that imported buffer has. */
if (attach->dmabuf->size != gntdev_dmabuf->nr_pages << PAGE_SHIFT) {
ret = ERR_PTR(-EINVAL);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/xen-front: Add support for EDID based configuration
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's "resolution" property.
If backend provides EDID with XENDISPL_OP_GET_EDID request then
its values must take precedence over the resolutions defined in
XenStore.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 62
drivers/gpu/drm/xen/xen_drm_front.h | 9 ++-
drivers/gpu/drm/xen/xen_drm_front_cfg.c | 82 +
drivers/gpu/drm/xen/xen_drm_front_cfg.h | 7 ++
drivers/gpu/drm/xen/xen_drm_front_conn.c| 26 ++-
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 3 +
drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 3 +
drivers/gpu/drm/xen/xen_drm_front_kms.c | 5 ++
8 files changed, 194 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 013c9e0e412c..cc5981bdbfb3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,59 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info
*front_info,
fb_cookie);
}
+int xen_drm_front_get_edid(struct xen_drm_front_info *front_info,
+ int conn_idx, struct page **pages,
+ u32 buffer_sz, u32 *edid_sz)
+{
+ struct xen_drm_front_evtchnl *evtchnl;
+ struct xen_front_pgdir_shbuf_cfg buf_cfg;
+ struct xen_front_pgdir_shbuf shbuf;
+ struct xendispl_req *req;
+ unsigned long flags;
+ int ret;
+
+ if (unlikely(conn_idx >= front_info->num_evt_pairs))
+ return -EINVAL;
+
+ memset(_cfg, 0, sizeof(buf_cfg));
+ buf_cfg.xb_dev = front_info->xb_dev;
+ buf_cfg.num_pages = DIV_ROUND_UP(buffer_sz, PAGE_SIZE);
+ buf_cfg.pages = pages;
+ buf_cfg.pgdir =
+ buf_cfg.be_alloc = false;
+
+ ret = xen_front_pgdir_shbuf_alloc(_cfg);
+ if (ret < 0)
+ return ret;
+
+ evtchnl = _info->evt_pairs[conn_idx].req;
+
+ mutex_lock(>u.req.req_io_lock);
+
+ spin_lock_irqsave(_info->io_lock, flags);
+ req = be_prepare_req(evtchnl, XENDISPL_OP_GET_EDID);
+ req->op.get_edid.gref_directory =
+ xen_front_pgdir_shbuf_get_dir_start();
+ req->op.get_edid.buffer_sz = buffer_sz;
+
+ ret = be_stream_do_io(evtchnl, req);
+ spin_unlock_irqrestore(_info->io_lock, flags);
+
+ if (ret < 0)
+ goto fail;
+
+ ret = be_stream_wait_io(evtchnl);
+ if (ret < 0)
+ goto fail;
+
+ *edid_sz = evtchnl->u.req.resp.get_edid.edid_sz;
+
+fail:
+ mutex_unlock(>u.req.req_io_lock);
+ xen_front_pgdir_shbuf_free();
+ return ret;
+}
+
static int xen_drm_drv_dumb_create(struct drm_file *filp,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
@@ -466,6 +519,7 @@ static void xen_drm_drv_release(struct drm_device *dev)
xenbus_switch_state(front_info->xb_dev,
XenbusStateInitialising);
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
}
@@ -562,6 +616,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info
*front_info)
drm_mode_config_cleanup(drm_dev);
drm_dev_put(drm_dev);
fail:
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
return ret;
}
@@ -622,7 +677,14 @@ static int displback_initwait(struct xen_drm_front_info
*front_info)
static int displback_connect(struct xen_drm_front_info *front_info)
{
+ int ret;
+
xen_drm_front_evtchnl_set_state(front_info, EVTCHNL_STATE_CONNECTED);
+
+ /* We are all set to read additional configuration from the backend. */
+ ret = xen_drm_front_cfg_tail(front_info, _info->cfg);
+ if (ret < 0)
+ return ret;
return xen_drm_drv_init(front_info);
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..be0c982f4d82 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -112,9 +112,12 @@ struct xen_drm_front_drm_pipeline {
struct drm_simple_display_pipe pipe;
struct drm_connector conn;
- /* These are only for connector mode checking */
+ /* These are only for connector mode checking if no EDID present */
int width, height;
+ /* Is not NULL if EDID is used for connector configuration. */
+ struct edid *edid;
+
struct drm_pending_vblank_event *pending_event;
struct delayed_work pflip_to_worker;
@@ -160,4 +163,8 @@ int
[Intel-gfx] [PATCH 0/6] Fixes and improvements for Xen pvdrm
From: Oleksandr Andrushchenko Hello, This series contains an assorted set of fixes and improvements for the Xen para-virtualized display driver and grant device driver which I have collected over the last couple of months: 1. Minor fixes to grant device driver and drm/xen-front. 2. New format (YUYV) added to the list of the PV DRM supported formats which allows the driver to be used in zero-copying use-cases when a camera device is the source of the dma-bufs. 3. Synchronization with the latest para-virtualized protocol definition in Xen [1]. 4. SGT offset is now propagated to the backend: while importing a dmabuf it is possible that the data of the buffer is put with offset which is indicated by the SGT offset. This is needed for some GPUs which have non-zero offset. 5. Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID request which allows frontends to request EDID structure per connector. This request is optional and if not supported by the backend then visible area is still defined by the relevant XenStore's "resolution" property. If backend provides EDID with XENDISPL_OP_GET_EDID request then its values must take precedence over the resolutions defined in XenStore. Thank you, Oleksandr Andrushchenko [1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=c27a184225eab54d20435c8cab5ad0ef384dc2c0 Oleksandr Andrushchenko (6): xen/gntdev: Fix dmabuf import with non-zero sgt offset drm/xen-front: Fix misused IS_ERR_OR_NULL checks drm/xen-front: Add YUYV to supported formats xen: Sync up with the canonical protocol definition in Xen drm/xen-front: Pass dumb buffer data offset to the backend drm/xen-front: Add support for EDID based configuration drivers/gpu/drm/xen/xen_drm_front.c | 72 +++- drivers/gpu/drm/xen/xen_drm_front.h | 11 ++- drivers/gpu/drm/xen/xen_drm_front_cfg.c | 82 +++ drivers/gpu/drm/xen/xen_drm_front_cfg.h | 7 ++ drivers/gpu/drm/xen/xen_drm_front_conn.c| 27 +- drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 3 + drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 3 + drivers/gpu/drm/xen/xen_drm_front_gem.c | 11 +-- drivers/gpu/drm/xen/xen_drm_front_kms.c | 7 +- drivers/xen/gntdev-dmabuf.c | 8 ++ include/xen/interface/io/displif.h | 91 - 11 files changed, 305 insertions(+), 17 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] xen: Sync up with the canonical protocol definition in Xen
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add the version as an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
There are cases when display data buffer is created with non-zero
offset to the data start. Handle such cases and provide that offset
while creating a display buffer.
3. Add XENDISPL_OP_GET_EDID command
Add an optional request for reading Extended Display Identification
Data (EDID) structure which allows better configuration of the
display connectors over the configuration set in XenStore.
With this change connectors may have multiple resolutions defined
with respect to detailed timing definitions and additional properties
normally provided by displays.
If this request is not supported by the backend then visible area
is defined by the relevant XenStore's "resolution" property.
If backend provides extended display identification data (EDID) with
XENDISPL_OP_GET_EDID request then EDID values must take precedence
over the resolutions defined in XenStore.
4. Bump protocol version to 2.
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/displif.h | 91 +-
1 file changed, 88 insertions(+), 3 deletions(-)
diff --git a/include/xen/interface/io/displif.h
b/include/xen/interface/io/displif.h
index fdc279dc4a88..c2d900186883 100644
--- a/include/xen/interface/io/displif.h
+++ b/include/xen/interface/io/displif.h
@@ -38,7 +38,8 @@
* Protocol version
**
*/
-#define XENDISPL_PROTOCOL_VERSION "1"
+#define XENDISPL_PROTOCOL_VERSION "2"
+#define XENDISPL_PROTOCOL_VERSION_INT 2
/*
**
@@ -202,6 +203,9 @@
* Width and height of the connector in pixels separated by
* XENDISPL_RESOLUTION_SEPARATOR. This defines visible area of the
* display.
+ * If backend provides extended display identification data (EDID) with
+ * XENDISPL_OP_GET_EDID request then EDID values must take precedence
+ * over the resolutions defined here.
*
*-- Connector Request Transport Parameters ---
*
@@ -349,6 +353,8 @@
#define XENDISPL_OP_FB_DETACH 0x13
#define XENDISPL_OP_SET_CONFIG 0x14
#define XENDISPL_OP_PG_FLIP0x15
+/* The below command is available in protocol version 2 and above. */
+#define XENDISPL_OP_GET_EDID 0x16
/*
**
@@ -377,6 +383,10 @@
#define XENDISPL_FIELD_BE_ALLOC"be-alloc"
#define XENDISPL_FIELD_UNIQUE_ID "unique-id"
+#define XENDISPL_EDID_BLOCK_SIZE 128
+#define XENDISPL_EDID_BLOCK_COUNT 256
+#define XENDISPL_EDID_MAX_SIZE (XENDISPL_EDID_BLOCK_SIZE *
XENDISPL_EDID_BLOCK_COUNT)
+
/*
**
* STATUS RETURN CODES
@@ -451,7 +461,9 @@
* +++++
* | gref_directory | 40
* +++++
- * | reserved | 44
+ * | data_ofs | 44
+ * +++++
+ * | reserved | 48
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
@@ -494,6 +506,7 @@
* buffer size (buffer_sz) exceeds what can be addressed by this single page,
* then reference to the next page must be supplied (see gref_dir_next_page
* below)
+ * data_ofs - uint32_t, offset of the data in the buffer, octets
*/
#define XENDISPL_DBUF_FLG_REQ_ALLOC(1 << 0)
@@ -506,6 +519,7 @@ struct xendispl_dbuf_create_req {
uint32_t buffer_sz;
uint32_t flags;
grant_ref_t gref_directory;
+ uint32_t data_ofs;
};
/*
@@ -731,6 +745,44 @@ struct xendispl_page_flip_req {
uint64_t fb_cookie;
};
+/*
+ * Request EDID - request EDID describing current connector:
+ * 01 2 3octet
+ * +++++
+ * | id| _OP_GET_EDID | reserved | 4
+ *
[Intel-gfx] [PATCH 5/6] drm/xen-front: Pass dumb buffer data offset to the backend
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 6 --
drivers/gpu/drm/xen/xen_drm_front.h | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 88db2726e8ce..013c9e0e412c 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -157,7 +157,8 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages)
+ u32 bpp, u64 size, u32 offset,
+ struct page **pages)
{
struct xen_drm_front_evtchnl *evtchnl;
struct xen_drm_front_dbuf *dbuf;
@@ -194,6 +195,7 @@ int xen_drm_front_dbuf_create(struct xen_drm_front_info
*front_info,
req->op.dbuf_create.gref_directory =
xen_front_pgdir_shbuf_get_dir_start(>shbuf);
req->op.dbuf_create.buffer_sz = size;
+ req->op.dbuf_create.data_ofs = offset;
req->op.dbuf_create.dbuf_cookie = dbuf_cookie;
req->op.dbuf_create.width = width;
req->op.dbuf_create.height = height;
@@ -408,7 +410,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
ret = xen_drm_front_dbuf_create(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(obj),
args->width, args->height, args->bpp,
- args->size,
+ args->size, 0,
xen_drm_front_gem_get_pages(obj));
if (ret)
goto fail_backend;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index f92c258350ca..54486d89650e 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -145,7 +145,7 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages);
+ u32 bpp, u64 size, u32 offset, struct page
**pages);
int xen_drm_front_fb_attach(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u64 fb_cookie, u32 width,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 4ec8a49241e1..39ff95b75357 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -210,7 +210,8 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
ret = xen_drm_front_dbuf_create(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(_obj->base),
- 0, 0, 0, size, xen_obj->pages);
+ 0, 0, 0, size, sgt->sgl->offset,
+ xen_obj->pages);
if (ret < 0)
return ERR_PTR(ret);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
drivers/gpu/drm/xen/xen_drm_front_gem.c
133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
134 size_t size)
135 {
136 struct xen_gem_object *xen_obj;
137
138 xen_obj = gem_create(dev, size);
139 if (IS_ERR_OR_NULL(xen_obj))
140 return ERR_CAST(xen_obj);
Fix this and the rest of misused places with IS_ERR_OR_NULL in the
driver.
Fixes: c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend"
Signed-off-by: Oleksandr Andrushchenko
Reported-by: Dan Carpenter
---
drivers/gpu/drm/xen/xen_drm_front.c | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.c | 8
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 3e660fb111b3..88db2726e8ce 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -400,8 +400,8 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
args->size = args->pitch * args->height;
obj = xen_drm_front_gem_create(dev, args->size);
- if (IS_ERR_OR_NULL(obj)) {
- ret = PTR_ERR_OR_ZERO(obj);
+ if (IS_ERR(obj)) {
+ ret = PTR_ERR(obj);
goto fail;
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e094111..4ec8a49241e1 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -83,7 +83,7 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
size = round_up(size, PAGE_SIZE);
xen_obj = gem_create_obj(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return xen_obj;
if (drm_info->front_info->cfg.be_alloc) {
@@ -117,7 +117,7 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
*/
xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
xen_obj->pages = drm_gem_get_pages(_obj->base);
- if (IS_ERR_OR_NULL(xen_obj->pages)) {
+ if (IS_ERR(xen_obj->pages)) {
ret = PTR_ERR(xen_obj->pages);
xen_obj->pages = NULL;
goto fail;
@@ -136,7 +136,7 @@ struct drm_gem_object *xen_drm_front_gem_create(struct
drm_device *dev,
struct xen_gem_object *xen_obj;
xen_obj = gem_create(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return ERR_CAST(xen_obj);
return _obj->base;
@@ -194,7 +194,7 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
size = attach->dmabuf->size;
xen_obj = gem_create_obj(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return ERR_CAST(xen_obj);
ret = gem_alloc_pages_array(xen_obj, size);
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 78096bbcd226..ef11b1e4de39 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -60,7 +60,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
int ret;
fb = drm_gem_fb_create_with_funcs(dev, filp, mode_cmd, _funcs);
- if (IS_ERR_OR_NULL(fb))
+ if (IS_ERR(fb))
return fb;
gem_obj = fb->obj[0];
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/xen-front: Add YUYV to supported formats
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
index 459702fa990e..44f1f70c0aed 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -33,6 +33,7 @@ static const u32 plane_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB1555,
DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_YUYV,
};
const u32 *xen_drm_front_conn_get_formats(int *format_count)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake
== Series Details == Series: series starting with [1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake URL : https://patchwork.freedesktop.org/series/80139/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3)
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma
page-directories (rev3)
URL : https://patchwork.freedesktop.org/series/80045/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8822 -> Patchwork_18283
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/index.html
Known issues
Here are the changes found in Patchwork_18283 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][3] -> [INCOMPLETE][4] ([i915#2045])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-kefka/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][13] ([i915#1233]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][19] ([i915#2203]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][23] ([i915#2203]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8822/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18283/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +2 similar issues
[25]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3)
== Series Details == Series: series starting with [CI,1/3] drm/i915: Preallocate stashes for vma page-directories (rev3) URL : https://patchwork.freedesktop.org/series/80045/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Load DMC firmware v2.07 for Tiger Lake
Bump TGL DMC version to 2.07. This new version has power saving enhancements. Cc: José Roberto de Souza Signed-off-by: Anusha Srivatsa Reviewed-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_csr.c b/drivers/gpu/drm/i915/display/intel_csr.c index f22a7645c249..eb74eb123148 100644 --- a/drivers/gpu/drm/i915/display/intel_csr.c +++ b/drivers/gpu/drm/i915/display/intel_csr.c @@ -44,8 +44,8 @@ #define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) MODULE_FIRMWARE(RKL_CSR_PATH); -#define TGL_CSR_PATH "i915/tgl_dmc_ver2_06.bin" -#define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 6) +#define TGL_CSR_PATH "i915/tgl_dmc_ver2_07.bin" +#define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 7) #define TGL_CSR_MAX_FW_SIZE0x6000 MODULE_FIRMWARE(TGL_CSR_PATH); -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Load DMC firmware v2.02 for Rocket Lake
The latest firmware contains fix for PSR2 power saving. Cc: Matt Roper Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_csr.c b/drivers/gpu/drm/i915/display/intel_csr.c index eb74eb123148..b6d0ce627d07 100644 --- a/drivers/gpu/drm/i915/display/intel_csr.c +++ b/drivers/gpu/drm/i915/display/intel_csr.c @@ -40,8 +40,8 @@ #define GEN12_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE -#define RKL_CSR_PATH "i915/rkl_dmc_ver2_01.bin" -#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) +#define RKL_CSR_PATH "i915/rkl_dmc_ver2_02.bin" +#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) MODULE_FIRMWARE(RKL_CSR_PATH); #define TGL_CSR_PATH "i915/tgl_dmc_ver2_07.bin" -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Drop stale timeline constructor assert
== Series Details ==
Series: drm/i915/selftests: Drop stale timeline constructor assert
URL : https://patchwork.freedesktop.org/series/80138/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8821 -> Patchwork_18282
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/index.html
Known issues
Here are the changes found in Patchwork_18282 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-bsw-kefka/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [PASS][7] -> [DMESG-FAIL][8] ([i915#1233])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][13] ([fdo#109271]) -> [DMESG-FAIL][14]
([i915#62])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18282/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.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#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 36)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8821 -> Patchwork_18282
CI-20190529: 20190529
CI_DRM_8821: cf15caaa19051dc0f83f0192b63520bff861dec2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5753: d80bd02632e8a91389c58c601b3ebce8e6c924d3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18282:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Drop stale timeline constructor assert
== Series Details == Series: drm/i915/selftests: Drop stale timeline constructor assert URL : https://patchwork.freedesktop.org/series/80138/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 33/66] drm/i915: Remove unused i915_gem_evict_vm()
On 7/15/20 1:51 PM, Chris Wilson wrote: Obsolete, last user removed. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/66] drm/i915/gt: Push the wait for the context to bound to the request
On 7/15/20 1:51 PM, Chris Wilson wrote: Rather than synchronously wait for the context to be bound, within the intel_context_pin(), we can track the pending completion of the bind fence and only submit requests along the context when signaled. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini()
== Series Details ==
Series: series starting with [CI,1/7] drm/i915: Add a couple of missing
i915_active_fini()
URL : https://patchwork.freedesktop.org/series/80136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8821 -> Patchwork_18281
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/index.html
Known issues
Here are the changes found in Patchwork_18281 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-bxt-dsi: [PASS][1] -> [DMESG-WARN][2] ([i915#1635] /
[i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-bxt-dsi/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-bxt-dsi/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8821/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18281/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 36)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8821 -> Patchwork_18281
CI-20190529: 20190529
CI_DRM_8821: cf15caaa19051dc0f83f0192b63520bff861dec2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5753: d80bd02632e8a91389c58c601b3ebce8e6c924d3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18281: aa9ef3910fe6c2792d8dd09aa125157bb1ef4cd9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
aa9ef3910fe6 drm/i915: Provide a fastpath for waiting on vma bindings
73e2c3dcb3cf drm/i915: Reduce locking around
i915_active_acquire_preallocate_barrier()
818db00a50b5 drm/i915: Make the stale cached active node available for any
timeline
917a7fe12197 drm/i915: Keep the most recently used active-fence upon discard
7c5f10efb72e drm/i915: Export a preallocate variant of i915_active_acquire()
fee371eac94d drm/i915: Skip taking acquire mutex for no ref->active callback
dbd6608f1534 drm/i915: Add a couple of missing i915_active_fini()
==
Re: [Intel-gfx] [PATCH 31/66] drm/i915/gt: Acquire backing storage for the context
On 7/15/20 1:51 PM, Chris Wilson wrote: Pull the individual acquisition of the context objects (state, ring, timeline) under a common i915_acquire_ctx in preparation to allow the context to evict memory (or rather the i915_acquire_ctx on its behalf). The context objects maintain their semi-permanent status; that is they are assumed to be accessible by the HW at all times until we receive a signal from the HW that they are no longer in use. Currently, we generate such a signal ourselves from the context switch following the final use of the objects. This means that they will remain on the HW for an indefinite amount of time, and we retain the use of pinning to keep them in the same place. As they are pinned, they can be processed outside of the working set for the requests within the context. This is useful, as the context share some global state causing it to incur a global lock via its objects. By only requiring that lock as the context is activated, it is both reduced in frequency and reduced in duration (as compared to execbuf). Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Drop stale timeline constructor assert
Since we pass around encoded parameters to the kernel context
constructor using the ce->timeline pointer, we can no longer assert that
it should be zero for mock timeline construction.
Fixes: cffef56a43bb ("drm/i915/gt: Support multiple pinned timelines")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/mock_engine.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index d5beb116261f..027de53cd05b 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -152,7 +152,6 @@ static int mock_context_alloc(struct intel_context *ce)
if (!ce->ring)
return -ENOMEM;
- GEM_BUG_ON(ce->timeline);
ce->timeline = intel_timeline_create(ce->engine->gt);
if (IS_ERR(ce->timeline)) {
kfree(ce->engine);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini()
== Series Details == Series: series starting with [CI,1/7] drm/i915: Add a couple of missing i915_active_fini() URL : https://patchwork.freedesktop.org/series/80136/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/66] drm/i915: Hold wakeref for the duration of the vma GGTT binding
On 7/15/20 1:51 PM, Chris Wilson wrote: Now that we have pushed the binding itself outside of the vm->mutex, we are clear of the potential wakeref inversions and can take the wakeref around the actual duration of the HW interaction. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/66] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
On 7/15/20 1:51 PM, Chris Wilson wrote: From: Maarten Lankhorst i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory eviction. We don't use it yet, but lets start adding the definition first. To use it, we have to pass a non-NULL ww to gem_object_lock, and don't unlock directly. It is done in i915_gem_ww_ctx_fini. Changes since v1: - Change ww_ctx and obj order in locking functions (Jonas Lahtinen) Signed-off-by: Maarten Lankhorst Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/66] drm/i915/gem: Reintroduce multiple passes for reloc processing
On 7/15/20 1:51 PM, Chris Wilson wrote: The prospect of locking the entire submission sequence under a wide ww_mutex re-imposes some key restrictions, in particular that we must not call copy_(from|to)_user underneath the mutex (as the faulthandlers themselves may need to take the ww_mutex). To satisfy this requirement, we need to split the relocation handling into multiple phases again. After dropping the reservations, we need to allocate enough buffer space to both copy the relocations from userspace into, and serve as the relocation command buffer. Once we have finished copying the relocations, we can then re-aquire all the objects for the execbuf and rebind them, including our new relocations objects. After we have bound all the new and old objects into their final locations, we can then convert the relocation entries into the GPU commands to update the relocated vma. Finally, once it is all over and we have dropped the ww_mutex for the last time, we can then complete the update of the user relocation entries. Signed-off-by: Chris Wilson Tvrtko had some issues with this patch when submitted as part of a previous series, and they don't seem addressed. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_ringsize: Manually control timeout
On Fri, 31 Jul 2020 at 10:15, Chris Wilson wrote: > > Manually setup the signal handler for SIGARLM so that we can dump some > debug information for test failures. > > Signed-off-by: Chris Wilson Acked-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/66] drm/i915/gem: Include secure batch in common execbuf pinning
On 7/15/20 1:51 PM, Chris Wilson wrote: Pull the GGTT binding for the secure batch dispatch into the common vma pinning routine for execbuf, so that there is just a single central place for all i915_vma_pin(). Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/66] drm/i915/gem: Include cmdparser in common execbuf pinning
On 7/15/20 1:51 PM, Chris Wilson wrote: Pull the cmdparser allocations in to the reservation phase, and then they are included in the common vma pinning pass. Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/perf: Map OA buffer to user space for gen12 performance query
Quoting Umesh Nerlige Ramappa (2020-07-31 07:07:23)
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
> implementation for query, but Gen12+ requires a new approach for query
> based on triggered reports within oa buffer.
>
> Triggering reports into the OA buffer is achieved by writing into a
> a trigger register. Optionally an unused counter/register is set with a
> marker value such that a triggered report can be identified in the OA
> buffer. Reports are usually triggered at the start and end of work that
> is measured.
>
> Since OA buffer is large and queries can be frequent, an efficient way
> to look for triggered reports is required. By knowing the current head
> and tail offsets into the OA buffer, it is easier to determine the
> locality of the reports of interest.
>
> Current perf OA interface does not expose head/tail information to the
> user and it filters out invalid reports before sending data to user.
> Also considering limited size of user buffer used during a query,
> creating a 1:1 copy of the OA buffer at the user space added undesired
> complexity.
>
> The solution was to map the OA buffer to user space provided
>
> (1) that it is accessed from a privileged user.
> (2) OA report filtering is not used.
>
> These 2 conditions would satisfy the safety criteria that the current
> perf interface addresses.
>
> To enable the query:
> - Add an ioctl to expose head and tail to the user
> - Add an ioctl to return size and offset of the OA buffer
> - Map the OA buffer to the user space
>
> v2:
> - Improve commit message (Chris)
> - Do not mmap based on gem object filp. Instead, use perf_fd and support
> mmap syscall (Chris)
> - Pass non-zero offset in mmap to enforce the right object is
> mapped (Chris)
> - Do not expose gpu_address (Chris)
> - Verify start and length of vma for page alignment (Lionel)
> - Move SQNTL config out (Lionel)
>
> v3: (Chris)
> - Omit redundant checks
> - Return VM_FAULT_SIGBUS is old stream is closed
> - Maintain reference counts to stream in vm_open and vm_close
> - Use switch to identify object to be mapped
>
> v4: Call kref_put on closing perf fd (Chris)
> v5:
> - Strip access to OA buffer from unprivileged child of a privileged
> parent. Use VM_DONTCOPY
> - Enforce MAP_PRIVATE by checking for VM_MAYSHARE
>
> v6:
> (Chris)
> - Use len of -1 in unmap_mapping_range
> - Don't use stream->oa_buffer.vma->obj in vm_fault_oa
> - Use kernel block comment style
> - do_mmap gets a reference to the file and puts it in do_munmap, so
> no need to maintain a reference to i915_perf_stream. Hence, remove
> vm_open/vm_close and stream->closed hooks/checks.
> (Umesh)
> - Do not allow mmap if SAMPLE_OA_REPORT is not set during
> i915_perf_open_ioctl.
> - Drop ioctl returning head/tail since this information is already
> whitelisted. Remove hooks to read head register.
>
> v7: (Chris)
> - unmap before destroy
> - change ioctl argument struct
>
> Signed-off-by: Piotr Maciejewski
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 +
> drivers/gpu/drm/i915/i915_perf.c | 123 ++-
> include/uapi/drm/i915_drm.h | 18
> 4 files changed, 143 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index b23368529a40..7c4b9b0c334b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -204,7 +204,7 @@ compute_partial_view(const struct drm_i915_gem_object
> *obj,
> return view;
> }
>
> -static vm_fault_t i915_error_to_vmf_fault(int err)
> +vm_fault_t i915_error_to_vmf_fault(int err)
> {
> switch (err) {
> default:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> index efee9e0d2508..1190a3a228ea 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> @@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj);
>
> void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
>
> +vm_fault_t i915_error_to_vmf_fault(int err);
> +
> #endif
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 8ff502719dfd..8ac7944c24b8 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -192,10 +192,12 @@
> */
>
> #include
> +#include
> #include
> #include
>
> #include "gem/i915_gem_context.h"
> +#include "gem/i915_gem_mman.h"
> #include "gt/intel_engine_pm.h"
> #include "gt/intel_engine_user.h"
> #include "gt/intel_gt.h"
> @@ -3269,6 +3271,42 @@ static long
Re: [Intel-gfx] [PATCH 20/66] drm/i915/gem: Separate the ww_mutex walker into its own list
On 7/15/20 1:51 PM, Chris Wilson wrote: In preparation for making eb_vma bigger and heavy to run in parallel, we need to stop applying an in-place swap() to reorder around ww_mutex deadlocks. Keep the array intact and reorder the locks using a dedicated list. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/perf: Ensure observation logic is not clock gated
Quoting Umesh Nerlige Ramappa (2020-07-31 07:07:20)
> From: Piotr Maciejewski
>
> A clock gating switch can control if the performance monitoring and
> observation logic is enaled or not. Ensure that we enable the clocks.
>
> v2: Separate code from other patches (Lionel)
> v3: Reset PMON enable when disabling perf to save power (Lionel)
>
> Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
> Signed-off-by: Piotr Maciejewski
> Signed-off-by: Umesh Nerlige Ramappa
> Reviewed-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 13 +
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index c6f6370283cf..fe408c327d3c 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2493,6 +2493,14 @@ gen12_enable_metric_set(struct i915_perf_stream
> *stream,
> (period_exponent <<
> GEN12_OAG_OAGLBCTXCTRL_TIMER_PERIOD_SHIFT))
> : 0);
>
> + /*
> +* Initialize Super Queue Internal Cnt Register
> +* Set PMON Enable in order to collect valid metrics.
> +*/
> + intel_uncore_write(uncore, GEN12_SQCNT1,
> + intel_uncore_read(uncore, GEN12_SQCNT1) |
> + GEN12_SQCNT1_PMON_ENABLE);
intel_uncore_rmw(uncore, GEN12_SQCNT, 0 GEN12_SQCNT1_PMON_ENABLE);
> +
> /*
> * Update all contexts prior writing the mux configurations as we need
> * to make sure all slices/subslices are ON before writing to NOA
> @@ -2552,6 +2560,11 @@ static void gen12_disable_metric_set(struct
> i915_perf_stream *stream)
>
> /* Make sure we disable noa to save power. */
> intel_uncore_rmw(uncore, RPM_CONFIG1, GEN10_GT_NOA_ENABLE, 0);
> +
> + /* Reset PMON Enable to save power. */
> + intel_uncore_write(uncore, GEN12_SQCNT1,
> + intel_uncore_read(uncore, GEN12_SQCNT1) &
> + ~GEN12_SQCNT1_PMON_ENABLE);
intel_uncore_rmw(uncore, GEN12_SQCNT, GEN12_SQCNT1_PMON_ENABLE, 0);
Tempting to suggest we add intel_uncore_set_bit/clr_bit helpers around
the rmw helper.
> }
>
> static void gen7_oa_enable(struct i915_perf_stream *stream)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5eae593ee784..377339399458 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -696,6 +696,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define OABUFFER_SIZE_16M (7 << 3)
>
> #define GEN12_OA_TLB_INV_CR _MMIO(0xceec)
> +#define GEN12_SQCNT1 _MMIO(0x8718)
> +#define GEN12_SQCNT1_PMON_ENABLE (1 << 30)
REG_BIT(30)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_ringsize: Manually control timeout
Manually setup the signal handler for SIGARLM so that we can dump some
debug information for test failures.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_ringsize.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_ctx_ringsize.c b/tests/i915/gem_ctx_ringsize.c
index c8e661472..4530b242f 100644
--- a/tests/i915/gem_ctx_ringsize.c
+++ b/tests/i915/gem_ctx_ringsize.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -214,6 +215,10 @@ static uint32_t batch_create(int i915)
return __batch_create(i915, 0);
}
+static void sighandler(int sig)
+{
+}
+
static unsigned int measure_inflight(int i915, unsigned int engine, int
timeout)
{
IGT_CORK_FENCE(cork);
@@ -230,15 +235,18 @@ static unsigned int measure_inflight(int i915, unsigned
int engine, int timeout)
int err;
fcntl(i915, F_SETFL, fcntl(i915, F_GETFL) | O_NONBLOCK);
- igt_set_timeout(timeout, "execbuf blocked!");
+ signal(SIGALRM, sighandler);
+ alarm(timeout);
gem_execbuf(i915, );
for (count = 1; (err = __execbuf(i915, )) == 0; count++)
;
+ igt_debugfs_dump(i915, "i915_engine_info");
igt_assert_eq(err, -EWOULDBLOCK);
close(execbuf.rsvd2);
- igt_reset_timeout();
+ alarm(0);
+ signal(SIGALRM, SIG_DFL);
fcntl(i915, F_SETFL, fcntl(i915, F_GETFL) & ~O_NONBLOCK);
igt_cork_unplug();
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/66] drm/i915: Always defer fenced work to the worker
On 7/15/20 1:50 PM, Chris Wilson wrote: Currently, if an error is raised we always call the cleanup locally [and skip the main work callback]. However, some future users Could you add an example of those future users? may need to take a mutex to cleanup and so we cannot immediately execute the cleanup as we may still be in interrupt context. With the execute-immediate flag, for most cases this should result in immediate cleanup of an error. Signed-off-by: Chris Wilson Otherwise Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/66] drm/i915: Add list_for_each_entry_safe_continue_reverse
On 7/15/20 1:50 PM, Chris Wilson wrote: One more list iterator variant, for when we want to unwind from inside one list iterator with the intention of restarting from the current entry as the new head of the list. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/66] drm/i915/gem: Remove the call for no-evict i915_vma_pin
On 7/28/20 5:05 PM, Chris Wilson wrote: Quoting Thomas Hellström (Intel) (2020-07-28 10:46:51) On 7/15/20 1:50 PM, Chris Wilson wrote: Remove the stub i915_vma_pin() used for incrementally pining objects for s/pining/pinning/ Pining for the fjords. -Chris Apart from that, Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
