[Intel-gfx] ✓ Fi.CI.BAT: success for Second round of i915_reg.h splitting
== Series Details == Series: Second round of i915_reg.h splitting URL : https://patchwork.freedesktop.org/series/99079/ State : success == Summary == CI Bug Log - changes from CI_DRM_1 -> Patchwork_22034 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/index.html Participating hosts (48 -> 40) -- Missing(8): shard-tglu bat-dg1-5 fi-icl-u2 fi-bsw-cyan fi-pnv-d510 shard-rkl shard-dg1 fi-bdw-samus Known issues Here are the changes found in Patchwork_22034 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_suspend@basic-s3@smem: - fi-tgl-1115g4: [PASS][2] -> [FAIL][3] ([i915#1888]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [PASS][4] -> [FAIL][5] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: [PASS][6] -> [DMESG-FAIL][7] ([i915#4494]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#4785]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] / [i915#4312]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-hsw-4770/igt@run...@aborted.html - fi-bdw-5557u: NOTRUN -> [FAIL][11] ([i915#2426] / [i915#4312]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][12] ([i915#3921]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785 Build changes - * Linux: CI_DRM_1 -> Patchwork_22034 CI-20190529: 20190529 CI_DRM_1: fe44f8bdb12374a6168cb561834eb714097f5e5f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22034: 87c7015ee797898a661781527260262112fb64d2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 87c7015ee797 drm/i915: Only include i915_reg.h from .c files 3761ccf4ed2a drm/i915: Move GT registers to their own header file 463b5c4cf89b drm/i915: Parameterize MI_PREDICATE registers 313b83d52475 drm/i915: Parameterize R_PWR_CLK_STATE register definition e96246c3da89 drm/i915/perf: Express OA register ranges with i915_range 1e07c9d33aa4 drm/i915/perf: Move OA regs to their own header == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22034/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: Eliminate remnant GEN references (rev2)
== Series Details == Series: drm/i915/dmc: Eliminate remnant GEN references (rev2) URL : https://patchwork.freedesktop.org/series/98166/ State : success == Summary == CI Bug Log - changes from CI_DRM_1_full -> Patchwork_22033_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_22033_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-tglb: NOTRUN -> [DMESG-WARN][1] ([i915#3002] / [i915#4856]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-tglb2/igt@gem_cre...@create-massive.html - shard-skl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-skl10/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-hang: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-snb4/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_eio@in-flight-contexts-1us: - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb1/igt@gem_...@in-flight-contexts-1us.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-tglb8/igt@gem_...@in-flight-contexts-1us.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][6] -> [INCOMPLETE][7] ([i915#180]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-apl2/igt@gem_...@in-flight-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-apl1/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb1/igt@gem_exec_balan...@parallel.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-iclb7/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-apl2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-vebox: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271]) +212 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-skl9/igt@gem_exec_par...@no-vebox.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#112283]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-iclb8/igt@gem_exec_par...@secure-non-root.html * igt@gem_lmem_swapping@heavy-random: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-kbl1/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-multi.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-apl3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_softpin@allocator-evict-all-engines: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#4171]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-glk7/igt@gem_soft...@allocator-evict-all-engines.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-glk1/igt@gem_soft...@allocator-evict-all-engines.html * igt@gem_userptr_blits@vma-merge: - shard-skl: NOTRUN -> [FAIL][21] ([i915#3318]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/shard-skl2/igt@gem_userptr_bl...@vma-merge.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +1 similar issue
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Second round of i915_reg.h splitting
== Series Details == Series: Second round of i915_reg.h splitting URL : https://patchwork.freedesktop.org/series/99079/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Second round of i915_reg.h splitting
== Series Details ==
Series: Second round of i915_reg.h splitting
URL : https://patchwork.freedesktop.org/series/99079/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1e07c9d33aa4 drm/i915/perf: Move OA regs to their own header
-:39: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#39:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 1023 lines checked
e96246c3da89 drm/i915/perf: Express OA register ranges with i915_range
-:30: ERROR:OPEN_BRACE: open brace '{' following function definitions go on the
next line
#30: FILE: drivers/gpu/drm/i915/i915_perf.c:3867:
+static inline bool reg_in_range_table(u32 addr, const struct i915_range
*table) {
-:87: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#87: FILE: drivers/gpu/drm/i915/i915_perf.c:3914:
+ { .start = 0x182300, .end = 0x1823a4 },$
-:88: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#88: FILE: drivers/gpu/drm/i915/i915_perf.c:3915:
+ {}$
total: 1 errors, 2 warnings, 0 checks, 524 lines checked
313b83d52475 drm/i915: Parameterize R_PWR_CLK_STATE register definition
463b5c4cf89b drm/i915: Parameterize MI_PREDICATE registers
3761ccf4ed2a drm/i915: Move GT registers to their own header file
-:178: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#178:
new file mode 100644
-:291: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#291: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:109:
+#define GEN8_SELECTIVE_READ_SUBSLICE_SELECT_MASK (0x3 <<
GEN8_SELECTIVE_READ_SUBSLICE_SELECT_SHIFT)
-:293: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#293: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:111:
+#define GEN8_SELECTIVE_READ_SLICE_SELECT_MASK(0x3 <<
GEN8_SELECTIVE_READ_SLICE_SELECT_SHIFT)
-:404: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#404: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:222:
+#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (1 <<
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
-:408: WARNING:LONG_LINE: line length of 107 exceeds 100 columns
#408: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:226:
+#define GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (0x7 <<
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
-:414: WARNING:LONG_LINE: line length of 108 exceeds 100 columns
#414: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:232:
+#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK(0x3 <<
GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
-:734: WARNING:LONG_LINE_COMMENT: line length of 104 exceeds 100 columns
#734: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:552:
+#define PXVFREQ(fstart)_MMIO(0x0 + (fstart) * 4) /*
P[0-15]VIDFREQ (0x1114c) (Ironlake) */
-:773: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines
#773: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:591:
+#define MEMCTL_CMD_STS (1 << 12) /* write 1 triggers command, clears
+when command complete */
-:773: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#773: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:591:
+when command complete */
-:886: WARNING:LONG_LINE_COMMENT: line length of 134 exceeds 100 columns
#886: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:704:
+#define IMPROMOEN(1 << 10) /* promo is immediate or delayed
until next idle interval (only for timeout method above) */
-:973: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'cxt_reg' - possible
side-effects?
#973: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:791:
+#define GEN6_CXT_TOTAL_SIZE(cxt_reg) (GEN6_CXT_RING_SIZE(cxt_reg) + \
+ GEN6_CXT_EXTENDED_SIZE(cxt_reg) + \
+ GEN6_CXT_PIPELINE_SIZE(cxt_reg))
-:983: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ctx_reg' - possible
side-effects?
#983: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:801:
+#define GEN7_CXT_TOTAL_SIZE(ctx_reg) (GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \
+GEN7_CXT_VFSTATE_SIZE(ctx_reg))
-:1553: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice' - possible
side-effects?
#1553: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:1371:
+#define GEN10_SLICE_PGCTL_ACK(slice) _MMIO(0x804c + ((slice) / 3) * 0x34 + \
+((slice) % 3) * 0x4)
-:1560: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice' - possible
side-effects?
#1560: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:1378:
+#define GEN10_SS01_EU_PGCTL_ACK(slice) _MMIO(0x805c + ((slice) / 3) * 0x30 + \
+((slice) % 3) * 0x8)
-:1563: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice' - possible
side-effects?
#1563: FILE: drivers/gpu/drm/i915/gt/intel_gt_regs.h:1381:
+#define GEN10_SS23_EU_PGCTL_ACK(slice) _MMIO(0x8060 + ((slice) / 3) * 0x30 + \
+((slice) % 3) * 0x8)
total: 0 errors, 10 warnings, 5 checks, 3520 lines checked
87c7015ee797 drm/i915: Only
[Intel-gfx] [PATCH 4/6] drm/i915: Parameterize MI_PREDICATE registers
The various MI_PREDICATE registers have per-engine instances. Today we
only utilize the RCS0 instance of each, but that will likely change in
the future; switch to parameterized register definitions to make these
easier to work with going forward.
Of special note is MI_PREDICATE_RESULT_2; we only use it in one place in
the driver today in HSW-specific code. It turns out that the bspec
(page 94) lists two different offsets for this register on HSW; one is
in the standard location shared by all other platforms (base + 0x3bc)
and the other is an unusual location (0x2214). We're using the second,
non-standard offset in i915 today; that offset doesn't exist on any
other platforms (and it's not even 100% clear that it's correct for HSW)
so I've renamed the current non-standard definition to
HSW_MI_PREDICATE_RESULT_2; the new cross-platform parameterized macro
(which is still unused at the moment) uses the standard offset.
Cc: Jani Nikula
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 11 +++
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_perf.c| 8
drivers/gpu/drm/i915/i915_reg.h | 11 +--
5 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index daf4a241cf77..e9fec6214073 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -142,6 +142,17 @@
(REG_FIELD_PREP(CMD_CCTL_WRITE_OVERRIDE_MASK, (write) << 1) | \
REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, (read) << 1))
+#define MI_PREDICATE_RESULT_2(base)_MMIO((base) + 0x3bc)
+#define LOWER_SLICE_ENABLED (1 << 0)
+#define LOWER_SLICE_DISABLED (0 << 0)
+#define MI_PREDICATE_SRC0(base)_MMIO((base) + 0x400)
+#define MI_PREDICATE_SRC0_UDW(base)_MMIO((base) + 0x400 + 4)
+#define MI_PREDICATE_SRC1(base)_MMIO((base) + 0x408)
+#define MI_PREDICATE_SRC1_UDW(base)_MMIO((base) + 0x408 + 4)
+#define MI_PREDICATE_DATA(base)_MMIO((base) + 0x410)
+#define MI_PREDICATE_RESULT(base) _MMIO((base) + 0x418)
+#define MI_PREDICATE_RESULT_1(base)_MMIO((base) + 0x41c)
+
#define RING_PP_DIR_DCLV(base) _MMIO((base) + 0x220)
#define PP_DIR_DCLV_2G 0x
#define RING_PP_DIR_BASE(base) _MMIO((base) + 0x228)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 622cdfed8a8b..3889efb3ffa4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -209,7 +209,7 @@ int intel_gt_init_hw(struct intel_gt *gt)
if (IS_HASWELL(i915))
intel_uncore_write(uncore,
- MI_PREDICATE_RESULT_2,
+ HSW_MI_PREDICATE_RESULT_2,
IS_HSW_GT3(i915) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 96c398051084..332b8ffb58f8 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -611,8 +611,8 @@ static const struct drm_i915_reg_descriptor
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
- REG64(MI_PREDICATE_SRC0),
- REG64(MI_PREDICATE_SRC1),
+ REG64_IDX(MI_PREDICATE_SRC0, RENDER_RING_BASE),
+ REG64_IDX(MI_PREDICATE_SRC1, RENDER_RING_BASE),
REG32(GEN7_3DPRIM_END_OFFSET),
REG32(GEN7_3DPRIM_START_VERTEX),
REG32(GEN7_3DPRIM_VERTEX_COUNT),
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f25906f19d56..aa7ee60715f8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1684,7 +1684,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
stream, cs, true /* save */, CS_GPR(i),
INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR + 8 * i, 2);
cs = save_restore_register(
- stream, cs, true /* save */, MI_PREDICATE_RESULT_1,
+ stream, cs, true /* save */,
MI_PREDICATE_RESULT_1(RENDER_RING_BASE),
INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1, 1);
/* First timestamp snapshot location. */
@@ -1738,7 +1738,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
*/
*cs++ = MI_LOAD_REGISTER_REG | (3 - 2);
*cs++ = i915_mmio_reg_offset(CS_GPR(JUMP_PREDICATE));
- *cs++ = i915_mmio_reg_offset(MI_PREDICATE_RESULT_1);
+ *cs++ =
[Intel-gfx] [PATCH 0/6] Second round of i915_reg.h splitting
Let's continue to split our giant i915_reg.h file into more logical domain-specific headers. In addition to a bunch of register definition segregation, the final patch of this series ensures that i915_reg.h is only #include'd from .c files that truly need its definitions (and removes all of the places it was included by other headers). This significantly reduces how much of the driver code gets rebuilt after a modifications to i915_reg.h. There's still more work to do after this series (especially moving display registers to their own header(s)). We'll also need to do a lot of cleanup of the definitions themselves in a future series --- for now the definitions have mostly been moved to new locations as-is without modification to order, coding-style, etc. Cc: Jani Nikula Cc: Lucas De Marchi Matt Roper (6): drm/i915/perf: Move OA regs to their own header drm/i915/perf: Express OA register ranges with i915_range drm/i915: Parameterize R_PWR_CLK_STATE register definition drm/i915: Parameterize MI_PREDICATE registers drm/i915: Move GT registers to their own header file drm/i915: Only include i915_reg.h from .c files drivers/gpu/drm/i915/display/g4x_hdmi.h |2 +- drivers/gpu/drm/i915/display/intel_atomic.c |1 + drivers/gpu/drm/i915/display/intel_bios.c |1 + drivers/gpu/drm/i915/display/intel_bw.c |1 + drivers/gpu/drm/i915/display/intel_crt.h |2 +- drivers/gpu/drm/i915/display/intel_ddi.h |2 +- drivers/gpu/drm/i915/display/intel_de.h |1 - .../drm/i915/display/intel_display_power.h|1 - drivers/gpu/drm/i915/display/intel_dmc.h |2 +- drivers/gpu/drm/i915/display/intel_dp.h |2 - drivers/gpu/drm/i915/display/intel_dsb.h |2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c |1 + drivers/gpu/drm/i915/display/intel_dvo_dev.h |2 +- drivers/gpu/drm/i915/display/intel_hdmi.h |2 - drivers/gpu/drm/i915/display/intel_lvds.h |2 +- drivers/gpu/drm/i915/display/intel_sdvo.h |2 +- drivers/gpu/drm/i915/display/intel_tc.c |1 + drivers/gpu/drm/i915/gem/i915_gem_stolen.c|1 + drivers/gpu/drm/i915/gem/i915_gem_tiling.c|1 + .../i915/gem/selftests/i915_gem_client_blt.c |3 +- .../drm/i915/gem/selftests/i915_gem_context.c |3 +- drivers/gpu/drm/i915/gt/gen2_engine_cs.c |1 + drivers/gpu/drm/i915/gt/gen6_ppgtt.c |1 + drivers/gpu/drm/i915/gt/gen7_renderclear.c|1 + drivers/gpu/drm/i915/gt/gen8_engine_cs.c |3 +- drivers/gpu/drm/i915/gt/intel_engine.h|1 - drivers/gpu/drm/i915/gt/intel_engine_cs.c |1 + drivers/gpu/drm/i915/gt/intel_engine_regs.h | 26 + .../drm/i915/gt/intel_execlists_submission.c |1 + drivers/gpu/drm/i915/gt/intel_ggtt.c |1 + drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c |2 + drivers/gpu/drm/i915/gt/intel_gt.c|3 +- .../gpu/drm/i915/gt/intel_gt_clock_utils.c|2 + drivers/gpu/drm/i915/gt/intel_gt_irq.c|2 +- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |2 + drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c |1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1538 drivers/gpu/drm/i915/gt/intel_gtt.c |1 + drivers/gpu/drm/i915/gt/intel_llc.c |1 + drivers/gpu/drm/i915/gt/intel_lrc.c |1 + drivers/gpu/drm/i915/gt/intel_mocs.c |2 +- drivers/gpu/drm/i915/gt/intel_rc6.c |2 + drivers/gpu/drm/i915/gt/intel_rc6.h |2 +- drivers/gpu/drm/i915/gt/intel_region_lmem.c |1 + drivers/gpu/drm/i915/gt/intel_reset.c |2 + .../gpu/drm/i915/gt/intel_ring_submission.c |1 + drivers/gpu/drm/i915/gt/intel_rps.c |1 + drivers/gpu/drm/i915/gt/intel_sseu.c |3 +- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c |1 + drivers/gpu/drm/i915/gt/intel_workarounds.c |1 + .../gpu/drm/i915/gt/intel_workarounds_types.h |2 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h |1 - drivers/gpu/drm/i915/gt/uc/intel_guc.c|1 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|1 + drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |1 + drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h|2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c |2 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c |1 + drivers/gpu/drm/i915/gt/uc/intel_huc.h|2 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |1 + drivers/gpu/drm/i915/gvt/aperture_gm.c|1 + drivers/gpu/drm/i915/gvt/cmd_parser.c |1 + drivers/gpu/drm/i915/gvt/display.c|1 + drivers/gpu/drm/i915/gvt/dmabuf.c |1 + drivers/gpu/drm/i915/gvt/edid.c |1 + drivers/gpu/drm/i915/gvt/fb_decoder.c |1 + drivers/gpu/drm/i915/gvt/gtt.c|2 + drivers/gpu/drm/i915/gvt/handlers.c |2 +
[Intel-gfx] [PATCH 3/6] drm/i915: Parameterize R_PWR_CLK_STATE register definition
At the moment we only use R_PWR_CLK_STATE in the context of the RCS
engine, but upcoming support for compute engines will start using
instances relative to the CCS engine base offsets. Let's parameterize
the register and move it to the engine reg header.
Cc: Jani Nikula
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/gem/selftests/i915_gem_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 15 +++
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 15 ---
5 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 80d99b9c694f..7cc4fa8f8c56 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -8,6 +8,7 @@
#include "gem/i915_gem_pm.h"
#include "gt/intel_engine_pm.h"
+#include "gt/intel_engine_regs.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_requests.h"
#include "gt/intel_reset.h"
@@ -894,7 +895,7 @@ static int rpcs_query_batch(struct drm_i915_gem_object
*rpcs, struct i915_vma *v
return PTR_ERR(cmd);
*cmd++ = MI_STORE_REGISTER_MEM_GEN8;
- *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE);
+ *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE(RENDER_RING_BASE));
*cmd++ = lower_32_bits(vma->node.start);
*cmd++ = upper_32_bits(vma->node.start);
*cmd = MI_BATCH_BUFFER_END;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 60511f310767..daf4a241cf77 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -77,6 +77,21 @@
#define RING_INSTPM(base) _MMIO((base) + 0xc0)
#define RING_CMD_CCTL(base)_MMIO((base) + 0xc4)
#define ACTHD(base)_MMIO((base) + 0xc8)
+#define GEN8_R_PWR_CLK_STATE(base) _MMIO((base) + 0xc8)
+#define GEN8_RPCS_ENABLE (1 << 31)
+#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
+#define GEN8_RPCS_S_CNT_SHIFT15
+#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f <<
GEN11_RPCS_S_CNT_SHIFT)
+#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
+#define GEN8_RPCS_SS_CNT_SHIFT 8
+#define GEN8_RPCS_SS_CNT_MASK(0x7 <<
GEN8_RPCS_SS_CNT_SHIFT)
+#define GEN8_RPCS_EU_MAX_SHIFT 4
+#define GEN8_RPCS_EU_MAX_MASK(0xf <<
GEN8_RPCS_EU_MAX_SHIFT)
+#define GEN8_RPCS_EU_MIN_SHIFT 0
+#define GEN8_RPCS_EU_MIN_MASK(0xf <<
GEN8_RPCS_EU_MIN_SHIFT)
+
#define RING_RESET_CTL(base) _MMIO((base) + 0xd0)
#define RESET_CTL_CAT_ERROR REG_BIT(2)
#define RESET_CTL_READY_TO_RESET REG_BIT(1)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index bdf09051b8a0..f161087f30d0 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -4,7 +4,7 @@
*/
#include "i915_drv.h"
-#include "intel_lrc_reg.h"
+#include "intel_engine_regs.h"
#include "intel_sseu.h"
void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 385e17f167ec..f25906f19d56 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2420,7 +2420,7 @@ gen12_configure_all_contexts(struct i915_perf_stream
*stream,
{
struct flex regs[] = {
{
- GEN8_R_PWR_CLK_STATE,
+ GEN8_R_PWR_CLK_STATE(RENDER_RING_BASE),
CTX_R_PWR_CLK_STATE,
},
};
@@ -2440,7 +2440,7 @@ lrc_configure_all_contexts(struct i915_perf_stream
*stream,
#define ctx_flexeuN(N) (ctx_flexeu0 + 2 * (N) + 1)
struct flex regs[] = {
{
- GEN8_R_PWR_CLK_STATE,
+ GEN8_R_PWR_CLK_STATE(RENDER_RING_BASE),
CTX_R_PWR_CLK_STATE,
},
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bfc54d920110..0cd690f2418a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -272,21 +272,6 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
#define GEN12_SFC_DONE_MAX 4
-#define GEN8_R_PWR_CLK_STATE _MMIO(0x20C8)
-#define GEN8_RPCS_ENABLE (1 << 31)
-#define
[Intel-gfx] [PATCH 2/6] drm/i915/perf: Express OA register ranges with i915_range
Let's use 'struct i915_range' to express sets of b-counter and mux
registers in the perf code. This makes the code more similar to how we
handle things like multicast register ranges, forcewake tables, shadow
tables, etc. and also lets us avoid needing symbolic register name
definitions for the various range end points. With this change, many of
the OA register definitions are no longer used in the code, so we can
drop their #define's for simplicity.
Cc: Jani Nikula
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_perf.c | 120 +---
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 360 ---
2 files changed, 77 insertions(+), 403 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 41cbfb399432..385e17f167ec 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3864,80 +3864,114 @@ static bool gen8_is_valid_flex_addr(struct i915_perf
*perf, u32 addr)
return false;
}
-#define ADDR_IN_RANGE(addr, start, end) \
- ((addr) >= (start) && \
-(addr) <= (end))
+static inline bool reg_in_range_table(u32 addr, const struct i915_range
*table) {
+ while (table->start || table->end) {
+ if (addr >= table->start && addr <= table->end)
+ return true;
+
+ table++;
+ }
-#define REG_IN_RANGE(addr, start, end) \
- ((addr) >= i915_mmio_reg_offset(start) && \
-(addr) <= i915_mmio_reg_offset(end))
+ return false;
+}
#define REG_EQUAL(addr, mmio) \
((addr) == i915_mmio_reg_offset(mmio))
-static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
-{
- return REG_IN_RANGE(addr, OASTARTTRIG1, OASTARTTRIG8) ||
- REG_IN_RANGE(addr, OAREPORTTRIG1, OAREPORTTRIG8) ||
- REG_IN_RANGE(addr, OACEC0_0, OACEC7_1);
-}
+static const struct i915_range gen7_oa_b_counters[] = {
+ { .start = 0x2710, .end = 0x272c }, /* OASTARTTRIG[1-8] */
+ { .start = 0x2740, .end = 0x275c }, /* OAREPORTTRIG[1-8] */
+ { .start = 0x2770, .end = 0x27ac }, /* OACEC[0-7][0-1] */
+ {}
+};
+
+static const struct i915_range gen12_oa_b_counters[] = {
+ { .start = 0x2b2c, .end = 0x2b2c }, /* GEN12_OAG_OA_PESS */
+ { .start = 0xd900, .end = 0xd91c }, /* GEN12_OAG_OASTARTTRIG[1-8] */
+ { .start = 0xd920, .end = 0xd93c }, /* GEN12_OAG_OAREPORTTRIG1[1-8]
*/
+ { .start = 0xd940, .end = 0xd97c }, /* GEN12_OAG_CEC[0-7][0-1] */
+ { .start = 0xdc00, .end = 0xdc3c }, /* GEN12_OAG_SCEC[0-7][0-1] */
+ { .start = 0xdc40, .end = 0xdc40 }, /* GEN12_OAG_SPCTR_CNF */
+ { .start = 0xdc44, .end = 0xdc44 }, /* GEN12_OAA_DBG_REG */
+ {}
+};
+
+static const struct i915_range gen7_oa_mux_regs[] = {
+ { .start = 0x91b8, .end = 0x91cc }, /* OA_PERFCNT[1-2],
OA_PERFMATRIX */
+ { .start = 0x9800, .end = 0x9888 }, /* MICRO_BP0_0 - NOA_WRITE */
+ { .start = 0xe180, .end = 0xe180 }, /* HALF_SLICE_CHICKEN2 */
+ {}
+};
-static bool gen7_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
+static const struct i915_range hsw_oa_mux_regs[] = {
+ { .start = 0x09e80, .end = 0x09ea4 }, /* HSW_MBVID2_NOA[0-9] */
+ { .start = 0x09ec0, .end = 0x09ec0 }, /* HSW_MBVID2_MISR0 */
+ { .start = 0x25100, .end = 0x2ff90 },
+ {}
+};
+
+static const struct i915_range chv_oa_mux_regs[] = {
+ { .start = 0x182300, .end = 0x1823a4 },
+ {}
+};
+
+static const struct i915_range gen8_oa_mux_regs[] = {
+ { .start = 0x0d00, .end = 0x0d2c }, /* RPM_CONFIG[0-1],
NOA_CONFIG[0-8] */
+ { .start = 0x20cc, .end = 0x20cc }, /* WAIT_FOR_RC6_EXIT */
+ {}
+};
+
+static const struct i915_range gen11_oa_mux_regs[] = {
+ { .start = 0x91c8, .end = 0x91dc }, /* OA_PERFCNT[3-4] */
+ {}
+};
+
+static const struct i915_range gen12_oa_mux_regs[] = {
+ { .start = 0x0d00, .end = 0x0d2c }, /* RPM_CONFIG[0-1],
NOA_CONFIG[0-8] */
+ { .start = 0x9840, .end = 0x9840 }, /* GDT_CHICKEN_BITS */
+ { .start = 0x9884, .end = 0x9888 }, /* NOA_WRITE */
+ { .start = 0x20cc, .end = 0x20cc }, /* WAIT_FOR_RC6_EXIT */
+ {}
+};
+
+static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
{
- return REG_EQUAL(addr, HALF_SLICE_CHICKEN2) ||
- REG_IN_RANGE(addr, MICRO_BP0_0, NOA_WRITE) ||
- REG_IN_RANGE(addr, OA_PERFCNT1_LO, OA_PERFCNT2_HI) ||
- REG_IN_RANGE(addr, OA_PERFMATRIX_LO, OA_PERFMATRIX_HI);
+ return reg_in_range_table(addr, gen7_oa_b_counters);
}
static bool gen8_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
- return gen7_is_valid_mux_addr(perf, addr) ||
- REG_EQUAL(addr, WAIT_FOR_RC6_EXIT) ||
- REG_IN_RANGE(addr, RPM_CONFIG0, NOA_CONFIG(8));
+
[Intel-gfx] [PATCH 1/6] drm/i915/perf: Move OA regs to their own header
The OA unit registers are only used by the perf code; move them to their own header file. Cc: Jani Nikula Cc: Umesh Nerlige Ramappa Cc: Lionel Landwerlin Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gvt/scheduler.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 1 + drivers/gpu/drm/i915/i915_perf_oa_regs.h | 497 +++ drivers/gpu/drm/i915/i915_reg.h | 485 -- 4 files changed, 499 insertions(+), 485 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_perf_oa_regs.h diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index 42a0c9ae0a73..ecd90dbd9544 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -43,6 +43,7 @@ #include "i915_drv.h" #include "i915_gem_gtt.h" +#include "i915_perf_oa_regs.h" #include "gvt.h" #define RING_CTX_OFF(x) \ diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 19647f0d6f14..41cbfb399432 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -208,6 +208,7 @@ #include "i915_drv.h" #include "i915_perf.h" +#include "i915_perf_oa_regs.h" /* HW requires this to be a power of two, between 128k and 16M, though driver * is currently generally designed assuming the largest 16M size is used such diff --git a/drivers/gpu/drm/i915/i915_perf_oa_regs.h b/drivers/gpu/drm/i915/i915_perf_oa_regs.h new file mode 100644 index ..5896ed43f5c4 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_perf_oa_regs.h @@ -0,0 +1,497 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2022 Intel Corporation + */ + +#ifndef __INTEL_PERF_OA_REGS__ +#define __INTEL_PERF_OA_REGS__ + +#include "i915_reg_defs.h" + +#define GEN7_OACONTROL _MMIO(0x2360) +#define GEN7_OACONTROL_CTX_MASK 0xF000 +#define GEN7_OACONTROL_TIMER_PERIOD_MASK 0x3F +#define GEN7_OACONTROL_TIMER_PERIOD_SHIFT 6 +#define GEN7_OACONTROL_TIMER_ENABLE (1 << 5) +#define GEN7_OACONTROL_FORMAT_A13 (0 << 2) +#define GEN7_OACONTROL_FORMAT_A29 (1 << 2) +#define GEN7_OACONTROL_FORMAT_A13_B8_C8(2 << 2) +#define GEN7_OACONTROL_FORMAT_A29_B8_C8(3 << 2) +#define GEN7_OACONTROL_FORMAT_B4_C8 (4 << 2) +#define GEN7_OACONTROL_FORMAT_A45_B8_C8(5 << 2) +#define GEN7_OACONTROL_FORMAT_B4_C8_A16(6 << 2) +#define GEN7_OACONTROL_FORMAT_C4_B8 (7 << 2) +#define GEN7_OACONTROL_FORMAT_SHIFT 2 +#define GEN7_OACONTROL_PER_CTX_ENABLE (1 << 1) +#define GEN7_OACONTROL_ENABLE (1 << 0) + +#define GEN8_OACTXID _MMIO(0x2364) + +#define GEN8_OA_DEBUG _MMIO(0x2B04) +#define GEN9_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS(1 << 5) +#define GEN9_OA_DEBUG_INCLUDE_CLK_RATIO (1 << 6) +#define GEN9_OA_DEBUG_DISABLE_GO_1_0_REPORTS (1 << 2) +#define GEN9_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS (1 << 1) + +#define GEN8_OACONTROL _MMIO(0x2B00) +#define GEN8_OA_REPORT_FORMAT_A12 (0 << 2) +#define GEN8_OA_REPORT_FORMAT_A12_B8_C8(2 << 2) +#define GEN8_OA_REPORT_FORMAT_A36_B8_C8(5 << 2) +#define GEN8_OA_REPORT_FORMAT_C4_B8 (7 << 2) +#define GEN8_OA_REPORT_FORMAT_SHIFT 2 +#define GEN8_OA_SPECIFIC_CONTEXT_ENABLE(1 << 1) +#define GEN8_OA_COUNTER_ENABLE (1 << 0) + +#define GEN8_OACTXCONTROL _MMIO(0x2360) +#define GEN8_OA_TIMER_PERIOD_MASK 0x3F +#define GEN8_OA_TIMER_PERIOD_SHIFT2 +#define GEN8_OA_TIMER_ENABLE (1 << 1) +#define GEN8_OA_COUNTER_RESUME(1 << 0) + +#define GEN7_OABUFFER _MMIO(0x23B0) /* R/W */ +#define GEN7_OABUFFER_OVERRUN_DISABLE (1 << 3) +#define GEN7_OABUFFER_EDGE_TRIGGER(1 << 2) +#define GEN7_OABUFFER_STOP_RESUME_ENABLE (1 << 1) +#define GEN7_OABUFFER_RESUME (1 << 0) + +#define GEN8_OABUFFER_UDW _MMIO(0x23b4) +#define GEN8_OABUFFER _MMIO(0x2b14) +#define GEN8_OABUFFER_MEM_SELECT_GGTT (1 << 0) /* 0: PPGTT, 1: GGTT */ + +#define GEN7_OASTATUS1 _MMIO(0x2364) +#define GEN7_OASTATUS1_TAIL_MASK 0xffc0 +#define GEN7_OASTATUS1_COUNTER_OVERFLOW(1 << 2) +#define GEN7_OASTATUS1_OABUFFER_OVERFLOW (1 << 1) +#define GEN7_OASTATUS1_REPORT_LOST(1 << 0) + +#define GEN7_OASTATUS2 _MMIO(0x2368) +#define GEN7_OASTATUS2_HEAD_MASK 0xffc0 +#define GEN7_OASTATUS2_MEM_SELECT_GGTT (1 << 0) /* 0: PPGTT, 1: GGTT */ + +#define GEN8_OASTATUS _MMIO(0x2b08) +#define GEN8_OASTATUS_TAIL_POINTER_WRAP(1 << 17) +#define GEN8_OASTATUS_HEAD_POINTER_WRAP(1 << 16) +#define GEN8_OASTATUS_OVERRUN_STATUS (1 << 3) +#define GEN8_OASTATUS_COUNTER_OVERFLOW (1 << 2) +#define GEN8_OASTATUS_OABUFFER_OVERFLOW(1 << 1) +#define GEN8_OASTATUS_REPORT_LOST (1 << 0) + +#define GEN8_OAHEADPTR _MMIO(0x2B0C) +#define GEN8_OAHEADPTR_MASK0xffc0 +#define GEN8_OATAILPTR _MMIO(0x2B10) +#define GEN8_OATAILPTR_MASK0xffc0 + +#define
[Intel-gfx] [PATCH 6/6] drm/i915: Only include i915_reg.h from .c files
Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much every file of the driver, even those that don't have any kind of register access. Let's delete the i915_reg.h include from all headers and include an explicit include from the .c files that truly need the register definitions; those that need a definition of i915_reg_t for a function definition can get it from i915_reg_defs.h instead. We also remove two non-register #define's (VLV_DISPLAY_BASE and GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the i915_reg.h include from a couple of headers. There's probably a lot more header dependency optimization possible, but the changes here roughly cut the number of files compiled after 'touch i915_reg.h' in half --- a good first step. Cc: Jani Nikula Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/display/g4x_hdmi.h | 2 +- drivers/gpu/drm/i915/display/intel_atomic.c | 1 + drivers/gpu/drm/i915/display/intel_bios.c | 1 + drivers/gpu/drm/i915/display/intel_bw.c | 1 + drivers/gpu/drm/i915/display/intel_crt.h | 2 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 +- drivers/gpu/drm/i915/display/intel_de.h | 1 - drivers/gpu/drm/i915/display/intel_display_power.h| 1 - drivers/gpu/drm/i915/display/intel_dmc.h | 2 +- drivers/gpu/drm/i915/display/intel_dp.h | 2 -- drivers/gpu/drm/i915/display/intel_dsb.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 1 + drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.h | 2 -- drivers/gpu/drm/i915/display/intel_lvds.h | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.h | 2 +- drivers/gpu/drm/i915/display/intel_tc.c | 1 + drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 1 + drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 1 + drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 1 + drivers/gpu/drm/i915/gt/intel_engine.h| 1 - drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_clock_utils.c| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 1 + drivers/gpu/drm/i915/gt/intel_llc.c | 1 + drivers/gpu/drm/i915/gt/intel_rc6.c | 1 + drivers/gpu/drm/i915/gt/intel_rc6.h | 2 +- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 + drivers/gpu/drm/i915/gt/intel_workarounds_types.h | 2 +- drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 1 - drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 1 + drivers/gpu/drm/i915/gt/uc/intel_huc.h| 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + drivers/gpu/drm/i915/gvt/aperture_gm.c| 1 + drivers/gpu/drm/i915/gvt/display.c| 1 + drivers/gpu/drm/i915/gvt/dmabuf.c | 1 + drivers/gpu/drm/i915/gvt/edid.c | 1 + drivers/gpu/drm/i915/gvt/fb_decoder.c | 1 + drivers/gpu/drm/i915/gvt/handlers.c | 1 + drivers/gpu/drm/i915/gvt/interrupt.c | 1 + drivers/gpu/drm/i915/gvt/interrupt.h | 2 +- drivers/gpu/drm/i915/gvt/mmio.c | 1 + drivers/gpu/drm/i915/gvt/mmio_context.h | 1 - drivers/gpu/drm/i915/i915_cmd_parser.c| 1 + drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf_types.h| 2 +- drivers/gpu/drm/i915/i915_reg.h | 3 --- drivers/gpu/drm/i915/i915_reg_defs.h | 4 drivers/gpu/drm/i915/intel_dram.c | 1 + drivers/gpu/drm/i915/intel_pcode.c| 1 + drivers/gpu/drm/i915/intel_pm.h | 1 - drivers/gpu/drm/i915/intel_sbi.c | 1 + drivers/gpu/drm/i915/intel_uncore.h | 2 +- drivers/gpu/drm/i915/vlv_sideband.c | 1 + 56 files changed, 49 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.h b/drivers/gpu/drm/i915/display/g4x_hdmi.h index 7aca14b602c6..db9a93bc9321 100644 --- a/drivers/gpu/drm/i915/display/g4x_hdmi.h +++ b/drivers/gpu/drm/i915/display/g4x_hdmi.h @@ -8,7 +8,7 @@ #include -#include "i915_reg.h" +#include "i915_reg_defs.h" enum port; struct drm_i915_private; diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c index 1080741d1561..093904065112 100644 --- a/drivers/gpu/drm/i915/display/intel_atomic.c +++ b/drivers/gpu/drm/i915/display/intel_atomic.c @@ -35,6
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix vma resource freeing (rev2)
On Thu, 2022-01-20 at 01:43 +, Patchwork wrote: > Patch Details > Series:drm/i915: Fix vma resource freeing > (rev2)URL:https://patchwork.freedesktop.org/series/99055/State:failur > e > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/index.html > CI Bug Log - changes from CI_DRM_0_full -> > Patchwork_22029_fullSummaryFAILURE > Serious unknown changes coming with Patchwork_22029_full absolutely > need to be > verified manually. > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_22029_full, please notify your bug team to > allow them > to document this new failure mode, which will reduce false positives > in CI. > Participating hosts (10 -> 10)No changes in participating hosts > Possible new issuesHere are the unknown changes that may have been introduced > in > Patchwork_22029_full: > IGT changesPossible regressions * > igt@gem_ctx_isolation@preservation-s3@vecs0:shard-skl: PASS -> >INCOMPLETE > Known issues Unrelated failure. /Thomas
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct (rev3)
== Series Details == Series: drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct (rev3) URL : https://patchwork.freedesktop.org/series/98816/ State : failure == Summary == CI Bug Log - changes from CI_DRM_1_full -> Patchwork_22032_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22032_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22032_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22032_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb3/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-iclb6/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22032_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002] / [i915#4856]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-tglb3/igt@gem_cre...@create-massive.html - shard-skl: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-skl9/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-hang: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-snb4/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_eio@kms: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#232]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_...@kms.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-tglb1/igt@gem_...@kms.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb1/igt@gem_exec_balan...@parallel.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-iclb7/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-kbl1/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][11] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-apl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-glk9/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-iclb8/igt@gem_exec_par...@secure-non-root.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-skl6/igt@gem_lmem_swapp...@heavy-verify-multi.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/shard-apl7/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613]) [21]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Don't try to map and fence large scanout buffers (v4)
== Series Details == Series: drm/i915/gem: Don't try to map and fence large scanout buffers (v4) URL : https://patchwork.freedesktop.org/series/99074/ State : failure == Summary == CI Bug Log - changes from CI_DRM_1_full -> Patchwork_22031_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22031_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22031_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22031_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@wide@vecs0: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-apl3/igt@gem_exec_schedule@w...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-apl1/igt@gem_exec_schedule@w...@vecs0.html Known issues Here are the changes found in Patchwork_22031_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-tglb: NOTRUN -> [DMESG-WARN][3] ([i915#3002] / [i915#4856]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-tglb1/igt@gem_cre...@create-massive.html * igt@gem_eio@kms: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#232]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_...@kms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-tglb8/igt@gem_...@kms.html * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb4/igt@gem_exec_balan...@parallel-contexts.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-iclb3/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-apl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-vebox: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271]) +135 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-skl8/igt@gem_exec_par...@no-vebox.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#112283]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-iclb8/igt@gem_exec_par...@secure-non-root.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-skl4/igt@gem_lmem_swapp...@heavy-verify-multi.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-apl6/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_userptr_blits@vma-merge: - shard-skl: NOTRUN -> [FAIL][18] ([i915#3318]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/shard-skl6/igt@gem_userptr_bl...@vma-merge.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / [i915#716]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-skl2/igt@gen9_exec_pa...@allowed-single.html [20]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: Eliminate remnant GEN references (rev2)
== Series Details ==
Series: drm/i915/dmc: Eliminate remnant GEN references (rev2)
URL : https://patchwork.freedesktop.org/series/98166/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_1 -> Patchwork_22033
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/index.html
Participating hosts (45 -> 40)
--
Missing(5): bat-dg1-5 fi-bsw-cyan fi-icl-u2 fi-pnv-d510 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22033 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-tgl-1115g4: [PASS][2] -> [FAIL][3] ([i915#1888])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][4] -> [INCOMPLETE][5] ([i915#4547])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][6] -> [DMESG-FAIL][7] ([i915#4494])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][8] ([i915#3921]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][10] ([i915#4269]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/fi-cml-u2/igt@kms_frontbuffer_track...@basic.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#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
Build changes
-
* Linux: CI_DRM_1 -> Patchwork_22033
CI-20190529: 20190529
CI_DRM_1: fe44f8bdb12374a6168cb561834eb714097f5e5f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22033: 7ad736672977b9df12ad8236bc04a03eafdec5bc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7ad736672977 drm/i915/dmc: Eliminate remnant GEN references
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22033/index.html
[Intel-gfx] ✗ Fi.CI.IGT: failure for Flush G2H handler during a GT reset (rev3)
== Series Details == Series: Flush G2H handler during a GT reset (rev3) URL : https://patchwork.freedesktop.org/series/98855/ State : failure == Summary == CI Bug Log - changes from CI_DRM_1_full -> Patchwork_22030_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22030_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22030_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22030_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@fences-dpms: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb7/igt@i915_pm_...@fences-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-iclb7/igt@i915_pm_...@fences-dpms.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: - shard-iclb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb3/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions-varying-size.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-iclb7/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions-varying-size.html Known issues Here are the changes found in Patchwork_22030_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-tglb: NOTRUN -> [DMESG-WARN][5] ([i915#3002] / [i915#4856]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-tglb3/igt@gem_cre...@create-massive.html - shard-skl: NOTRUN -> [DMESG-WARN][6] ([i915#3002]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-skl6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-hang: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-snb6/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_eio@kms: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#232]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_...@kms.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-tglb8/igt@gem_...@kms.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-iclb1/igt@gem_exec_balan...@parallel.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-iclb8/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][12] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-apl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-vebox: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271]) +188 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-skl10/igt@gem_exec_par...@no-vebox.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#112283]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-iclb6/igt@gem_exec_par...@secure-non-root.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-skl4/igt@gem_lmem_swapp...@heavy-verify-multi.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/shard-apl2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gen9_exec_parse@batch-invalid-length: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#2856]) [20]:
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Eliminate remnant GEN references
On Tue, 2022-01-18 at 13:37 -0800, Lucas De Marchi wrote: > On Thu, Dec 23, 2021 at 03:18:57AM +, Tolakanahalli Pradeep, > Madhumitha wrote: > > On Fri, 2021-12-17 at 21:37 +, Yokoyama, Caz wrote: > > > On Thu, 2021-12-16 at 19:41 -0800, Madhumitha Tolakanahalli > > > Pradeep > > > wrote: > > > > Replace GEN with DISPLAY_VER, in line with the naming > > > > convention > > > > followed in the i915 driver code. > > > > > > > > Signed-off-by: Madhumitha Tolakanahalli Pradeep < > > > > madhumitha.tolakanahalli.prad...@intel.com> > > I was checking to apply this today, but BAT is failing on CI and it > didn't trigger the full run. Error seems unrelated and I don't think > this would trigger any error in the machines in CI, but I'd prefer to > merge this with a clean run. > > Can you re-submit or trigger it again via patchwork if the patch > still > applies? > > thanks > Lucas De Marchi The error does seem pretty random. I've triggered a rerun, awaiting results. Thanks! - Madhumitha
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
On Wed, 17 Nov 2021 13:49:26 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/drm/gpu_scheduler.h:316: warning: Function parameter or member 'work'
> not described in 'drm_sched_job'
>
> Introduced by commit
>
> 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
I am still seeing this warning.
--
Cheers,
Stephen Rothwell
pgpUZZWoa8Sj4.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
On Fri, 15 Oct 2021 21:01:04 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/drm/drm_modeset_lock.h:74: warning: Function parameter or member
> 'stack_depot' not described in 'drm_modeset_acquire_ctx'
>
> Introduced by commit
>
> cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks
> without backoff")
I am still getting this warning.
--
Cheers,
Stephen Rothwell
pgpyUahEJnvrH.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
On Fri, 15 Oct 2021 20:54:22 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/gpu/drm-kms-helpers:451:
> /home/sfr/next/next/drivers/gpu/drm/drm_privacy_screen.c:270: WARNING: Inline
> emphasis start-string without end-string.
>
> Introduced by commit
>
> 8a12b170558a ("drm/privacy-screen: Add notifier support (v2)")
I am still getting this warning.
--
Cheers,
Stephen Rothwell
pgpgA7hyEGA4L.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix vma resource freeing (rev2)
== Series Details == Series: drm/i915: Fix vma resource freeing (rev2) URL : https://patchwork.freedesktop.org/series/99055/ State : failure == Summary == CI Bug Log - changes from CI_DRM_0_full -> Patchwork_22029_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22029_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22029_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22029_full: ### IGT changes ### Possible regressions * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-skl8/igt@gem_ctx_isolation@preservation...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-skl6/igt@gem_ctx_isolation@preservation...@vecs0.html Known issues Here are the changes found in Patchwork_22029_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-hang: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-snb6/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_eio@kms: - shard-skl: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-skl8/igt@gem_...@kms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-skl8/igt@gem_...@kms.html * igt@gem_exec_balancer@parallel-out-fence: - shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-iclb4/igt@gem_exec_balan...@parallel-out-fence.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-iclb8/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk7/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-kbl3/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-apl8/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][22] -> [DMESG-WARN][23] ([i915#118]) [22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct (rev3)
== Series Details == Series: drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct (rev3) URL : https://patchwork.freedesktop.org/series/98816/ State : success == Summary == CI Bug Log - changes from CI_DRM_1 -> Patchwork_22032 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/index.html Participating hosts (45 -> 42) -- Additional (1): fi-kbl-soraka Missing(4): fi-bsw-cyan bat-jsl-2 fi-bdw-samus fi-pnv-d510 Known issues Here are the changes found in Patchwork_22032 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3@smem: - fi-tgl-1115g4: [PASS][4] -> [FAIL][5] ([i915#1888]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [PASS][9] -> [DMESG-FAIL][10] ([i915#4494]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - bat-dg1-6: [PASS][11] -> [DMESG-FAIL][12] ([i915#4494]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@late_gt_pm: - fi-bsw-n3050: [PASS][13] -> [DMESG-FAIL][14] ([i915#2927] / [i915#3428]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-skl-6600u: NOTRUN -> [SKIP][17] ([fdo#109271]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-skl-6600u/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-bsw-n3050: NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#1436] / [i915#3428] / [i915#4312]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-bsw-n3050/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-icl-u2: [DMESG-WARN][19] -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22032/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][21] ([i915#3921]) -> [PASS][22] [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Don't try to map and fence large scanout buffers (v4)
== Series Details == Series: drm/i915/gem: Don't try to map and fence large scanout buffers (v4) URL : https://patchwork.freedesktop.org/series/99074/ State : success == Summary == CI Bug Log - changes from CI_DRM_1 -> Patchwork_22031 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/index.html Participating hosts (45 -> 42) -- Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1 Known issues Here are the changes found in Patchwork_22031 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_suspend@basic-s3: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][3] ([i915#4547]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_suspend@basic-s3@smem: - fi-tgl-1115g4: [PASS][4] -> [FAIL][5] ([i915#1888]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [PASS][6] -> [DMESG-FAIL][7] ([i915#4494]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - bat-dg1-6: [PASS][8] -> [DMESG-FAIL][9] ([i915#4494]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-icl-u2: [DMESG-WARN][10] -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][12] ([i915#3921]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_1 -> Patchwork_22031 CI-20190529: 20190529 CI_DRM_1: fe44f8bdb12374a6168cb561834eb714097f5e5f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22031: 1efd01b0458b6a6ce0fb889dbf33022b31c3d8d5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1efd01b0458b drm/i915/gem: Don't try to map and fence large scanout buffers (v4) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22031/index.html
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add support for querying hw info that UMDs need
On 1/19/2022 16:42, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* Add support for querying hw info that UMDs need
*URL:* https://patchwork.freedesktop.org/series/99060/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/index.html
CI Bug Log - changes from CI_DRM_0_full -> Patchwork_22027_full
Summary
*FAILURE*
Serious unknown changes coming with Patchwork_22027_full absolutely
need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22027_full, please notify your bug team to
allow them
to document this new failure mode, which will reduce false positives
in CI.
Participating hosts (10 -> 10)
No changes in participating hosts
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_22027_full:
IGT changes
Possible regressions
*
{igt@i915_query@hwconfig_table} (NEW):
o
shard-tglb: NOTRUN -> SKIP
o
shard-iclb: NOTRUN -> SKIP
Expected. The table only exists on ALD-P and later. So TGL/ICL will be
skips.
*
o
*
igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
o shard-tglb: PASS
-> INCOMPLETE
Not related to this change.
John.
*
New tests
New tests have been introduced between CI_DRM_0_full and
Patchwork_22027_full:
New IGT tests (1)
* igt@i915_query@hwconfig_table:
o Statuses : 7 skip(s)
o Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_22027_full that come from
known issues:
CI changes
Issues hit
* boot:
o shard-glk: (PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
,
PASS
)
-> (PASS
,
PASS
,
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add support for querying hw info that UMDs need
== Series Details ==
Series: Add support for querying hw info that UMDs need
URL : https://patchwork.freedesktop.org/series/99060/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_0_full -> Patchwork_22027_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22027_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22027_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22027_full:
### IGT changes ###
Possible regressions
* {igt@i915_query@hwconfig_table} (NEW):
- shard-tglb: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/shard-tglb6/igt@i915_query@hwconfig_table.html
- shard-iclb: NOTRUN -> [SKIP][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/shard-iclb4/igt@i915_query@hwconfig_table.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-tglb8/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/shard-tglb7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
New tests
-
New tests have been introduced between CI_DRM_0_full and
Patchwork_22027_full:
### New IGT tests (1) ###
* igt@i915_query@hwconfig_table:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_22027_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][5], [PASS][6], [PASS][7], [PASS][8],
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14],
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20],
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26],
[PASS][27], [PASS][28], [PASS][29]) -> ([PASS][30], [PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [FAIL][43], [PASS][44],
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
[PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk8/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk7/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk7/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk2/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/shard-glk1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/shard-glk3/boot.html
[31]:
[Intel-gfx] ✓ Fi.CI.BAT: success for Flush G2H handler during a GT reset (rev3)
== Series Details ==
Series: Flush G2H handler during a GT reset (rev3)
URL : https://patchwork.freedesktop.org/series/98855/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_1 -> Patchwork_22030
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/index.html
Participating hosts (45 -> 42)
--
Additional (1): fi-kbl-soraka
Missing(4): fi-bsw-cyan fi-icl-u2 fi-bdw-samus fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22030:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_softpin@allocator-basic-reserve:
- {bat-jsl-2}:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-jsl-2/igt@gem_soft...@allocator-basic-reserve.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/bat-jsl-2/igt@gem_soft...@allocator-basic-reserve.html
Known issues
Here are the changes found in Patchwork_22030 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +8 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][4] -> [INCOMPLETE][5] ([i915#4547])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][9] -> [DMESG-FAIL][10] ([i915#4494])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Warnings
* igt@runner@aborted:
- fi-skl-6600u: [FAIL][13] ([i915#4312]) -> [FAIL][14] ([i915#2722] /
[i915#4312])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_1/fi-skl-6600u/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22030/fi-skl-6600u/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-
* Linux: CI_DRM_1 -> Patchwork_22030
CI-20190529: 20190529
CI_DRM_1: fe44f8bdb12374a6168cb561834eb714097f5e5f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @
Re: [Intel-gfx] [PATCH 0/7] DRM kmap() fixes and kmap_local_page() conversions
On Wed, Jan 19, 2022 at 06:24:22PM +0100, Daniel Vetter wrote: > On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira Weiny wrote: > > On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote: > > > From: Ira Weiny > > > > > > This series starts by converting the last easy kmap() uses to > > > kmap_local_page(). > > > > > > There is one more call to kmap() wrapped in ttm_bo_kmap_ttm(). > > > Unfortunately, > > > ttm_bo_kmap_ttm() is called in a number of different ways including some > > > which > > > are not thread local. I have a patch to convert that call. However, it > > > is not > > > straight forward so it is not included in this series. > > > > > > The final 2 patches fix bugs found while working on the ttm_bo_kmap_ttm() > > > conversion. > > > > Gentile ping on this series? Will it make this merge window? > > I think this fell through the cracks and so no. Note that generally we > feature-freeze drm tree around -rc6 anyway for the upcoming merge window, > so you were cutting this all a bit close anyway. Ok, No problem. I just had not heard if this was picked up or not. > Also looks like the ttm > kmap caching question didn't get resolved? I'm sorry I thought it was resolve for this series. Christian said the patches in this series were "a good bug fix" even if not strictly necessary.[1] Beyond this series I was discussing where to go from here, and is it possible to go further with more changes.[2] At the moment I don't think I will. Christian did I misunderstand? I can drop patch 6 and 7 if they are not proper bug fixes or at least clarifications to the code. Ira [1] https://lore.kernel.org/lkml/c3b173ea-6509-ebbe-b5f9-eeb29f1ce...@amd.com/ [2] https://lore.kernel.org/lkml/20211215210949.gw3538...@iweiny-desk2.sc.intel.com/ > > Anyway if patches are stuck resend with RESEND and if people still don't > pick them up poke me and I'll apply as fallback. > > Cheers, Daniel > > > > > Thanks, > > Ira > > > > > > > > > > > Ira Weiny (7): > > > drm/i915: Replace kmap() with kmap_local_page() > > > drm/amd: Replace kmap() with kmap_local_page() > > > drm/gma: Remove calls to kmap() > > > drm/radeon: Replace kmap() with kmap_local_page() > > > drm/msm: Alter comment to use kmap_local_page() > > > drm/amdgpu: Ensure kunmap is called on error > > > drm/radeon: Ensure kunmap is called on error > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 > > > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 + > > > drivers/gpu/drm/gma500/gma_display.c | 6 ++ > > > drivers/gpu/drm/gma500/mmu.c | 8 > > > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++-- > > > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 > > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- > > > drivers/gpu/drm/i915/gt/shmem_utils.c | 4 ++-- > > > drivers/gpu/drm/i915/i915_gem.c | 8 > > > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > > > drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++-- > > > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > > > drivers/gpu/drm/radeon/radeon_uvd.c | 1 + > > > 13 files changed, 32 insertions(+), 32 deletions(-) > > > > > > -- > > > 2.31.1 > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Flush G2H handler during a GT reset (rev3)
== Series Details == Series: Flush G2H handler during a GT reset (rev3) URL : https://patchwork.freedesktop.org/series/98855/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH v4 RESEND] drm/i915/gem: Don't try to map and fence large scanout buffers (v4)
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 88 ++---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
2 files changed, 60 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e3a2c2a0e156..95ec972f8c8a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,6 +46,7 @@
#include "gem/i915_gem_mman.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -876,6 +877,63 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(>vma.lock);
}
+static bool i915_gem_obj_too_big(struct drm_i915_gem_object *obj,
+u64 alignment)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+ struct drm_mm_node *hole;
+ u64 hole_start, hole_end, start, end;
+ u64 fence_size, fence_alignment;
+ unsigned int count = 0;
+
+ /*
+* If the required space is larger than the available
+* aperture, we will not able to find a slot for the
+* object and unbinding the object now will be in
+* vain. Worse, doing so may cause us to ping-pong
+* the object in and out of the Global GTT and
+* waste a lot of cycles under the mutex.
+*/
+ if (obj->base.size > ggtt->mappable_end)
+ return true;
+
+ if (HAS_GMCH(i915) || DISPLAY_VER(i915) < 11 ||
+ !i915_gem_object_is_framebuffer(obj))
+ return false;
+
+ fence_size = i915_gem_fence_size(i915, obj->base.size,
+i915_gem_object_get_tiling(obj),
+i915_gem_object_get_stride(obj));
+ fence_alignment = i915_gem_fence_alignment(i915, obj->base.size,
+
i915_gem_object_get_tiling(obj),
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix vma resource freeing (rev2)
== Series Details ==
Series: drm/i915: Fix vma resource freeing (rev2)
URL : https://patchwork.freedesktop.org/series/99055/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_0 -> Patchwork_22029
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/index.html
Participating hosts (45 -> 42)
--
Missing(3): fi-bsw-cyan fi-icl-u2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22029 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +31 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][2] -> [INCOMPLETE][3] ([i915#4418])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [PASS][6] -> [DMESG-FAIL][7] ([i915#4494])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@runner@aborted:
- bat-dg1-5: NOTRUN -> [FAIL][9] ([i915#4214] / [i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/bat-dg1-5/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] /
[i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- fi-tgl-1115g4: [FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html
Warnings
* igt@i915_selftest@live:
- fi-skl-6600u: [INCOMPLETE][13] ([i915#4794]) -> [FAIL][14]
([i915#4547])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-skl-6600u/igt@i915_selft...@live.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-skl-6600u/igt@i915_selft...@live.html
* igt@runner@aborted:
- fi-skl-6600u: [FAIL][15] ([i915#1436] / [i915#2722] / [i915#4312])
-> [FAIL][16] ([i915#1436] / [i915#4312])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-skl-6600u/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22029/fi-skl-6600u/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#4214]: https://gitlab.freedesktop.org/drm/intel/issues/4214
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4794]: https://gitlab.freedesktop.org/drm/intel/issues/4794
Build changes
-
* Linux: CI_DRM_0 -> Patchwork_22029
CI-20190529: 20190529
CI_DRM_0: 773fc0fe92f90fa7bbbcdccffa7436259bbab22f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22029:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
== Series Details ==
Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
URL : https://patchwork.freedesktop.org/series/99052/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11109_full -> Patchwork_22024_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22024_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22024_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22024_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_capture@pi@vcs0:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglb3/igt@gem_exec_capture@p...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-tglb7/igt@gem_exec_capture@p...@vcs0.html
* igt@i915_selftest@live@execlists:
- shard-skl: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-skl2/igt@i915_selftest@l...@execlists.html
* igt@kms_flip@flip-vs-fences-interruptible@b-vga1:
- shard-snb: [PASS][4] -> [DMESG-WARN][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-snb4/igt@kms_flip@flip-vs-fences-interrupti...@b-vga1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-snb7/igt@kms_flip@flip-vs-fences-interrupti...@b-vga1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_userptr_blits@sd-probe:
- {shard-dg1}:NOTRUN -> [SKIP][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-dg1-18/igt@gem_userptr_bl...@sd-probe.html
* igt@prime_busy@hang@rcs0:
- {shard-tglu}: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglu-8/igt@prime_busy@h...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-tglu-7/igt@prime_busy@h...@rcs0.html
* igt@runner@aborted:
- {shard-tglu}: ([FAIL][9], [FAIL][10], [FAIL][11]) ([i915#3002] /
[i915#3690] / [i915#4312]) -> ([FAIL][12], [FAIL][13]) ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglu-7/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglu-2/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglu-4/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-tglu-1/igt@run...@aborted.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-tglu-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_22024_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][14] -> [SKIP][15] ([i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-iclb2/igt@feature_discov...@psr2.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-iclb5/igt@feature_discov...@psr2.html
* igt@gem_ctx_persistence@engines-hang:
- shard-snb: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1099])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-snb7/igt@gem_ctx_persiste...@engines-hang.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [PASS][17] -> [TIMEOUT][18] ([i915#3063])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglb6/igt@gem_...@in-flight-contexts-immediate.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-tglb2/igt@gem_...@in-flight-contexts-immediate.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#232]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-tglb6/igt@gem_...@unwedge-stress.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-tglb8/igt@gem_...@unwedge-stress.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][21] -> [SKIP][22] ([i915#4525]) +2 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/shard-iclb1/igt@gem_exec_balan...@parallel-out-fence.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/shard-iclb7/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_capture@pi@rcs0:
-
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
> > except '"no\0\0yes" + v * 4' works a bit better. > > Is it a C code obfuscation contest? That would be: return &(v * 3)["no\0yes"]; :-) - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [Intel-gfx] [PATCH 0/6] drm/i915: Extend parse_ddi_port() to all g4x+ platforms
On Fri, Dec 17, 2021 at 05:53:57PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Quick attempt at unifying the VBT DDI parsing to all g4x+ > platforms. > > Note that we'll still use the hardware straps as the primary > source of port presence information on old platforms since the > device type bits in VBT tend to be often a bit wrong (for DP++ > ports at least). Hopefully the rest of the information (mainly > aux_ch/ddc_pin) are correct. > > Only very slightly smoke tested on SNB so far. Smoked this a bit more on a set of ctg,ilk,snb,ivb and all seems good so far. Pushed to drm-intel-next with fingers and toes crossed. Thanks for the review. > > Ville Syrjälä (6): > drm/i915/bios: Introduce has_ddi_port_info() > drm/i915/bios: Use i915->vbt.ports[] on CHV > drm/i915/bios: Use i915->vbt.ports[] for all g4x+ > drm/i915/bios: Throw out the !has_ddi_port_info() codepaths > drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITS > drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports > > drivers/gpu/drm/i915/display/intel_bios.c | 117 +++--- > drivers/gpu/drm/i915/display/intel_hdmi.c | 8 ++ > drivers/gpu/drm/i915/display/intel_vbt_defs.h | 26 > 3 files changed, 28 insertions(+), 123 deletions(-) > > -- > 2.32.0 -- Ville Syrjälä Intel
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct (rev2)
== Series Details == Series: drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct (rev2) URL : https://patchwork.freedesktop.org/series/98816/ State : failure == Summary == CI Bug Log - changes from CI_DRM_0 -> Patchwork_22028 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22028 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22028, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/index.html Participating hosts (45 -> 43) -- Additional (1): fi-pnv-d510 Missing(3): fi-bsw-cyan fi-icl-u2 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22028: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22028 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +31 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [PASS][4] -> [FAIL][5] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: [PASS][6] -> [DMESG-FAIL][7] ([i915#4494]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-bsw-n3050: [PASS][9] -> [FAIL][10] ([i915#2122]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html * igt@prime_vgem@basic-userptr: - fi-pnv-d510:NOTRUN -> [SKIP][11] ([fdo#109271]) +57 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/fi-pnv-d510/igt@prime_v...@basic-userptr.html Warnings * igt@runner@aborted: - fi-skl-6600u: [FAIL][12] ([i915#1436] / [i915#2722] / [i915#4312]) -> [FAIL][13] ([i915#4312]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-skl-6600u/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/fi-skl-6600u/igt@run...@aborted.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_0 -> Patchwork_22028 CI-20190529: 20190529 CI_DRM_0: 773fc0fe92f90fa7bbbcdccffa7436259bbab22f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22028: 31ae216a16d1449c11d15b9321702a4cea7b207f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 31ae216a16d1 drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22028/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for querying hw info that UMDs need
== Series Details ==
Series: Add support for querying hw info that UMDs need
URL : https://patchwork.freedesktop.org/series/99060/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_0 -> Patchwork_22027
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/index.html
Participating hosts (45 -> 42)
--
Missing(3): fi-bsw-cyan bat-jsl-2 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22027:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_hangman@error-state-basic:
- {bat-adlp-6}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-adlp-6/igt@i915_hang...@error-state-basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/bat-adlp-6/igt@i915_hang...@error-state-basic.html
Known issues
Here are the changes found in Patchwork_22027 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-ilk-650: [PASS][3] -> [FAIL][4] ([i915#4684])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-ilk-650/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-ilk-650/boot.html
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271]) +31 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][7] -> [DMESG-FAIL][8] ([i915#4494])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [PASS][9] -> [DMESG-FAIL][10] ([i915#4494])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][11] -> [INCOMPLETE][12] ([i915#3921])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][14] ([i915#4269]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][16] ([fdo#109271]) -> [FAIL][17] ([i915#579])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22027/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4684]: https://gitlab.freedesktop.org/drm/intel/issues/4684
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Build changes
-
* IGT: IGT_6329 -> IGTPW_6562
* Linux: CI_DRM_0 -> Patchwork_22027
CI-20190529: 20190529
CI_DRM_0: 773fc0fe92f90fa7bbbcdccffa7436259bbab22f @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_6562: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6562/index.html
IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @
[Intel-gfx] [PATCH 3/3] drm/i915/guc: Flush G2H handler during a GT reset
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which in turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
v2:
(John Harrison)
- Fix typo in commit message (s/is/in)
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 514b3060b141..406dd2e3f5a9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1396,8 +1396,6 @@ static void guc_flush_destroyed_contexts(struct intel_guc
*guc);
void intel_guc_submission_reset_prepare(struct intel_guc *guc)
{
- int i;
-
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
return;
@@ -1414,21 +1412,7 @@ void intel_guc_submission_reset_prepare(struct intel_guc
*guc)
guc_flush_submissions(guc);
guc_flush_destroyed_contexts(guc);
-
- /*
-* Handle any outstanding G2Hs before reset. Call IRQ handler directly
-* each pass as interrupt have been disabled. We always scrub for
-* outstanding G2H as it is possible for outstanding_submission_g2h to
-* be incremented after the context state update.
-*/
- for (i = 0; i < 4 && atomic_read(>outstanding_submission_g2h);
++i) {
- intel_guc_to_host_event_handler(guc);
-#define wait_for_reset(guc, wait_var) \
- intel_guc_wait_for_pending_msg(guc, wait_var, false, (HZ / 20))
- do {
- wait_for_reset(guc, >outstanding_submission_g2h);
- } while (!list_empty(>ct.requests.incoming));
- }
+ flush_work(>ct.requests.worker);
scrub_guc_desc_for_outstanding_g2h(guc);
}
--
2.34.1
[Intel-gfx] [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT when an engine reset failure is received to break this
circular dependency.
v2:
(John Harrison)
- Store engine reset mask
- Fix typo in commit message
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 9 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +--
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d26a86fe557..c4a9fc7dd246 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -119,6 +119,15 @@ struct intel_guc {
* function as it might be in an atomic context (no sleeping)
*/
struct work_struct destroyed_worker;
+ /**
+* @reset_worker: worker to trigger a GT reset after an engine
+* reset fails
+*/
+ struct work_struct reset_worker;
+ /**
+* @reset_mask: mask of engines that failed to reset
+*/
+ intel_engine_mask_t reset_mask;
} submission_state;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3918f1be114f..514b3060b141 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1731,6 +1731,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
*guc)
}
static void destroyed_worker_func(struct work_struct *w);
+static void reset_worker_func(struct work_struct *w);
/*
* Set up the memory resources to be shared with the GuC (via the GGTT)
@@ -1761,6 +1762,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_LIST_HEAD(>submission_state.destroyed_contexts);
INIT_WORK(>submission_state.destroyed_worker,
destroyed_worker_func);
+ INIT_WORK(>submission_state.reset_worker,
+ reset_worker_func);
guc->submission_state.guc_ids_bitmap =
bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
@@ -4026,6 +4029,26 @@ guc_lookup_engine(struct intel_guc *guc, u8 guc_class,
u8 instance)
return gt->engine_class[engine_class][instance];
}
+static void reset_worker_func(struct work_struct *w)
+{
+ struct intel_guc *guc = container_of(w, struct intel_guc,
+submission_state.reset_worker);
+ struct intel_gt *gt = guc_to_gt(guc);
+ intel_engine_mask_t reset_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(>submission_state.lock, flags);
+ reset_mask = guc->submission_state.reset_mask;
+ guc->submission_state.reset_mask = 0;
+ spin_unlock_irqrestore(>submission_state.lock, flags);
+
+ if (likely(reset_mask))
+ intel_gt_handle_error(gt, reset_mask,
+ I915_ERROR_CAPTURE,
+ "GuC failed to reset engine mask=0x%x\n",
+ reset_mask);
+}
+
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len)
{
@@ -4033,6 +4056,7 @@ int intel_guc_engine_failure_process_msg(struct intel_guc
*guc,
struct intel_gt *gt = guc_to_gt(guc);
u8 guc_class, instance;
u32 reason;
+ unsigned long flags;
if (unlikely(len != 3)) {
drm_err(>i915->drm, "Invalid length %u", len);
@@ -4057,10 +4081,15 @@ int intel_guc_engine_failure_process_msg(struct
intel_guc *guc,
drm_err(>i915->drm, "GuC engine reset request failed on %d:%d (%s)
because 0x%08X",
guc_class, instance, engine->name, reason);
- intel_gt_handle_error(gt, engine->mask,
- I915_ERROR_CAPTURE,
- "GuC failed to reset %s (reason=0x%08x)\n",
- engine->name, reason);
+ spin_lock_irqsave(>submission_state.lock, flags);
+ guc->submission_state.reset_mask |= engine->mask;
+ spin_unlock_irqrestore(>submission_state.lock, flags);
+
+ /*
+* A GT reset flushes this worker queue (G2H handler) so we must use
+* another worker to trigger a GT reset.
+*/
+ queue_work(system_unbound_wq, >submission_state.reset_worker);
return 0;
}
--
2.34.1
[Intel-gfx] [PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL to fully decouple the error capture from fence signalling.
v2:
(John Harrison)
- Fix typo in commit message (s/do/to)
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 67f3515f07e7..aee42eae4729 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1516,7 +1516,7 @@ capture_engine(struct intel_engine_cs *engine,
struct i915_request *rq = NULL;
unsigned long flags;
- ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);
+ ee = intel_engine_coredump_alloc(engine, ALLOW_FAIL);
if (!ee)
return NULL;
--
2.34.1
[Intel-gfx] [PATCH 0/3] Flush G2H handler during a GT reset
After a small fix to error capture code, we now can flush G2H during a GT reset which simplifies code and seals some extreme corner case races. v2: (CI) - Don't trigger GT reset from G2H handler v3: - Address John Harrison's comments Signed-off-by: Matthew Brost Matthew Brost (3): drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915/guc: Add work queue to trigger a GT reset drm/i915/guc: Flush G2H handler during a GT reset drivers/gpu/drm/i915/gt/uc/intel_guc.h| 9 +++ .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 55 --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 3 files changed, 44 insertions(+), 22 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH] drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct
Realized that the GuC multi-lrc fini breadcrumb emit code is very
delicate as the math this code does relies on functions it calls to emit
a certain number of DWs. Add a few GEM_BUG_ONs to assert the math is
correct.
v2:
- Rebase + resend for CI
(Checkpatch)
- Fix blank line warning
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 33 +++
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3918f1be114f..650efd3d3a48 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4429,27 +4429,31 @@ static inline bool skip_handshake(struct i915_request
*rq)
return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, >fence.flags);
}
+#define NON_SKIP_LEN 6
static u32 *
emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
u32 *cs)
{
struct intel_context *ce = rq->context;
+ __maybe_unused u32 *before_fini_breadcrumb_user_interrupt_cs;
+ __maybe_unused u32 *start_fini_breadcrumb_cs = cs;
GEM_BUG_ON(!intel_context_is_parent(ce));
if (unlikely(skip_handshake(rq))) {
/*
* NOP everything in
__emit_fini_breadcrumb_parent_no_preempt_mid_batch,
-* the -6 comes from the length of the emits below.
+* the NON_SKIP_LEN comes from the length of the emits below.
*/
memset(cs, 0, sizeof(u32) *
- (ce->engine->emit_fini_breadcrumb_dw - 6));
- cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ (ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN));
+ cs += ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN;
} else {
cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
}
/* Emit fini breadcrumb */
+ before_fini_breadcrumb_user_interrupt_cs = cs;
cs = gen8_emit_ggtt_write(cs,
rq->fence.seqno,
i915_request_active_timeline(rq)->hwsp_offset,
@@ -4459,6 +4463,12 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct
i915_request *rq,
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_NOOP;
+ /* Ensure our math for skip + emit is correct */
+ GEM_BUG_ON(before_fini_breadcrumb_user_interrupt_cs + NON_SKIP_LEN !=
+ cs);
+ GEM_BUG_ON(start_fini_breadcrumb_cs +
+ ce->engine->emit_fini_breadcrumb_dw != cs);
+
rq->tail = intel_ring_offset(rq, cs);
return cs;
@@ -4501,22 +4511,25 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct
i915_request *rq,
u32 *cs)
{
struct intel_context *ce = rq->context;
+ __maybe_unused u32 *before_fini_breadcrumb_user_interrupt_cs;
+ __maybe_unused u32 *start_fini_breadcrumb_cs = cs;
GEM_BUG_ON(!intel_context_is_child(ce));
if (unlikely(skip_handshake(rq))) {
/*
* NOP everything in
__emit_fini_breadcrumb_child_no_preempt_mid_batch,
-* the -6 comes from the length of the emits below.
+* the NON_SKIP_LEN comes from the length of the emits below.
*/
memset(cs, 0, sizeof(u32) *
- (ce->engine->emit_fini_breadcrumb_dw - 6));
- cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+ (ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN));
+ cs += ce->engine->emit_fini_breadcrumb_dw - NON_SKIP_LEN;
} else {
cs = __emit_fini_breadcrumb_child_no_preempt_mid_batch(rq, cs);
}
/* Emit fini breadcrumb */
+ before_fini_breadcrumb_user_interrupt_cs = cs;
cs = gen8_emit_ggtt_write(cs,
rq->fence.seqno,
i915_request_active_timeline(rq)->hwsp_offset,
@@ -4526,11 +4539,19 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct
i915_request *rq,
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_NOOP;
+ /* Ensure our math for skip + emit is correct */
+ GEM_BUG_ON(before_fini_breadcrumb_user_interrupt_cs + NON_SKIP_LEN !=
+ cs);
+ GEM_BUG_ON(start_fini_breadcrumb_cs +
+ ce->engine->emit_fini_breadcrumb_dw != cs);
+
rq->tail = intel_ring_offset(rq, cs);
return cs;
}
+#undef NON_SKIP_LEN
+
static struct intel_context *
guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count,
unsigned long flags)
--
2.34.1
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset
On Wed, Jan 19, 2022 at 01:07:22PM -0800, John Harrison wrote:
> On 1/19/2022 12:54, Matthew Brost wrote:
> > On Tue, Jan 18, 2022 at 05:37:01PM -0800, John Harrison wrote:
> > > On 1/18/2022 13:43, Matthew Brost wrote:
> > > > The G2H handler needs to be flushed during a GT reset but a G2H
> > > > indicating engine reset failure can trigger a GT reset. Add a worker to
> > > > trigger the GT when a engine reset failure is received to break this
> > > s/a/an/
> > >
> > Yep.
> >
> > > > circular dependency.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > >drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5
> > > >.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 23
> > > > +++
> > > >2 files changed, 24 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > index 9d26a86fe557a..60ea8deef5392 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > @@ -119,6 +119,11 @@ struct intel_guc {
> > > > * function as it might be in an atomic context (no
> > > > sleeping)
> > > > */
> > > > struct work_struct destroyed_worker;
> > > > + /**
> > > > +* @reset_worker: worker to trigger a GT reset after an
> > > > engine
> > > > +* reset fails
> > > > +*/
> > > > + struct work_struct reset_worker;
> > > > } submission_state;
> > > > /**
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 23a40f10d376d..cdd8d691251ff 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -1746,6 +1746,7 @@ void intel_guc_submission_reset_finish(struct
> > > > intel_guc *guc)
> > > >}
> > > >static void destroyed_worker_func(struct work_struct *w);
> > > > +static void reset_worker_func(struct work_struct *w);
> > > >/*
> > > > * Set up the memory resources to be shared with the GuC (via the
> > > > GGTT)
> > > > @@ -1776,6 +1777,8 @@ int intel_guc_submission_init(struct intel_guc
> > > > *guc)
> > > > INIT_LIST_HEAD(>submission_state.destroyed_contexts);
> > > > INIT_WORK(>submission_state.destroyed_worker,
> > > > destroyed_worker_func);
> > > > + INIT_WORK(>submission_state.reset_worker,
> > > > + reset_worker_func);
> > > > guc->submission_state.guc_ids_bitmap =
> > > > bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
> > > > @@ -4052,6 +4055,17 @@ guc_lookup_engine(struct intel_guc *guc, u8
> > > > guc_class, u8 instance)
> > > > return gt->engine_class[engine_class][instance];
> > > >}
> > > > +static void reset_worker_func(struct work_struct *w)
> > > > +{
> > > > + struct intel_guc *guc = container_of(w, struct intel_guc,
> > > > +
> > > > submission_state.reset_worker);
> > > > + struct intel_gt *gt = guc_to_gt(guc);
> > > > +
> > > > + intel_gt_handle_error(gt, ALL_ENGINES,
> > > > + I915_ERROR_CAPTURE,
> > > > + "GuC failed to reset a engine\n");
> > > s/a/an/
> > >
> > Yep.
> >
> > > > +}
> > > > +
> > > >int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
> > > > const u32 *msg, u32 len)
> > > >{
> > > > @@ -4083,10 +4097,11 @@ int intel_guc_engine_failure_process_msg(struct
> > > > intel_guc *guc,
> > > > drm_err(>i915->drm, "GuC engine reset request failed on
> > > > %d:%d (%s) because 0x%08X",
> > > > guc_class, instance, engine->name, reason);
> > > > - intel_gt_handle_error(gt, engine->mask,
> > > > - I915_ERROR_CAPTURE,
> > > > - "GuC failed to reset %s
> > > > (reason=0x%08x)\n",
> > > > - engine->name, reason);
> > > The engine name and reason code are lost from the error capture? I guess
> > > we
> > > still get it in the drm_err above, though. So probably not an issue. We
> > > shouldn't be getting these from end users and any internal CI run is only
> > > likely to give us the dmesg, not the error capture anyway! However, still
> > That was my reasoning on the msg too.
> >
> > > seems like it is work saving engine->mask in the submission_state
> > > structure
> > > (ORing in, in case there are multiple resets). Clearing it should be safe
> > > because once a GT reset has happened, we aren't getting any more G2Hs. And
> > > we can't have multiple message handlers running concurrently, right? So no
> > > need to protect the OR either.
> > >
> > I could do that but the
Re: [Intel-gfx] [PATCH 0/3] lib/string_helpers: Add a few string helpers
On Wed, Jan 19, 2022 at 12:53:43PM -0800, Lucas De Marchi wrote: > On Wed, Jan 19, 2022 at 05:15:02PM +0100, Daniel Vetter wrote: > > On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote: ... > > Yeah we can sed this anytime later we want to, but we need to get the foot > > in the door. There's also a pile more of these all over. > > > > Acked-by: Daniel Vetter > > > > on the series, maybe it helps? And yes let's merge this through drm-misc. > > Ok, it seems we are reaching some agreement here then: > - Change it to use str_ prefix Not sure about this (*), but have no strong argument against. Up to you. Ah, yes, Jani said about additional churn this change will make if goes together with this series. Perhaps it can be done separately? > - Wait -rc1 to avoid conflict > - Merge through drm-misc *) E.g. yesno() to me doesn't sound too bad to misunderstand its meaning, esp.when it's used as an argument to the printf() functions. -- With Best Regards, Andy Shevchenko
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for querying hw info that UMDs need
== Series Details == Series: Add support for querying hw info that UMDs need URL : https://patchwork.freedesktop.org/series/99060/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 04:00:17PM -0500, Steven Rostedt wrote: > On Wed, 19 Jan 2022 21:25:08 +0200 > Andy Shevchenko wrote: > > > > I say keep it one line! > > > > > > Reviewed-by: Steven Rostedt (Google) > > > > I believe Sakari strongly follows the 80 rule, which means... > > Checkpatch says "100" I think we need to simply update the docs (the > documentation always lags the code ;-) The idea of checkpatch change is for old code to avoid tons of patches to satisfy 80 rule in (mostly) staging code. Some maintainers started / have been using relaxed approach. -- With Best Regards, Andy Shevchenko
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for querying hw info that UMDs need
== Series Details == Series: Add support for querying hw info that UMDs need URL : https://patchwork.freedesktop.org/series/99060/ State : warning == Summary == $ dim checkpatch origin/drm-tip 59215be8fef3 drm/i915/guc: Add fetch of hwconfig table -:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #78: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 227 lines checked 236332f9458a drm/i915/uapi: Add query for hwconfig table
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset
On Tue, Jan 18, 2022 at 05:37:01PM -0800, John Harrison wrote:
> On 1/18/2022 13:43, Matthew Brost wrote:
> > The G2H handler needs to be flushed during a GT reset but a G2H
> > indicating engine reset failure can trigger a GT reset. Add a worker to
> > trigger the GT when a engine reset failure is received to break this
> s/a/an/
>
Yep.
> > circular dependency.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 +++
> > 2 files changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 9d26a86fe557a..60ea8deef5392 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -119,6 +119,11 @@ struct intel_guc {
> > * function as it might be in an atomic context (no sleeping)
> > */
> > struct work_struct destroyed_worker;
> > + /**
> > +* @reset_worker: worker to trigger a GT reset after an engine
> > +* reset fails
> > +*/
> > + struct work_struct reset_worker;
> > } submission_state;
> > /**
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 23a40f10d376d..cdd8d691251ff 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -1746,6 +1746,7 @@ void intel_guc_submission_reset_finish(struct
> > intel_guc *guc)
> > }
> > static void destroyed_worker_func(struct work_struct *w);
> > +static void reset_worker_func(struct work_struct *w);
> > /*
> >* Set up the memory resources to be shared with the GuC (via the GGTT)
> > @@ -1776,6 +1777,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
> > INIT_LIST_HEAD(>submission_state.destroyed_contexts);
> > INIT_WORK(>submission_state.destroyed_worker,
> > destroyed_worker_func);
> > + INIT_WORK(>submission_state.reset_worker,
> > + reset_worker_func);
> > guc->submission_state.guc_ids_bitmap =
> > bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
> > @@ -4052,6 +4055,17 @@ guc_lookup_engine(struct intel_guc *guc, u8
> > guc_class, u8 instance)
> > return gt->engine_class[engine_class][instance];
> > }
> > +static void reset_worker_func(struct work_struct *w)
> > +{
> > + struct intel_guc *guc = container_of(w, struct intel_guc,
> > +submission_state.reset_worker);
> > + struct intel_gt *gt = guc_to_gt(guc);
> > +
> > + intel_gt_handle_error(gt, ALL_ENGINES,
> > + I915_ERROR_CAPTURE,
> > + "GuC failed to reset a engine\n");
> s/a/an/
>
Yep.
> > +}
> > +
> > int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
> > const u32 *msg, u32 len)
> > {
> > @@ -4083,10 +4097,11 @@ int intel_guc_engine_failure_process_msg(struct
> > intel_guc *guc,
> > drm_err(>i915->drm, "GuC engine reset request failed on %d:%d (%s)
> > because 0x%08X",
> > guc_class, instance, engine->name, reason);
> > - intel_gt_handle_error(gt, engine->mask,
> > - I915_ERROR_CAPTURE,
> > - "GuC failed to reset %s (reason=0x%08x)\n",
> > - engine->name, reason);
> The engine name and reason code are lost from the error capture? I guess we
> still get it in the drm_err above, though. So probably not an issue. We
> shouldn't be getting these from end users and any internal CI run is only
> likely to give us the dmesg, not the error capture anyway! However, still
That was my reasoning on the msg too.
> seems like it is work saving engine->mask in the submission_state structure
> (ORing in, in case there are multiple resets). Clearing it should be safe
> because once a GT reset has happened, we aren't getting any more G2Hs. And
> we can't have multiple message handlers running concurrently, right? So no
> need to protect the OR either.
>
I could do that but the engine->mask is really only used for the error
capture with GuC submission as any i915 based reset with GuC submission
is a GT reset. Going from engine->mask to ALL_ENGINES will just capture
all engine state before doing a GT reset which probably isn't a bad
thing, right?
I can update the commit message explaining this if that helps.
Matt
> John.
>
>
> > + /*
> > +* A GT reset flushes this worker queue (G2H handler) so we must use
> > +* another worker to trigger a GT reset.
> > +*/
> > + queue_work(system_unbound_wq, >submission_state.reset_worker);
> > return 0;
> > }
>
Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU
On Wed, Jan 19, 2022 at 12:30:04PM -0800, Lucas De Marchi wrote: > On Tue, Jan 18, 2022 at 02:01:45PM -0600, Bjorn Helgaas wrote: > > Haha :) I was hoping not to touch it myself because I think this > > whole stolen memory thing is kind of nasty. It's not clear to me why > > we need it at all, or why we have to keep all this device-specific > > logic in the kernel, or why it has to be an early quirk as opposed to > > a regular PCI quirk. We had a thread [1] about it a while ago but I > > don't think anything got resolved. > > I was reading that thread again and thinking what we could do to try to > resolve this. I will reply on that thread. Great! I hope there's some way around this. > > But to try to make forward progress, I applied patch 1/5 (actually, > > the updated one from [2]) to my pci/misc branch with the updated > > commit log and code comments below. > > thanks. I found the wording in the title odd as when I read "first" it > gives me the impression it's saying there could be more, which is not > possible. I said "first integrated GPU" because Linux doesn't control what devices are in the system; it just has to deal with whatever it finds. All one can tell from the code is that if we find one or more devices that appear in intel_early_ids[], we reserve stolen memory for the first such device. System-specific knowledge might tell you that there should only be one integrated GPU, but there's no constraint like that in Linux. Bjorn
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
On 1/19/2022 12:47, Matthew Brost wrote:
On Tue, Jan 18, 2022 at 05:29:54PM -0800, John Harrison wrote:
On 1/18/2022 13:43, Matthew Brost wrote:
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL do fully decouple the error capture from fence signalling.
s/do/to/
Yep.
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Does this really count as a bug fix over that patch? Isn't it more of a
changing in policy now that we do DRM fence signalling and that other
changes related to error capture behaviour have been implemented.
That patch was supposed to allow signalling annotations to be added,
without this change I think these annotations would be broken. So I
think the Fixes is correct.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 67f3515f07e7a..aee42eae4729f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1516,7 +1516,7 @@ capture_engine(struct intel_engine_cs *engine,
struct i915_request *rq = NULL;
unsigned long flags;
- ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);
+ ee = intel_engine_coredump_alloc(engine, ALLOW_FAIL);
This still makes me nervous that we will fail to allocate engine captures in
stress test scenarios, which are exactly the kind of situations where we
need valid error captures.
Me too, but this whole file has been changed to the ALLOW_FAIL. Thomas
and Daniel seem to think this is correct. For what it's worth this
allocation is less than a page, so it should be pretty safe to do with
ALLOW_FAIL.
There is also still a GFP_KERNEL in __i915_error_grow(). Doesn't that need
updating as well?
Probably just should be deleted. If look it tries with ALLOW_FAIL first,
then falls back to GFP_KERNEL. I didn't want to make that update in this
series yet but that is something to keep an eye on.
Matt
Okay. Makes sense. With the description typo fixed:
Reviewed-by: John Harrison
John.
if (!ee)
return NULL;
Re: [Intel-gfx] [PATCH 0/3] lib/string_helpers: Add a few string helpers
On Wed, Jan 19, 2022 at 05:15:02PM +0100, Daniel Vetter wrote: On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote: On Wed, 19 Jan 2022, Petr Mladek wrote: > On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote: >> Add some helpers under lib/string_helpers.h so they can be used >> throughout the kernel. When I started doing this there were 2 other >> previous attempts I know of, not counting the iterations each of them >> had: >> >> 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/ >> 2) https://lore.kernel.org/all/20210215142137.64476-1-andriy.shevche...@linux.intel.com/#t >> >> Going through the comments I tried to find some common ground and >> justification for what is in here, addressing some of the concerns >> raised. >> >> d. This doesn't bring onoff() helper as there are some places in the >>kernel with onoff as variable - another name is probably needed for >>this function in order not to shadow the variable, or those variables >>could be renamed. Or if people wanting >>try to find a short one > > I would call it str_on_off(). > > And I would actually suggest to use the same style also for > the other helpers. > > The "str_" prefix would make it clear that it is something with > string. There are other _on_off() that affect some > functionality, e.g. mute_led_on_off(), e1000_vlan_filter_on_off(). > > The dash '_' would significantly help to parse the name. yesno() and > onoff() are nicely short and kind of acceptable. But "enabledisable()" > is a puzzle. > > IMHO, str_yes_no(), str_on_off(), str_enable_disable() are a good > compromise. > > The main motivation should be code readability. You write the > code once. But many people will read it many times. Open coding > is sometimes better than misleading macro names. > > That said, I do not want to block this patchset. If others like > it... ;-) I don't mind the names either way. Adding the prefix and dashes is helpful in that it's possible to add the functions first and convert users at leisure, though with a bunch of churn, while using names that collide with existing ones requires the changes to happen in one go. What I do mind is grinding this series to a halt once again. I sent a handful of versions of this three years ago, with inconclusive bikeshedding back and forth, eventually threw my hands up in disgust, and walked away. Yeah we can sed this anytime later we want to, but we need to get the foot in the door. There's also a pile more of these all over. Acked-by: Daniel Vetter on the series, maybe it helps? And yes let's merge this through drm-misc. Ok, it seems we are reaching some agreement here then: - Change it to use str_ prefix - Wait -rc1 to avoid conflict - Merge through drm-misc I will re-send the series again soon. Lucas De Marchi
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
On Tue, Jan 18, 2022 at 05:29:54PM -0800, John Harrison wrote:
> On 1/18/2022 13:43, Matthew Brost wrote:
> > Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
> > GFP_KERNEL do fully decouple the error capture from fence signalling.
> s/do/to/
>
Yep.
> >
> > Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture
> > code")
> Does this really count as a bug fix over that patch? Isn't it more of a
> changing in policy now that we do DRM fence signalling and that other
> changes related to error capture behaviour have been implemented.
>
That patch was supposed to allow signalling annotations to be added,
without this change I think these annotations would be broken. So I
think the Fixes is correct.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 67f3515f07e7a..aee42eae4729f 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -1516,7 +1516,7 @@ capture_engine(struct intel_engine_cs *engine,
> > struct i915_request *rq = NULL;
> > unsigned long flags;
> > - ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);
> > + ee = intel_engine_coredump_alloc(engine, ALLOW_FAIL);
> This still makes me nervous that we will fail to allocate engine captures in
> stress test scenarios, which are exactly the kind of situations where we
> need valid error captures.
>
Me too, but this whole file has been changed to the ALLOW_FAIL. Thomas
and Daniel seem to think this is correct. For what it's worth this
allocation is less than a page, so it should be pretty safe to do with
ALLOW_FAIL.
> There is also still a GFP_KERNEL in __i915_error_grow(). Doesn't that need
> updating as well?
>
Probably just should be deleted. If look it tries with ALLOW_FAIL first,
then falls back to GFP_KERNEL. I didn't want to make that update in this
series yet but that is something to keep an eye on.
Matt
> John.
>
> > if (!ee)
> > return NULL;
>
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 10:06:35AM -0500, Steven Rostedt wrote:
On Wed, 19 Jan 2022 11:18:59 +0200
Sakari Ailus wrote:
On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote:
> @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct
tomoyo_io_buffer *head,
>case 3:
>if (cond->grant_log != TOMOYO_GRANTLOG_AUTO)
>tomoyo_io_printf(head, " grant_log=%s",
> - tomoyo_yesno(cond->grant_log ==
> -TOMOYO_GRANTLOG_YES));
> + yesno(cond->grant_log ==
TOMOYO_GRANTLOG_YES));
This would be better split on two lines.
Really? Yuck!
I thought the "max line size" guideline was going to grow to a 100, but I
still see it as 80. But anyway...
Checking that: docs still say 80, but checkpatch was changed to warn
only on 100. Commit bdc48fa11e46 ("checkpatch/coding-style: deprecate
80-column warning") is clear why the discrepancy.
Lucas De Marchi
cond->grant_log ==
TOMOYO_GRANTLOG_YES
is not readable at all. Not compared to
cond->grant_log == TOMOYO_GRANTLOG_YES
I say keep it one line!
Reviewed-by: Steven Rostedt (Google)
-- Steve
Then,
Reviewed-by: Sakari Ailus
[Intel-gfx] [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interested components can grab the
very latest and synchronized information using a simple query.
As per most of the other queries, this one can be called twice.
Once with item.length=0 to determine the exact buffer size, then
allocate the user memory and call it again for to retrieve the
table data. For example:
struct drm_i915_query_item item = {
.query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
};
query.items_ptr = (int64_t)
query.num_items = 1;
ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
if (item.length <= 0)
return -ENOENT;
data = malloc(item.length);
item.data_ptr = (int64_t)
ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
// Parse the data as appropriate...
The returned array is a simple and flexible KLV (Key/Length/Value)
formatted table. For example, it could be just:
enum device_attr {
ATTR_SOME_VALUE = 0,
ATTR_SOME_MASK = 1,
};
static const u32 hwconfig[] = {
ATTR_SOME_VALUE,
1, // Value Length in DWords
8, // Value
ATTR_SOME_MASK,
3,
0x00, 0x, 0xFF00,
};
The attribute ids are defined in a hardware spec.
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
Cc: Michal Wajdeczko
Cc: Slawomir Milczarek
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_query.c | 23 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..609e64d5f395 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private
*i915,
return total_length;
}
+static int query_hwconfig_table(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct intel_gt *gt = to_gt(i915);
+ struct intel_guc_hwconfig *hwconfig = >uc.guc.hwconfig;
+
+ if (!hwconfig->size || !hwconfig->ptr)
+ return -ENODEV;
+
+ if (query_item->length == 0)
+ return hwconfig->size;
+
+ if (query_item->length < hwconfig->size)
+ return -EINVAL;
+
+ if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+hwconfig->ptr, hwconfig->size))
+ return -EFAULT;
+
+ return hwconfig->size;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
query_engine_info,
query_perf_config,
query_memregion_info,
+ query_hwconfig_table,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 914ebd9290e5..132515199f27 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
#define DRM_I915_QUERY_ENGINE_INFO 2
#define DRM_I915_QUERY_PERF_CONFIG 3
#define DRM_I915_QUERY_MEMORY_REGIONS 4
+#define DRM_I915_QUERY_HWCONFIG_TABLE 5
/* Must be kept compact -- no holes and well documented */
/**
--
2.25.1
[Intel-gfx] [PATCH v3 0/2] Add support for querying hw info that UMDs need
From: John Harrison Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. v2: Rebased to newer baseline and added a kerneldoc comment. v3: Rebased to newer baseline and newer GuC interface. Test-with: 20220119200137.2364940-2-john.c.harri...@intel.com UMD: https://github.com/intel/compute-runtime/pull/432/files UMD: https://github.com/intel/media-driver/pull/1239/files CC: Katarzyna Cencelewska CC: Tony Ye CC: Jason Ekstrand Signed-off-by: John Harrison Reviewed-by: Matthew Brost John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig table drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.h| 3 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 151 ++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 23 +++ include/uapi/drm/i915_drm.h | 1 + 9 files changed, 209 insertions(+) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.25.1
[Intel-gfx] [PATCH v3 1/2] drm/i915/guc: Add fetch of hwconfig table
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Michal Wajdeczko
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 3 +
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 151 ++
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +
7 files changed, 185 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f1a9a648ce09..23f6b264d260 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -193,6 +193,7 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_guc_rc.o \
gt/uc/intel_guc_slpc.o \
gt/uc/intel_guc_submission.o \
+ gt/uc/intel_guc_hwconfig.o \
gt/uc/intel_huc.o \
gt/uc/intel_huc_debugfs.o \
gt/uc/intel_huc_fw.o
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 7afdadc7656f..a9a329e53c35 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -129,6 +129,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_SETUP_PC_GUCRC = 0x3004,
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+ INTEL_GUC_ACTION_GET_HWCONFIG = 0x4100,
INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index c20658ee85a5..8085fb181274 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -8,6 +8,10 @@
enum intel_guc_response_status {
INTEL_GUC_RESPONSE_STATUS_SUCCESS = 0x0,
+ INTEL_GUC_RESPONSE_NOT_SUPPORTED = 0x20,
+ INTEL_GUC_RESPONSE_NO_ATTRIBUTE_TABLE = 0x201,
+ INTEL_GUC_RESPONSE_NO_DECRYPTION_KEY = 0x202,
+ INTEL_GUC_RESPONSE_DECRYPTION_FAILED = 0x204,
INTEL_GUC_RESPONSE_STATUS_GENERIC_FAIL = 0xF000,
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d26a86fe557..bc785403097f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -13,6 +13,7 @@
#include "intel_guc_fw.h"
#include "intel_guc_fwif.h"
#include "intel_guc_ct.h"
+#include "intel_guc_hwconfig.h"
#include "intel_guc_log.h"
#include "intel_guc_reg.h"
#include "intel_guc_slpc_types.h"
@@ -37,6 +38,8 @@ struct intel_guc {
struct intel_guc_ct ct;
/** @slpc: sub-structure containing SLPC related data and objects */
struct intel_guc_slpc slpc;
+ /** @hwconfig: hardware configuration KLV table */
+ struct intel_guc_hwconfig hwconfig;
/** @sched_engine: Global engine used to submit requests to GuC */
struct i915_sched_engine *sched_engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
new file mode 100644
index ..ce6088f112d4
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "gt/intel_gt.h"
+#include "i915_drv.h"
+#include "i915_memcpy.h"
+#include "intel_guc_hwconfig.h"
+
+static inline struct intel_guc *hwconfig_to_guc(struct intel_guc_hwconfig
*hwconfig)
+{
+ return container_of(hwconfig, struct intel_guc, hwconfig);
+}
+
+/*
+ * GuC has a blob containing hardware configuration information (HWConfig).
+ * This is formatted as a simple and flexible KLV (Key/Length/Value) table.
+ *
+ * For example, a minimal version could be:
+ * enum device_attr {
+ * ATTR_SOME_VALUE = 0,
+ * ATTR_SOME_MASK = 1,
+ * };
+ *
+ * static const u32 hwconfig[] = {
+ * ATTR_SOME_VALUE,
+ * 1, // Value Length in DWords
+ * 8, // Value
+ *
+ * ATTR_SOME_MASK,
+ * 3,
+ * 0x00, 0x, 0xFF00,
+ * };
+ *
+ * The attribute ids are defined in a hardware spec.
+ */
+
+static int __guc_action_get_hwconfig(struct intel_guc_hwconfig *hwconfig,
+u32
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 (rev2)
== Series Details == Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 (rev2) URL : https://patchwork.freedesktop.org/series/99052/ State : failure == Summary == CI Bug Log - changes from CI_DRM_0 -> Patchwork_22026 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22026 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22026, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/index.html Participating hosts (45 -> 34) -- Missing(11): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-bsw-cyan fi-apl-guc bat-adlp-6 bat-rpls-1 fi-bdw-samus bat-jsl-2 bat-jsl-1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22026: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-blb-e6850: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html Known issues Here are the changes found in Patchwork_22026 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +31 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@gem_exec_suspend@basic-s3: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][4] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - fi-tgl-1115g4: [FAIL][6] ([i915#1888]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_0/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/fi-tgl-1115g4/igt@gem_exec_suspend@basic...@smem.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_0 -> Patchwork_22026 CI-20190529: 20190529 CI_DRM_0: 773fc0fe92f90fa7bbbcdccffa7436259bbab22f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22026: 2ee69fab49bcbfe05337fdbfae4d7c4035e9bab0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2ee69fab49bc drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22026/index.html
Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU
On Tue, Jan 18, 2022 at 02:01:45PM -0600, Bjorn Helgaas wrote: On Tue, Jan 18, 2022 at 07:37:29PM +0100, Borislav Petkov wrote: On Tue, Jan 18, 2022 at 11:58:53AM -0600, Bjorn Helgaas wrote: > I don't really care much one way or the other. I think the simplest > approach is to remove QFLAG_APPLY_ONCE from intel_graphics_quirks() > and do nothing else, as I suggested here: > > https://lore.kernel.org/r/20220113000805.GA295089@bhelgaas > > Unfortunately that didn't occur to me until I'd already suggested more > complicated things that no longer seem worthwhile to me. > > The static variable might be ugly, but it does seem to be what > intel_graphics_quirks() wants -- a "do this at most once per system > but we don't know exactly which device" situation. I see. Yeah, keeping it solely inside intel_graphics_quirks() and maybe with a comment ontop, why it is done, is simple. I guess if more quirks need this once-thing people might have to consider a more sensible scheme - I was just objecting to sprinkling those static vars everywhere. But your call. :) Haha :) I was hoping not to touch it myself because I think this whole stolen memory thing is kind of nasty. It's not clear to me why we need it at all, or why we have to keep all this device-specific logic in the kernel, or why it has to be an early quirk as opposed to a regular PCI quirk. We had a thread [1] about it a while ago but I don't think anything got resolved. I was reading that thread again and thinking what we could do to try to resolve this. I will reply on that thread. But to try to make forward progress, I applied patch 1/5 (actually, the updated one from [2]) to my pci/misc branch with the updated commit log and code comments below. thanks. I found the wording in the title odd as when I read "first" it gives me the impression it's saying there could be more, which is not possible. Anyway, not a big thing. Thanks for rewording it. Lucas De Marchi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 (rev2)
== Series Details == Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 (rev2) URL : https://patchwork.freedesktop.org/series/99052/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH v2 i-g-t 1/1] tests/i915/query: Query, parse and validate the hwconfig table
From: Rodrigo Vivi
Newer platforms have an embedded table giving details about that
platform's hardware configuration. This table can be retrieved from
the KMD via the existing query API. So add a test for it as both an
example of how to fetch the table and to validate the contents as much
as is possible.
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Cc: Slawomir Milczarek
Reviewed-by: Matthew Brost
---
include/drm-uapi/i915_drm.h | 1 +
lib/intel_hwconfig_types.h | 106 +++
tests/i915/i915_query.c | 168
3 files changed, 275 insertions(+)
create mode 100644 lib/intel_hwconfig_types.h
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index 9c9e1afa6..7b68fb29e 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
#define DRM_I915_QUERY_ENGINE_INFO 2
#define DRM_I915_QUERY_PERF_CONFIG 3
#define DRM_I915_QUERY_MEMORY_REGIONS 4
+#define DRM_I915_QUERY_HWCONFIG_TABLE 5
/* Must be kept compact -- no holes and well documented */
/**
diff --git a/lib/intel_hwconfig_types.h b/lib/intel_hwconfig_types.h
new file mode 100644
index 0..c9961e6bd
--- /dev/null
+++ b/lib/intel_hwconfig_types.h
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef _INTEL_HWCONFIG_TYPES_H_
+#define _INTEL_HWCONFIG_TYPES_H_
+
+#include "intel_chipset.h"
+
+/**
+ * enum intel_hwconfig - Global definition of hwconfig table attributes
+ *
+ * Intel devices provide a KLV (Key/Length/Value) table containing
+ * the static hardware configuration for that platform.
+ * This enum defines the current attribute keys for this KLV.
+ */
+enum intel_hwconfig {
+ INTEL_HWCONFIG_MAX_SLICES_SUPPORTED = 1,
+ INTEL_HWCONFIG_MAX_DUAL_SUBSLICES_SUPPORTED,/* 2 */
+ INTEL_HWCONFIG_MAX_NUM_EU_PER_DSS, /* 3 */
+ INTEL_HWCONFIG_NUM_PIXEL_PIPES, /* 4 */
+ INTEL_HWCONFIG_DEPRECATED_MAX_NUM_GEOMETRY_PIPES, /* 5 */
+ INTEL_HWCONFIG_DEPRECATED_L3_CACHE_SIZE_IN_KB, /* 6 */
+ INTEL_HWCONFIG_DEPRECATED_L3_BANK_COUNT,/* 7 */
+ INTEL_HWCONFIG_L3_CACHE_WAYS_SIZE_IN_BYTES, /* 8 */
+ INTEL_HWCONFIG_L3_CACHE_WAYS_PER_SECTOR,/* 9 */
+ INTEL_HWCONFIG_MAX_MEMORY_CHANNELS, /* 10 */
+ INTEL_HWCONFIG_MEMORY_TYPE, /* 11 */
+ INTEL_HWCONFIG_CACHE_TYPES, /* 12 */
+ INTEL_HWCONFIG_LOCAL_MEMORY_PAGE_SIZES_SUPPORTED, /* 13 */
+ INTEL_HWCONFIG_DEPRECATED_SLM_SIZE_IN_KB, /* 14 */
+ INTEL_HWCONFIG_NUM_THREADS_PER_EU, /* 15 */
+ INTEL_HWCONFIG_TOTAL_VS_THREADS,/* 16 */
+ INTEL_HWCONFIG_TOTAL_GS_THREADS,/* 17 */
+ INTEL_HWCONFIG_TOTAL_HS_THREADS,/* 18 */
+ INTEL_HWCONFIG_TOTAL_DS_THREADS,/* 19 */
+ INTEL_HWCONFIG_TOTAL_VS_THREADS_POCS, /* 20 */
+ INTEL_HWCONFIG_TOTAL_PS_THREADS,/* 21 */
+ INTEL_HWCONFIG_DEPRECATED_MAX_FILL_RATE,/* 22 */
+ INTEL_HWCONFIG_MAX_RCS, /* 23 */
+ INTEL_HWCONFIG_MAX_CCS, /* 24 */
+ INTEL_HWCONFIG_MAX_VCS, /* 25 */
+ INTEL_HWCONFIG_MAX_VECS,/* 26 */
+ INTEL_HWCONFIG_MAX_COPY_CS, /* 27 */
+ INTEL_HWCONFIG_DEPRECATED_URB_SIZE_IN_KB, /* 28 */
+ INTEL_HWCONFIG_MIN_VS_URB_ENTRIES, /* 29 */
+ INTEL_HWCONFIG_MAX_VS_URB_ENTRIES, /* 30 */
+ INTEL_HWCONFIG_MIN_PCS_URB_ENTRIES, /* 31 */
+ INTEL_HWCONFIG_MAX_PCS_URB_ENTRIES, /* 32 */
+ INTEL_HWCONFIG_MIN_HS_URB_ENTRIES, /* 33 */
+ INTEL_HWCONFIG_MAX_HS_URB_ENTRIES, /* 34 */
+ INTEL_HWCONFIG_MIN_GS_URB_ENTRIES, /* 35 */
+ INTEL_HWCONFIG_MAX_GS_URB_ENTRIES, /* 36 */
+ INTEL_HWCONFIG_MIN_DS_URB_ENTRIES, /* 37 */
+ INTEL_HWCONFIG_MAX_DS_URB_ENTRIES, /* 38 */
+ INTEL_HWCONFIG_PUSH_CONSTANT_URB_RESERVED_SIZE, /* 39 */
+ INTEL_HWCONFIG_POCS_PUSH_CONSTANT_URB_RESERVED_SIZE,/* 40 */
+ INTEL_HWCONFIG_URB_REGION_ALIGNMENT_SIZE_IN_BYTES, /* 41 */
+ INTEL_HWCONFIG_URB_ALLOCATION_SIZE_UNITS_IN_BYTES, /* 42 */
+ INTEL_HWCONFIG_MAX_URB_SIZE_CCS_IN_BYTES, /* 43 */
+ INTEL_HWCONFIG_VS_MIN_DEREF_BLOCK_SIZE_HANDLE_COUNT,/* 44 */
+
[Intel-gfx] [PATCH v2 i-g-t 0/1] Add test for new hw info query
From: John Harrison Various UMDs require hardware configuration information about the current platform. A new interface has been added to the KMD to return this information. So, add a test for the new interface. v2: Rebased to newer baseline. Signed-off-by: John Harrison Reviewed-by: Matthew Brost Rodrigo Vivi (1): tests/i915/query: Query, parse and validate the hwconfig table include/drm-uapi/i915_drm.h | 1 + lib/intel_hwconfig_types.h | 106 +++ tests/i915/i915_query.c | 168 3 files changed, 275 insertions(+) create mode 100644 lib/intel_hwconfig_types.h -- 2.25.1
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/uapi: document behaviour for DG2 64K support
On 19/01/2022 18:36, Jordan Justen wrote:
Robert Beckett writes:
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..486b7b96291e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* **DG2 64K min page size implications:**
Long term, I'm not sure that the "**" (for emphasis) is needed here or
below. It's interesting at the moment, but will be just another thing
baked into the kernel/user code in a month from now. :)
fair point, I'll make it less shouty
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* **Special DG2 GTT address alignment requirement:**
+*
+* The GTT alignment will also need be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE(which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects GD2, this
+* id deemed to be a good compromise.
typos: GD2, id
thanks
Isn't much of this more relavent to the vma offset at exec time? Is
there actually any new restriction on the size field during buffer
creation?
No new restriction on size, just placement, which mesa is already doing.
The request for ack was just to get an ack from mesa folks that they are
happy with the mandatory 2MB alignment for DG2 vma.
I see Matthew references these notes from the offset comments, so if the
kernel devs prefer it here, then you can add my Acked-by on this patch.
thanks!
-Jordan
*/
__u64 size;
/**
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915: Nuke dg2_ddi_pre_enable_dp()
On Wed, Jan 19, 2022 at 11:09:47AM -0800, Navare, Manasi wrote: > On Wed, Jan 19, 2022 at 05:17:05PM +0200, Jani Nikula wrote: > > On Wed, 19 Jan 2022, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate > > > it. > > > > > > The one thing that tgl_ddi_pre_enable_dp() is missing that we > > > need is intel_ddi_config_transcoder_dp2(). So we'll bring that > > > over. > > > > > > tgl_ddi_pre_enable_dp() does also have a few things that > > > dg2_ddi_pre_enable_dp() didn't have: > > > - icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2 > > > - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on > > > DG2 > > > - intel_ddi_mso_configure() -> only matters for MSO panels > > > > > > Another slight difference is that dg2_ddi_pre_enable_dp() was > > > missing a bigjoiner check around intel_dsc_enable(), which > > > tgl_ddi_pre_enable_dp() does have. > > Thanks Ville for this patch, I was just comparing differences between > dg2_pre_enable_dp and tgl_pre_enable_dp > in regards to a bug and there is totally no need for two functions with the > checks you have here. > > For the bigjoiner check aroind intel_dsc_enable(), I think the function > intel_dsc_dp_pps_write(encoder, crtc_state); > also needs to be moved into that check. > And then this functions needs to be called from > icl_ddi_bigjoiner_pre_enable() where we call intel_dsc_enable The video DIP lives in the transcoder so we don't want to write it twice. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 3/3] drm: Convert open yes/no strings to yesno()
On Tue, Jan 18, 2022 at 11:24:50PM -0800, Lucas De Marchi wrote: > linux/string_helpers.h provides a helper to return "yes"/"no" > strings. Replace the open coded versions with yesno(). The places were > identified with the following semantic patch: > > @@ > expression b; > @@ > > - b ? "yes" : "no" > + yesno(b) > > Then the includes were added, so we include-what-we-use, and parenthesis > adjusted in drivers/gpu/drm/v3d/v3d_debugfs.c. After the conversion we > still see the same binary sizes: > >textdata bss dec hex filename > 1442171 60344 800 1503315 16f053 ./drivers/gpu/drm/radeon/radeon.ko > 1442171 60344 800 1503315 16f053 ./drivers/gpu/drm/radeon/radeon.ko.old > 5985991 324439 33808 6344238 60ce2e ./drivers/gpu/drm/amd/amdgpu/amdgpu.ko > 5985991 324439 33808 6344238 60ce2e > ./drivers/gpu/drm/amd/amdgpu/amdgpu.ko.old > 411986 104906176 428652 68a6c ./drivers/gpu/drm/drm.ko > 411986 104906176 428652 68a6c ./drivers/gpu/drm/drm.ko.old > 1970292 1095152352 2082159 1fc56f ./drivers/gpu/drm/nouveau/nouveau.ko > 1970292 1095152352 2082159 1fc56f > ./drivers/gpu/drm/nouveau/nouveau.ko.old ... > #include > #include > #include > +#include + blank line? > +#include ... > seq_printf(m, "\tDP branch device present: %s\n", > -branch_device ? "yes" : "no"); > +yesno(branch_device)); Now it's possible to keep this on one line. ... > drm_printf_indent(p, indent, "imported=%s\n", > - obj->import_attach ? "yes" : "no"); > + yesno(obj->import_attach)); 81 here, but anyway, ditto! ... > */ +blank line here? > +#include > + > #include "aux.h" > #include "pad.h" ... > seq_printf(m, "MMU:%s\n", > -(ident2 & V3D_HUB_IDENT2_WITH_MMU) ? "yes" : "no"); > +yesno(ident2 & V3D_HUB_IDENT2_WITH_MMU)); > seq_printf(m, "TFU:%s\n", > -(ident1 & V3D_HUB_IDENT1_WITH_TFU) ? "yes" : "no"); > +yesno(ident1 & V3D_HUB_IDENT1_WITH_TFU)); > seq_printf(m, "TSY:%s\n", > -(ident1 & V3D_HUB_IDENT1_WITH_TSY) ? "yes" : "no"); > +yesno(ident1 & V3D_HUB_IDENT1_WITH_TSY)); > seq_printf(m, "MSO:%s\n", > -(ident1 & V3D_HUB_IDENT1_WITH_MSO) ? "yes" : "no"); > +yesno(ident1 & V3D_HUB_IDENT1_WITH_MSO)); > seq_printf(m, "L3C:%s (%dkb)\n", > -(ident1 & V3D_HUB_IDENT1_WITH_L3C) ? "yes" : "no", > +yesno(ident1 & V3D_HUB_IDENT1_WITH_L3C), > V3D_GET_FIELD(ident2, V3D_HUB_IDENT2_L3C_NKB)); I believe it's fine to join back to have less LOCs (yes, it will be 83 or so, but I believe in these cases it's very much okay). -- With Best Regards, Andy Shevchenko
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote:
> > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
> >
> > return "yes\0no" + v * 4;
> >
> > :-)
>
> except '"no\0\0yes" + v * 4' works a bit better.
Is it a C code obfuscation contest?
--
With Best Regards,
Andy Shevchenko
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 10:06:35AM -0500, Steven Rostedt wrote: > On Wed, 19 Jan 2022 11:18:59 +0200 > Sakari Ailus wrote: > > On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote: > > > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct > > > tomoyo_io_buffer *head, > > > case 3: > > > if (cond->grant_log != TOMOYO_GRANTLOG_AUTO) > > > tomoyo_io_printf(head, " grant_log=%s", > > > - tomoyo_yesno(cond->grant_log == > > > - TOMOYO_GRANTLOG_YES)); > > > + yesno(cond->grant_log == > > > TOMOYO_GRANTLOG_YES)); > > > > This would be better split on two lines. > > Really? Yuck! > > I thought the "max line size" guideline was going to grow to a 100, but I > still see it as 80. But anyway... > > cond->grant_log == > TOMOYO_GRANTLOG_YES > > is not readable at all. Not compared to > > cond->grant_log == TOMOYO_GRANTLOG_YES > > I say keep it one line! > > Reviewed-by: Steven Rostedt (Google) I believe Sakari strongly follows the 80 rule, which means... > > Reviewed-by: Sakari Ailus ...chose either of these tags and be happy with :-) -- With Best Regards, Andy Shevchenko
[Intel-gfx] [PATCH v2] drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
LG Gram 2021 laptop 17Z95P-K.ADE9U1 OpRegion has
FW size: 0x2200
VBT size: 0x2000
BDB offset: 0x30
BDB size: 0x216e
Add intel_init_opregion_quirks to use FW size as VBT size on LG Gram
17Z95P-K.ADE9U1 and update intel_bios_is_valid_vbt to use FW size,
instead of VBT size if the quirk is applied, in range_overflows_t for
BDB size overflow check. This fixes:
https://gitlab.freedesktop.org/drm/intel/-/issues/4763
Signed-off-by: H.J. Lu
---
drivers/gpu/drm/i915/display/intel_bios.c | 15 ---
drivers/gpu/drm/i915/display/intel_bios.h | 3 +-
drivers/gpu/drm/i915/display/intel_opregion.c | 9 +++--
drivers/gpu/drm/i915/display/intel_quirks.c | 40 +++
drivers/gpu/drm/i915/display/intel_quirks.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
6 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7d04572dd18b..d6442ec2dc70 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2268,12 +2268,14 @@ static const struct bdb_header *get_bdb_header(const
struct vbt_header *vbt)
/**
* intel_bios_is_valid_vbt - does the given buffer contain a valid VBT
+ * @dev_priv: i915 device instance
* @buf: pointer to a buffer to validate
* @size: size of the buffer
*
* Returns true on valid VBT.
*/
-bool intel_bios_is_valid_vbt(const void *buf, size_t size)
+bool intel_bios_is_valid_vbt(struct drm_i915_private *dev_priv,
+const void *buf, size_t size)
{
const struct vbt_header *vbt = buf;
const struct bdb_header *bdb;
@@ -2296,16 +2298,17 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
size)
return false;
}
- size = vbt->vbt_size;
-
if (range_overflows_t(size_t,
vbt->bdb_offset,
sizeof(struct bdb_header),
- size)) {
+ vbt->vbt_size)) {
DRM_DEBUG_DRIVER("BDB header incomplete\n");
return false;
}
+ if (!(dev_priv->quirks & QUIRK_USE_FW_SIZE_AS_VBT_SIZE))
+ size = vbt->vbt_size;
+
bdb = get_bdb_header(vbt);
if (range_overflows_t(size_t, vbt->bdb_offset, bdb->bdb_size, size)) {
DRM_DEBUG_DRIVER("BDB incomplete\n");
@@ -2359,7 +2362,7 @@ static struct vbt_header *spi_oprom_get_vbt(struct
drm_i915_private *i915)
*(vbt + store++) = data;
}
- if (!intel_bios_is_valid_vbt(vbt, vbt_size))
+ if (!intel_bios_is_valid_vbt(i915, vbt, vbt_size))
goto err_free_vbt;
drm_dbg_kms(>drm, "Found valid VBT in SPI flash\n");
@@ -2416,7 +2419,7 @@ static struct vbt_header *oprom_get_vbt(struct
drm_i915_private *i915)
memcpy_fromio(vbt, p, vbt_size);
- if (!intel_bios_is_valid_vbt(vbt, vbt_size))
+ if (!intel_bios_is_valid_vbt(i915, vbt, vbt_size))
goto err_free_vbt;
pci_unmap_rom(pdev, oprom);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4709c4d29805..368ee87390e7 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -231,7 +231,8 @@ struct mipi_pps_data {
void intel_bios_init(struct drm_i915_private *dev_priv);
void intel_bios_driver_remove(struct drm_i915_private *dev_priv);
-bool intel_bios_is_valid_vbt(const void *buf, size_t size);
+bool intel_bios_is_valid_vbt(struct drm_i915_private *dev_priv,
+const void *buf, size_t size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port
port);
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index af9d30f56cc1..7a9b4d72d18c 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -36,6 +36,7 @@
#include "intel_display_types.h"
#include "intel_opregion.h"
#include "intel_pci_config.h"
+#include "intel_quirks.h"
#define OPREGION_HEADER_OFFSET 0
#define OPREGION_ACPI_OFFSET 0x100
@@ -817,7 +818,7 @@ static int intel_load_vbt_firmware(struct drm_i915_private
*dev_priv)
return ret;
}
- if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
+ if (intel_bios_is_valid_vbt(dev_priv, fw->data, fw->size)) {
opregion->vbt_firmware = kmemdup(fw->data, fw->size,
GFP_KERNEL);
if (opregion->vbt_firmware) {
drm_dbg_kms(_priv->drm,
@@ -922,6 +923,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if
Re: [Intel-gfx] [PATCH] drm/i915: Nuke dg2_ddi_pre_enable_dp()
On Wed, Jan 19, 2022 at 05:17:05PM +0200, Jani Nikula wrote:
> On Wed, 19 Jan 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate
> > it.
> >
> > The one thing that tgl_ddi_pre_enable_dp() is missing that we
> > need is intel_ddi_config_transcoder_dp2(). So we'll bring that
> > over.
> >
> > tgl_ddi_pre_enable_dp() does also have a few things that
> > dg2_ddi_pre_enable_dp() didn't have:
> > - icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2
> > - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on
> > DG2
> > - intel_ddi_mso_configure() -> only matters for MSO panels
> >
> > Another slight difference is that dg2_ddi_pre_enable_dp() was
> > missing a bigjoiner check around intel_dsc_enable(), which
> > tgl_ddi_pre_enable_dp() does have.
Thanks Ville for this patch, I was just comparing differences between
dg2_pre_enable_dp and tgl_pre_enable_dp
in regards to a bug and there is totally no need for two functions with the
checks you have here.
For the bigjoiner check aroind intel_dsc_enable(), I think the function
intel_dsc_dp_pps_write(encoder, crtc_state);
also needs to be moved into that check.
And then this functions needs to be called from icl_ddi_bigjoiner_pre_enable()
where we call intel_dsc_enable
With that:
Reviewed-by: Manasi Navare
Manasi
>
> Reviewed-by: Jani Nikula
>
> The modeset step bspec references could use a cleanup too. If they
> aren't stable number combos for *one* platform, let alone many,
> we should probably just remove them.
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 117 +--
> > 1 file changed, 4 insertions(+), 113 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4e93eac926a5..2f20abc5122d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -2289,116 +2289,6 @@ static void intel_ddi_mso_configure(const struct
> > intel_crtc_state *crtc_state)
> > OVERLAP_PIXELS_MASK, dss1);
> > }
> >
> > -static void dg2_ddi_pre_enable_dp(struct intel_atomic_state *state,
> > - struct intel_encoder *encoder,
> > - const struct intel_crtc_state *crtc_state,
> > - const struct drm_connector_state *conn_state)
> > -{
> > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > - struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > - bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> > -
> > - intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> > -crtc_state->lane_count);
> > -
> > - /*
> > -* We only configure what the register value will be here. Actual
> > -* enabling happens during link training farther down.
> > -*/
> > - intel_ddi_init_dp_buf_reg(encoder, crtc_state);
> > -
> > - /*
> > -* 1. Enable Power Wells
> > -*
> > -* This was handled at the beginning of intel_atomic_commit_tail(),
> > -* before we called down into this function.
> > -*/
> > -
> > - /* 2. Enable Panel Power if PPS is required */
> > - intel_pps_on(intel_dp);
> > -
> > - /*
> > -* 3. Enable the port PLL.
> > -*/
> > - intel_ddi_enable_clock(encoder, crtc_state);
> > -
> > - /* 4. Enable IO power */
> > - if (!intel_tc_port_in_tbt_alt_mode(dig_port))
> > - dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
> > -
> > dig_port->ddi_io_power_domain);
> > -
> > - /*
> > -* 5. The rest of the below are substeps under the bspec's "Enable and
> > -* Train Display Port" step. Note that steps that are specific to
> > -* MST will be handled by intel_mst_pre_enable_dp() before/after it
> > -* calls into this function. Also intel_mst_pre_enable_dp() only calls
> > -* us when active_mst_links==0, so any steps designated for "single
> > -* stream or multi-stream master transcoder" can just be performed
> > -* unconditionally here.
> > -*/
> > -
> > - /*
> > -* 5.a Configure Transcoder Clock Select to direct the Port clock to the
> > -* Transcoder.
> > -*/
> > - intel_ddi_enable_pipe_clock(encoder, crtc_state);
> > -
> > - /* 5.b Configure transcoder for DP 2.0 128b/132b */
> > - intel_ddi_config_transcoder_dp2(encoder, crtc_state);
> > -
> > - /*
> > -* 5.c Configure TRANS_DDI_FUNC_CTL DDI Select, DDI Mode Select & MST
> > -* Transport Select
> > -*/
> > - intel_ddi_config_transcoder_func(encoder, crtc_state);
> > -
> > - /*
> > -* 5.d Configure & enable DP_TP_CTL with link training pattern 1
> > -* selected
> > -*
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/uapi: document behaviour for DG2 64K support
Robert Beckett writes:
> From: Matthew Auld
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
> v2: Fixed suggestions on formatting [Daniel]
>
> Signed-off-by: Matthew Auld
> Signed-off-by: Ramalingam C
> Signed-off-by: Robert Beckett
> cc: Simon Ser
> cc: Pekka Paalanen
> Cc: Jordan Justen
> Cc: Kenneth Graunke
> Cc: mesa-...@lists.freedesktop.org
> Cc: Tony Ye
> Cc: Slawomir Milczarek
> ---
> include/uapi/drm/i915_drm.h | 44 -
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 5e678917da70..486b7b96291e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> /**
>* When the EXEC_OBJECT_PINNED flag is specified this is populated by
>* the user with the GTT offset at which this object will be pinned.
> + *
>* When the I915_EXEC_NO_RELOC flag is specified this must contain the
>* presumed_offset of the object.
> + *
>* During execbuffer2 the kernel populates it with the value of the
>* current GTT offset of the object, for future presumed_offset writes.
> + *
> + * See struct drm_i915_gem_create_ext for the rules when dealing with
> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> + * minimum page sizes, like DG2.
>*/
> __u64 offset;
>
> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
>*
>* The (page-aligned) allocated size for the object will be returned.
>*
> - * Note that for some devices we have might have further minimum
> - * page-size restrictions(larger than 4K), like for device local-memory.
> - * However in general the final size here should always reflect any
> - * rounding up, if for example using the
> I915_GEM_CREATE_EXT_MEMORY_REGIONS
> - * extension to place the object in device local-memory.
> + *
> + * **DG2 64K min page size implications:**
Long term, I'm not sure that the "**" (for emphasis) is needed here or
below. It's interesting at the moment, but will be just another thing
baked into the kernel/user code in a month from now. :)
> + *
> + * On discrete platforms, starting from DG2, we have to contend with GTT
> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> + * objects. Specifically the hardware only supports 64K or larger GTT
> + * page sizes for such memory. The kernel will already ensure that all
> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> + * sizes underneath.
> + *
> + * Note that the returned size here will always reflect any required
> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> + * such as DG2.
> + *
> + * **Special DG2 GTT address alignment requirement:**
> + *
> + * The GTT alignment will also need be at least 2M for such objects.
> + *
> + * Note that due to how the hardware implements 64K GTT page support, we
> + * have some further complications:
> + *
> + * 1) The entire PDE(which covers a 2MB virtual address range), must
> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> + * PDE is forbidden by the hardware.
> + *
> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> + * objects.
> + *
> + * To keep things simple for userland, we mandate that any GTT mappings
> + * must be aligned to and rounded up to 2MB. As this only wastes virtual
> + * address space and avoids userland having to copy any needlessly
> + * complicated PDE sharing scheme (coloring) and only affects GD2, this
> + * id deemed to be a good compromise.
typos: GD2, id
Isn't much of this more relavent to the vma offset at exec time? Is
there actually any new restriction on the size field during buffer
creation?
I see Matthew references these notes from the offset comments, so if the
kernel devs prefer it here, then you can add my Acked-by on this patch.
-Jordan
>*/
> __u64 size;
> /**
> --
> 2.25.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix vma resource freeing
== Series Details ==
Series: drm/i915: Fix vma resource freeing
URL : https://patchwork.freedesktop.org/series/99055/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11109 -> Patchwork_22025
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22025 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22025, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22025/index.html
Participating hosts (45 -> 42)
--
Missing(3): fi-bsw-cyan bat-jsl-2 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22025:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22025/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22025 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u: NOTRUN -> [FAIL][3] ([i915#4547])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22025/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [DMESG-FAIL][4] ([i915#541]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22025/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][6] ([i915#295]) -> [PASS][7] +12 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22025/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11109 -> Patchwork_22025
CI-20190529: 20190529
CI_DRM_11109: 72c0063cb976d8c82d8733fa20ca002b09ace98a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22025: 028b417caa705b6088d403c5d8750227001871b5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
028b417caa70 drm/i915: Fix vma resource freeing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22025/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
== Series Details ==
Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
URL : https://patchwork.freedesktop.org/series/99052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11109 -> Patchwork_22024
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/index.html
Participating hosts (45 -> 41)
--
Additional (1): fi-kbl-soraka
Missing(5): fi-bsw-cyan fi-icl-u2 fi-pnv-d510 bat-jsl-2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22024 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886] / [i915#2291])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][7] -> [DMESG-FAIL][8] ([i915#4494])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][11] ([fdo#109271]) +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [FAIL][14] ([i915#4547])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
Possible fixes
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [FAIL][15] ([i915#4547]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [DMESG-FAIL][17] ([i915#541]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22024/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][19] ([i915#4269]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11109/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[20]:
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
== Series Details == Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 URL : https://patchwork.freedesktop.org/series/99052/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_bios.c:2278: warning: Function parameter or member 'dev_priv' not described in 'intel_bios_is_valid_vbt'
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
== Series Details == Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 URL : https://patchwork.freedesktop.org/series/99052/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
== Series Details == Series: drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 URL : https://patchwork.freedesktop.org/series/99052/ State : warning == Summary == $ dim checkpatch origin/drm-tip be74e903c53e drm/i915/bios: Workaround broken video BIOS in LG Gram 2021 -:211: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #211: FILE: drivers/gpu/drm/i915/i915_drv.h:406: +#define QUIRK_USE_FW_SIZE_AS_VBT_SIZE (1<<9) ^ total: 0 errors, 0 warnings, 1 checks, 155 lines checked
Re: [Intel-gfx] [RE]: [PATCH v3 10/10] vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the mdev
On Mon, 2022-01-17 at 11:35 -0400, Jason Gunthorpe wrote: > On Fri, Jan 14, 2022 at 11:30:36AM -0500, Eric Farman wrote: > > On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote: > > > Hi Eric, > > > > > > Hope you are back from new year holiday.:-) Have you got chane to > > > consider > > > this patch? > > > > Hi Yi Liu, > > > > It's coming up the list, but it's not there yet. Haven't forgotten. > > :) > > Liu would like to see ccw use a normal lifecycle for the vfio_device > backing memory, is there a shorter path to achieve that then what I > came up with? Getting through your proposal is the task on our plate. Just not enough hours in the day at the moment, sorry. Eric > > Jason
Re: [Intel-gfx] [PATCH v9 1/6] drm: move the buddy allocator from i915 into common drm
Am 18.01.22 um 11:44 schrieb Arunpravin:
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
will be moved to drm selftest folder
cleanup i915 buddy references in i915 driver module
and replace with drm buddy
v2:
- include header file in alphabetical order(Thomas)
- merged changes listed in the body section into a single patch
to keep the build intact(Christian, Jani)
v3:
- make drm buddy a separate module(Thomas, Christian)
v4:
- Fix build error reported by kernel test robot
- removed i915 buddy selftest from i915_mock_selftests.h to
avoid build error
- removed selftests/i915_buddy.c file as we create a new set of
buddy test cases in drm/selftests folder
v5:
- Fix merge conflict issue
v6:
- replace drm_buddy_mm structure name as drm_buddy(Thomas, Christian)
- replace drm_buddy_alloc() function name as drm_buddy_alloc_blocks()
(Thomas)
- replace drm_buddy_free() function name as drm_buddy_free_block()
(Thomas)
- export drm_buddy_free_block() function
- fix multiple instances of KMEM_CACHE() entry
v7:
- fix warnings reported by kernel test robot
- modify the license(Christian)
v8:
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
I've just gone ahead and pushed this version here to drm-misc-next.
That should at least reduce the amount of mails send back and forth.
Let me know when there are more rbs on the rest and I will push that as
well.
Thanks,
Christian.
---
drivers/gpu/drm/Kconfig | 6 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_buddy.c | 535
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/i915_buddy.c | 466 ---
drivers/gpu/drm/i915/i915_buddy.h | 143
drivers/gpu/drm/i915/i915_module.c| 3 -
drivers/gpu/drm/i915/i915_scatterlist.c | 11 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 33 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_buddy.c | 787 --
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
.../drm/i915/selftests/intel_memory_region.c | 13 +-
include/drm/drm_buddy.h | 150
15 files changed, 725 insertions(+), 1431 deletions(-)
create mode 100644 drivers/gpu/drm/drm_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
create mode 100644 include/drm/drm_buddy.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 91f54aeb0b7c..cc3e979c9c9d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_BUDDY
+ tristate
+ depends on DRM
+ help
+ A page based buddy allocator
+
config DRM_VRAM_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 700abeb4945e..8675c2af7ae1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,8 @@ obj-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_cma_helper.o
drm_shmem_helper-y := drm_gem_shmem_helper.o
obj-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_shmem_helper.o
+obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
+
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
new file mode 100644
index ..d60878bc9c20
--- /dev/null
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -0,0 +1,535 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+static struct kmem_cache *slab_blocks;
+
+static struct drm_buddy_block *drm_block_alloc(struct drm_buddy *mm,
+ struct drm_buddy_block *parent,
+ unsigned int order,
+ u64 offset)
+{
+ struct drm_buddy_block *block;
+
+ BUG_ON(order > DRM_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+
Re: [Intel-gfx] [PATCH v2 0/5] Add driver for GSC controller
On Wed, Jan 19, 2022 at 05:58:02PM +0200, Alexander Usyskin wrote: > GSC is a graphics system controller, it provides > a chassis controller for graphics discrete cards. > > There are two MEI interfaces in GSC: HECI1 and HECI2. > > This series includes instantiation of the auxiliary devices for HECI2 > and mei-gsc auxiliary device driver that binds to the auxiliary device. > > In v2 the platform device was replaced by the auxiliary device. > > Greg KH, please review and ACK the MEI patches. > We are pushing all through gfx tree as the auxiliary device belongs there. I will review this after 5.17-rc1 is out. Please give us some time, there is no rush. greg k-h
[Intel-gfx] [PATCH] drm/i915: Fix vma resource freeing
In some cases we use leftover kfree() instead of i915_vma_resource_free().
Fix this.
Fixes: Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Reported-by: Robert Beckett
Cc: Matthew Auld
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
drivers/gpu/drm/i915/i915_vma_resource.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index b959e904c4d3..b1816a835abf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -464,7 +464,7 @@ int i915_vma_bind(struct i915_vma *vma,
if (vma->resource || !vma_res) {
/* Rebinding with an additional I915_VMA_*_BIND */
GEM_WARN_ON(!vma_flags);
- kfree(vma_res);
+ i915_vma_resource_free(vma_res);
} else {
i915_vma_resource_init_from_vma(vma_res, vma);
vma->resource = vma_res;
@@ -1462,7 +1462,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
err_unlock:
mutex_unlock(>vm->mutex);
err_vma_res:
- kfree(vma_res);
+ i915_vma_resource_free(vma_res);
err_fence:
if (work)
dma_fence_work_commit_imm(>base);
diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c
b/drivers/gpu/drm/i915/i915_vma_resource.c
index 1f41c0c699eb..6426c2f8a3b4 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.c
+++ b/drivers/gpu/drm/i915/i915_vma_resource.c
@@ -62,7 +62,8 @@ struct i915_vma_resource *i915_vma_resource_alloc(void)
*/
void i915_vma_resource_free(struct i915_vma_resource *vma_res)
{
- kmem_cache_free(slab_vma_resources, vma_res);
+ if (vma_res)
+ kmem_cache_free(slab_vma_resources, vma_res);
}
static const char *get_driver_name(struct dma_fence *fence)
--
2.31.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add driver for GSC controller (rev2)
== Series Details == Series: Add driver for GSC controller (rev2) URL : https://patchwork.freedesktop.org/series/98066/ State : failure == Summary == Applying: drm/i915/gsc: add gsc as a mei auxiliary device Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/Kconfig M drivers/gpu/drm/i915/Makefile M drivers/gpu/drm/i915/gt/intel_gt.c M drivers/gpu/drm/i915/gt/intel_gt.h M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_pci.c M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_device_info.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_device_info.h Auto-merging drivers/gpu/drm/i915/i915_reg.h Auto-merging drivers/gpu/drm/i915/i915_pci.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/gt/intel_gt.h Auto-merging drivers/gpu/drm/i915/gt/intel_gt.c Auto-merging drivers/gpu/drm/i915/Makefile Auto-merging drivers/gpu/drm/i915/Kconfig CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/Kconfig error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/gsc: add gsc as a mei auxiliary device When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH 0/7] DRM kmap() fixes and kmap_local_page() conversions
On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira Weiny wrote: > On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote: > > From: Ira Weiny > > > > This series starts by converting the last easy kmap() uses to > > kmap_local_page(). > > > > There is one more call to kmap() wrapped in ttm_bo_kmap_ttm(). > > Unfortunately, > > ttm_bo_kmap_ttm() is called in a number of different ways including some > > which > > are not thread local. I have a patch to convert that call. However, it is > > not > > straight forward so it is not included in this series. > > > > The final 2 patches fix bugs found while working on the ttm_bo_kmap_ttm() > > conversion. > > Gentile ping on this series? Will it make this merge window? I think this fell through the cracks and so no. Note that generally we feature-freeze drm tree around -rc6 anyway for the upcoming merge window, so you were cutting this all a bit close anyway. Also looks like the ttm kmap caching question didn't get resolved? Anyway if patches are stuck resend with RESEND and if people still don't pick them up poke me and I'll apply as fallback. Cheers, Daniel > > Thanks, > Ira > > > > > > > Ira Weiny (7): > > drm/i915: Replace kmap() with kmap_local_page() > > drm/amd: Replace kmap() with kmap_local_page() > > drm/gma: Remove calls to kmap() > > drm/radeon: Replace kmap() with kmap_local_page() > > drm/msm: Alter comment to use kmap_local_page() > > drm/amdgpu: Ensure kunmap is called on error > > drm/radeon: Ensure kunmap is called on error > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 > > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 + > > drivers/gpu/drm/gma500/gma_display.c | 6 ++ > > drivers/gpu/drm/gma500/mmu.c | 8 > > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++-- > > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- > > drivers/gpu/drm/i915/gt/shmem_utils.c | 4 ++-- > > drivers/gpu/drm/i915/i915_gem.c | 8 > > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > > drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++-- > > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > > drivers/gpu/drm/radeon/radeon_uvd.c | 1 + > > 13 files changed, 32 insertions(+), 32 deletions(-) > > > > -- > > 2.31.1 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 0/7] DRM kmap() fixes and kmap_local_page() conversions
On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote: > From: Ira Weiny > > This series starts by converting the last easy kmap() uses to > kmap_local_page(). > > There is one more call to kmap() wrapped in ttm_bo_kmap_ttm(). Unfortunately, > ttm_bo_kmap_ttm() is called in a number of different ways including some which > are not thread local. I have a patch to convert that call. However, it is > not > straight forward so it is not included in this series. > > The final 2 patches fix bugs found while working on the ttm_bo_kmap_ttm() > conversion. Gentile ping on this series? Will it make this merge window? Thanks, Ira > > > Ira Weiny (7): > drm/i915: Replace kmap() with kmap_local_page() > drm/amd: Replace kmap() with kmap_local_page() > drm/gma: Remove calls to kmap() > drm/radeon: Replace kmap() with kmap_local_page() > drm/msm: Alter comment to use kmap_local_page() > drm/amdgpu: Ensure kunmap is called on error > drm/radeon: Ensure kunmap is called on error > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 + > drivers/gpu/drm/gma500/gma_display.c | 6 ++ > drivers/gpu/drm/gma500/mmu.c | 8 > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++-- > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- > drivers/gpu/drm/i915/gt/shmem_utils.c | 4 ++-- > drivers/gpu/drm/i915/i915_gem.c | 8 > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_uvd.c | 1 + > 13 files changed, 32 insertions(+), 32 deletions(-) > > -- > 2.31.1 >
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
> > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
> return "yes\0no" + v * 4;
>
> :-)
except '"no\0\0yes" + v * 4' works a bit better.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
> > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
return "yes\0no" + v * 4;
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [Intel-gfx] [PATCH 0/3] lib/string_helpers: Add a few string helpers
On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote: > On Wed, 19 Jan 2022, Petr Mladek wrote: > > On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote: > >> Add some helpers under lib/string_helpers.h so they can be used > >> throughout the kernel. When I started doing this there were 2 other > >> previous attempts I know of, not counting the iterations each of them > >> had: > >> > >> 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/ > >> 2) > >> https://lore.kernel.org/all/20210215142137.64476-1-andriy.shevche...@linux.intel.com/#t > >> > >> Going through the comments I tried to find some common ground and > >> justification for what is in here, addressing some of the concerns > >> raised. > >> > >> d. This doesn't bring onoff() helper as there are some places in the > >>kernel with onoff as variable - another name is probably needed for > >>this function in order not to shadow the variable, or those variables > >>could be renamed. Or if people wanting > >>try to find a short one > > > > I would call it str_on_off(). > > > > And I would actually suggest to use the same style also for > > the other helpers. > > > > The "str_" prefix would make it clear that it is something with > > string. There are other _on_off() that affect some > > functionality, e.g. mute_led_on_off(), e1000_vlan_filter_on_off(). > > > > The dash '_' would significantly help to parse the name. yesno() and > > onoff() are nicely short and kind of acceptable. But "enabledisable()" > > is a puzzle. > > > > IMHO, str_yes_no(), str_on_off(), str_enable_disable() are a good > > compromise. > > > > The main motivation should be code readability. You write the > > code once. But many people will read it many times. Open coding > > is sometimes better than misleading macro names. > > > > That said, I do not want to block this patchset. If others like > > it... ;-) > > I don't mind the names either way. Adding the prefix and dashes is > helpful in that it's possible to add the functions first and convert > users at leisure, though with a bunch of churn, while using names that > collide with existing ones requires the changes to happen in one go. > > What I do mind is grinding this series to a halt once again. I sent a > handful of versions of this three years ago, with inconclusive > bikeshedding back and forth, eventually threw my hands up in disgust, > and walked away. Yeah we can sed this anytime later we want to, but we need to get the foot in the door. There's also a pile more of these all over. Acked-by: Daniel Vetter on the series, maybe it helps? And yes let's merge this through drm-misc. -Daniel > > > > > > >> e. One alternative to all of this suggested by Christian König > >>(43456ba7-c372-84cc-4949-dcb817188...@amd.com) would be to add a > >>printk format. But besides the comment, he also seemed to like > >>the common function. This brought the argument from others that the > >>simple yesno()/enabledisable() already used in the code is easier to > >>remember and use than e.g. %py[DOY] > > > > Thanks for not going this way :-) > > > >> Last patch also has some additional conversion of open coded cases. I > >> preferred starting with drm/ since this is "closer to home". > >> > >> I hope this is a good summary of the previous attempts and a way we can > >> move forward. > >> > >> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my > >> proposal is to take first 2 patches either through mm tree or maybe > >> vsprintf. Last patch can be taken later through drm. > > > > I agree with Andy that it should go via drm tree. It would make it > > easier to handle potential conflicts. > > > > Just in case, you decide to go with str_yes_no() or something similar. > > Mass changes are typically done at the end on the merge window. > > The best solution is when it can be done by a script. > > > > Best Regards, > > Petr > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm/i915/bios: Workaround broken video BIOS in LG Gram 2021
LG Gram 2021 laptop 17Z95P-K.ADE9U1 OpRegion has
FW size: 0x2200
VBT size: 0x2000
BDB offset: 0x30
BDB size: 0x216e
Add intel_init_opregion_quirks to use FW size as VBT size on LG Gram
17Z95P-K.ADE9U1 and update intel_bios_is_valid_vbt to use FW size,
instead of VBT size if the quirk is applied, in range_overflows_t for
BDB size overflow check. This fixes:
https://gitlab.freedesktop.org/drm/intel/-/issues/4763
Signed-off-by: H.J. Lu
---
drivers/gpu/drm/i915/display/intel_bios.c | 14 ---
drivers/gpu/drm/i915/display/intel_bios.h | 3 +-
drivers/gpu/drm/i915/display/intel_opregion.c | 9 +++--
drivers/gpu/drm/i915/display/intel_quirks.c | 40 +++
drivers/gpu/drm/i915/display/intel_quirks.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
6 files changed, 58 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7d04572dd18b..4e960eb45a5a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2273,7 +2273,8 @@ static const struct bdb_header *get_bdb_header(const
struct vbt_header *vbt)
*
* Returns true on valid VBT.
*/
-bool intel_bios_is_valid_vbt(const void *buf, size_t size)
+bool intel_bios_is_valid_vbt(struct drm_i915_private *dev_priv,
+const void *buf, size_t size)
{
const struct vbt_header *vbt = buf;
const struct bdb_header *bdb;
@@ -2296,16 +2297,17 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
size)
return false;
}
- size = vbt->vbt_size;
-
if (range_overflows_t(size_t,
vbt->bdb_offset,
sizeof(struct bdb_header),
- size)) {
+ vbt->vbt_size)) {
DRM_DEBUG_DRIVER("BDB header incomplete\n");
return false;
}
+ if (!(dev_priv->quirks & QUIRK_USE_FW_SIZE_AS_VBT_SIZE))
+ size = vbt->vbt_size;
+
bdb = get_bdb_header(vbt);
if (range_overflows_t(size_t, vbt->bdb_offset, bdb->bdb_size, size)) {
DRM_DEBUG_DRIVER("BDB incomplete\n");
@@ -2359,7 +2361,7 @@ static struct vbt_header *spi_oprom_get_vbt(struct
drm_i915_private *i915)
*(vbt + store++) = data;
}
- if (!intel_bios_is_valid_vbt(vbt, vbt_size))
+ if (!intel_bios_is_valid_vbt(i915, vbt, vbt_size))
goto err_free_vbt;
drm_dbg_kms(>drm, "Found valid VBT in SPI flash\n");
@@ -2416,7 +2418,7 @@ static struct vbt_header *oprom_get_vbt(struct
drm_i915_private *i915)
memcpy_fromio(vbt, p, vbt_size);
- if (!intel_bios_is_valid_vbt(vbt, vbt_size))
+ if (!intel_bios_is_valid_vbt(i915, vbt, vbt_size))
goto err_free_vbt;
pci_unmap_rom(pdev, oprom);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4709c4d29805..368ee87390e7 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -231,7 +231,8 @@ struct mipi_pps_data {
void intel_bios_init(struct drm_i915_private *dev_priv);
void intel_bios_driver_remove(struct drm_i915_private *dev_priv);
-bool intel_bios_is_valid_vbt(const void *buf, size_t size);
+bool intel_bios_is_valid_vbt(struct drm_i915_private *dev_priv,
+const void *buf, size_t size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port
port);
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index af9d30f56cc1..7a9b4d72d18c 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -36,6 +36,7 @@
#include "intel_display_types.h"
#include "intel_opregion.h"
#include "intel_pci_config.h"
+#include "intel_quirks.h"
#define OPREGION_HEADER_OFFSET 0
#define OPREGION_ACPI_OFFSET 0x100
@@ -817,7 +818,7 @@ static int intel_load_vbt_firmware(struct drm_i915_private
*dev_priv)
return ret;
}
- if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
+ if (intel_bios_is_valid_vbt(dev_priv, fw->data, fw->size)) {
opregion->vbt_firmware = kmemdup(fw->data, fw->size,
GFP_KERNEL);
if (opregion->vbt_firmware) {
drm_dbg_kms(_priv->drm,
@@ -922,6 +923,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (dmi_check_system(intel_no_opregion_vbt))
goto out;
+ intel_init_opregion_quirks(dev_priv);
+
if (opregion->header->over.major >= 2 && opregion->asle &&
opregion->asle->rvda &&
[Intel-gfx] [PATCH v2 5/5] mei: gsc: retrieve the firmware version
Add a hook to retrieve the firmware version of the
GSC devices to bus-fixup.
GSC has a different MKHI clients GUIDs but the same message structure
to retrieve the firmware version as MEI so mei_fwver() can be reused.
CC: Ashutosh Dixit
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 25 +
drivers/misc/mei/hw-me.c | 2 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 67844089db21..59506ba6fc48 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -30,6 +30,12 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
#define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
+#define MEI_UUID_IGSC_MKHI UUID_LE(0xE2C2AFA2, 0x3817, 0x4D19, \
+ 0x9D, 0x95, 0x06, 0xB1, 0x6B, 0x58, 0x8A, 0x5D)
+
+#define MEI_UUID_IGSC_MKHI_FIX UUID_LE(0x46E0C1FB, 0xA546, 0x414F, \
+ 0x91, 0x70, 0xB7, 0xF4, 0x6D, 0x57, 0xB4, 0xAD)
+
#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
@@ -241,6 +247,23 @@ static void mei_mkhi_fix(struct mei_cl_device *cldev)
mei_cldev_disable(cldev);
}
+static void mei_gsc_mkhi_ver(struct mei_cl_device *cldev)
+{
+ int ret;
+
+ /* No need to enable the client if nothing is needed from it */
+ if (!cldev->bus->fw_f_fw_ver_supported)
+ return;
+
+ ret = mei_cldev_enable(cldev);
+ if (ret)
+ return;
+
+ ret = mei_fwver(cldev);
+ if (ret < 0)
+ dev_err(>dev, "FW version command failed %d\n", ret);
+ mei_cldev_disable(cldev);
+}
/**
* mei_wd - wd client on the bus, change protocol version
* as the API has changed.
@@ -492,6 +515,8 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI, mei_gsc_mkhi_ver),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_ver),
MEI_FIXUP(MEI_UUID_HDCP, whitelist),
MEI_FIXUP(MEI_UUID_ANY, vt_support),
MEI_FIXUP(MEI_UUID_PAVP, whitelist),
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 9748d14849a1..7e77328142ff 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -1577,12 +1577,14 @@ static const struct mei_cfg mei_me_pch15_sps_cfg = {
static const struct mei_cfg mei_me_gsc_cfg = {
MEI_CFG_TYPE_GSC,
MEI_CFG_PCH8_HFS,
+ MEI_CFG_FW_VER_SUPP,
};
/* Graphics System Controller Firmware Interface */
static const struct mei_cfg mei_me_gscfi_cfg = {
MEI_CFG_TYPE_GSCFI,
MEI_CFG_PCH8_HFS,
+ MEI_CFG_FW_VER_SUPP,
};
/*
--
2.32.0
[Intel-gfx] [PATCH v2 4/5] mei: gsc: add runtime pm handlers
From: Tomas Winkler
Implement runtime handlers for mei-gsc, to track
idle state of the device properly.
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/gsc-me.c | 80 ++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index f58e54d2c1fc..fddae8009b62 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -158,7 +158,85 @@ static int __maybe_unused mei_gsc_pm_resume(struct device
*device)
return 0;
}
-static SIMPLE_DEV_PM_OPS(mei_gsc_pm_ops, mei_gsc_pm_suspend,
mei_gsc_pm_resume);
+static int __maybe_unused mei_gsc_pm_runtime_idle(struct device *device)
+{
+ struct mei_device *dev;
+
+ dev_dbg(device, "rpm: me: runtime_idle\n");
+
+ dev = dev_get_drvdata(device);
+ if (!dev)
+ return -ENODEV;
+ if (mei_write_is_idle(dev))
+ pm_runtime_autosuspend(device);
+
+ return -EBUSY;
+}
+
+static int __maybe_unused mei_gsc_pm_runtime_suspend(struct device *device)
+{
+ struct mei_device *dev;
+ struct mei_me_hw *hw;
+ int ret;
+
+ dev_dbg(device, "rpm: me: runtime suspend\n");
+
+ dev = dev_get_drvdata(device);
+ if (!dev)
+ return -ENODEV;
+
+ mutex_lock(>device_lock);
+
+ if (mei_write_is_idle(dev)) {
+ hw = to_me_hw(dev);
+ hw->pg_state = MEI_PG_ON;
+ ret = 0;
+ } else {
+ ret = -EAGAIN;
+ }
+
+ mutex_unlock(>device_lock);
+
+ dev_dbg(device, "rpm: me: runtime suspend ret=%d\n", ret);
+
+ return ret;
+}
+
+static int __maybe_unused mei_gsc_pm_runtime_resume(struct device *device)
+{
+ struct mei_device *dev;
+ struct mei_me_hw *hw;
+ irqreturn_t irq_ret;
+
+ dev_dbg(device, "rpm: me: runtime resume\n");
+
+ dev = dev_get_drvdata(device);
+ if (!dev)
+ return -ENODEV;
+
+ mutex_lock(>device_lock);
+
+ hw = to_me_hw(dev);
+ hw->pg_state = MEI_PG_OFF;
+
+ mutex_unlock(>device_lock);
+
+ irq_ret = mei_me_irq_thread_handler(1, dev);
+ if (irq_ret != IRQ_HANDLED)
+ dev_err(dev->dev, "thread handler fail %d\n", irq_ret);
+
+ dev_dbg(device, "rpm: me: runtime resume ret = 0\n");
+
+ return 0;
+}
+
+static const struct dev_pm_ops mei_gsc_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mei_gsc_pm_suspend,
+ mei_gsc_pm_resume)
+ SET_RUNTIME_PM_OPS(mei_gsc_pm_runtime_suspend,
+ mei_gsc_pm_runtime_resume,
+ mei_gsc_pm_runtime_idle)
+};
static const struct auxiliary_device_id mei_gsc_id_table[] = {
{
--
2.32.0
[Intel-gfx] [PATCH v2 3/5] mei: gsc: setup char driver alive in spite of firmware handshake failure
Setup char device in spite of firmware handshake failure.
In order to provide host access to the firmware status registers and other
information required for the manufacturing process.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/gsc-me.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index 8673ad5f0015..f58e54d2c1fc 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -79,11 +79,12 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
pm_runtime_set_active(device);
pm_runtime_enable(device);
- if (mei_start(dev)) {
- dev_err(device, "init hw failure.\n");
- ret = -ENODEV;
- goto err;
- }
+ /* Continue to char device setup in spite of firmware handshake failure.
+* In order to provide access to the firmware status registers to the
user
+* space via sysfs.
+*/
+ if (mei_start(dev))
+ dev_warn(device, "init hw failure.\n");
pm_runtime_set_autosuspend_delay(device, MEI_GSC_RPM_TIMEOUT);
pm_runtime_use_autosuspend(device);
--
2.32.0
[Intel-gfx] [PATCH v2 1/5] drm/i915/gsc: add gsc as a mei auxiliary device
From: Tomas Winkler
GSC is a graphics system controller, it provides
a chassis controller for graphics discrete cards.
There are two MEI interfaces in GSC: HECI1 and HECI2.
Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000.
GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled
via bit 15 and HECI2 via bit 14 in the interrupt register.
This patch exports GSC as auxiliary device for mei driver to bind to
for HECI2 interface.
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile| 3 +
drivers/gpu/drm/i915/gt/intel_gsc.c | 200 +++
drivers/gpu/drm/i915/gt/intel_gsc.h | 37 +
drivers/gpu/drm/i915/gt/intel_gt.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_drv.h | 8 +
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_device_info.h | 2 +
include/linux/mei_aux.h | 19 +++
13 files changed, 298 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.h
create mode 100644 include/linux/mei_aux.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a4c94dc2e216..92ae210d3e53 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -27,6 +27,7 @@ config DRM_I915
select CEC_CORE if CEC_NOTIFIER
select VMAP_PFN
select DRM_TTM
+ select AUXILIARY_BUS
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 213c5f9fae32..d758d6c5fc45 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -193,6 +193,9 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_huc_debugfs.o \
gt/uc/intel_huc_fw.o
+# graphics system controller (GSC) support
+i915-y += gt/intel_gsc.o
+
# modesetting core code
i915-y += \
display/intel_atomic.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c
b/drivers/gpu/drm/i915/gt/intel_gsc.c
new file mode 100644
index ..3fb1018dfe2d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2022, Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "intel_gsc.h"
+
+#define GSC_BAR_LENGTH 0x0FFC
+
+static void gsc_irq_mask(struct irq_data *d)
+{
+ /* generic irq handling */
+}
+
+static void gsc_irq_unmask(struct irq_data *d)
+{
+ /* generic irq handling */
+}
+
+static struct irq_chip gsc_irq_chip = {
+ .name = "gsc_irq_chip",
+ .irq_mask = gsc_irq_mask,
+ .irq_unmask = gsc_irq_unmask,
+};
+
+static int gsc_irq_init(struct drm_i915_private *dev_priv, int irq)
+{
+ irq_set_chip_and_handler_name(irq, _irq_chip,
+ handle_simple_irq, "gsc_irq_handler");
+
+ return irq_set_chip_data(irq, dev_priv);
+}
+
+struct intel_gsc_def {
+ const char *name;
+ const unsigned long bar;
+ size_t bar_size;
+};
+
+/* gscfi (graphics system controller firmware interface) resources */
+static const struct intel_gsc_def intel_gsc_def_dg1[] = {
+ {
+ },
+ {
+ .name = "mei-gscfi",
+ .bar = GSC_DG1_HECI2_BASE,
+ .bar_size = GSC_BAR_LENGTH,
+ }
+};
+
+static void intel_gsc_release_dev(struct device *dev)
+{
+ struct auxiliary_device *aux_dev = to_auxiliary_dev(dev);
+ struct mei_aux_device *adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+
+ kfree(adev);
+}
+
+static void intel_gsc_destroy_one(struct intel_gsc_intf *intf)
+{
+
+ if (intf->adev) {
+ auxiliary_device_delete(>adev->aux_dev);
+ auxiliary_device_uninit(>adev->aux_dev);
+ intf->adev = NULL;
+ }
+ if (intf->irq >= 0)
+ irq_free_desc(intf->irq);
+ intf->irq = -1;
+}
+
+static void intel_gsc_init_one(struct drm_i915_private *dev_priv,
+ struct intel_gsc_intf *intf,
+ unsigned int intf_id)
+{
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
+ struct mei_aux_device *adev;
+ struct auxiliary_device *aux_dev;
+ const struct intel_gsc_def *def;
+ int ret;
+
+ intf->irq = -1;
+ intf->id = intf_id;
+
+ if (intf_id == 0 && !HAS_HECI_PXP(dev_priv))
+ return;
[Intel-gfx] [PATCH v2 0/5] Add driver for GSC controller
GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. This series includes instantiation of the auxiliary devices for HECI2 and mei-gsc auxiliary device driver that binds to the auxiliary device. In v2 the platform device was replaced by the auxiliary device. Greg KH, please review and ACK the MEI patches. We are pushing all through gfx tree as the auxiliary device belongs there. Alexander Usyskin (2): mei: gsc: setup char driver alive in spite of firmware handshake failure mei: gsc: retrieve the firmware version Tomas Winkler (3): drm/i915/gsc: add gsc as a mei auxiliary device mei: add support for graphics system controller (gsc) devices mei: gsc: add runtime pm handlers drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile| 3 + drivers/gpu/drm/i915/gt/intel_gsc.c | 200 + drivers/gpu/drm/i915/gt/intel_gsc.h | 37 drivers/gpu/drm/i915/gt/intel_gt.c | 3 + drivers/gpu/drm/i915/gt/intel_gt.h | 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 + drivers/gpu/drm/i915/i915_drv.h | 8 + drivers/gpu/drm/i915/i915_pci.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 3 + drivers/gpu/drm/i915/intel_device_info.h | 2 + drivers/misc/mei/Kconfig | 14 ++ drivers/misc/mei/Makefile| 3 + drivers/misc/mei/bus-fixup.c | 25 +++ drivers/misc/mei/gsc-me.c| 271 +++ drivers/misc/mei/hw-me.c | 29 ++- drivers/misc/mei/hw-me.h | 2 + include/linux/mei_aux.h | 19 ++ 19 files changed, 640 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.h create mode 100644 drivers/misc/mei/gsc-me.c create mode 100644 include/linux/mei_aux.h -- 2.32.0
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Nuke dg2_ddi_pre_enable_dp()
== Series Details ==
Series: drm/i915: Nuke dg2_ddi_pre_enable_dp()
URL : https://patchwork.freedesktop.org/series/99041/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11104_full -> Patchwork_22022_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22022_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22022_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22022_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-fences-interruptible@b-vga1:
- shard-snb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-snb5/igt@kms_flip@flip-vs-fences-interrupti...@b-vga1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-snb6/igt@kms_flip@flip-vs-fences-interrupti...@b-vga1.html
* igt@syncobj_timeline@wait-all-snapshot:
- shard-skl: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-skl8/igt@syncobj_timel...@wait-all-snapshot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-skl3/igt@syncobj_timel...@wait-all-snapshot.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- {shard-tglu}: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-tglu-7/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-tglu-1/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@runner@aborted:
- {shard-tglu}: ([FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10])
([i915#3002] / [i915#3690] / [i915#4312]) -> ([FAIL][11], [FAIL][12])
([i915#3002] / [i915#4312])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-tglu-4/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-tglu-2/igt@run...@aborted.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-tglu-3/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-tglu-2/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-tglu-6/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-tglu-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_22022_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@kms:
- shard-skl: [PASS][13] -> [TIMEOUT][14] ([i915#3063])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-skl8/igt@gem_...@kms.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-skl3/igt@gem_...@kms.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][15] -> [SKIP][16] ([i915#4525]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-iclb1/igt@gem_exec_balan...@parallel-out-fence.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-iclb3/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_capture@pi@vcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][17] ([i915#4547])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-skl8/igt@gem_exec_capture@p...@vcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][18] -> [FAIL][19] ([i915#2846])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][20] -> [FAIL][21] ([i915#2842]) +2 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglb: NOTRUN -> [FAIL][22] ([i915#2842])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/shard-tglb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_params@secure-non-master:
Re: [Intel-gfx] [PATCH] drm/i915: Nuke dg2_ddi_pre_enable_dp()
On Wed, 19 Jan 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate
> it.
>
> The one thing that tgl_ddi_pre_enable_dp() is missing that we
> need is intel_ddi_config_transcoder_dp2(). So we'll bring that
> over.
>
> tgl_ddi_pre_enable_dp() does also have a few things that
> dg2_ddi_pre_enable_dp() didn't have:
> - icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2
> - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on DG2
> - intel_ddi_mso_configure() -> only matters for MSO panels
>
> Another slight difference is that dg2_ddi_pre_enable_dp() was
> missing a bigjoiner check around intel_dsc_enable(), which
> tgl_ddi_pre_enable_dp() does have.
Reviewed-by: Jani Nikula
The modeset step bspec references could use a cleanup too. If they
aren't stable number combos for *one* platform, let alone many,
we should probably just remove them.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 117 +--
> 1 file changed, 4 insertions(+), 113 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4e93eac926a5..2f20abc5122d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2289,116 +2289,6 @@ static void intel_ddi_mso_configure(const struct
> intel_crtc_state *crtc_state)
>OVERLAP_PIXELS_MASK, dss1);
> }
>
> -static void dg2_ddi_pre_enable_dp(struct intel_atomic_state *state,
> - struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state,
> - const struct drm_connector_state *conn_state)
> -{
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> - bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> -
> - intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> - crtc_state->lane_count);
> -
> - /*
> - * We only configure what the register value will be here. Actual
> - * enabling happens during link training farther down.
> - */
> - intel_ddi_init_dp_buf_reg(encoder, crtc_state);
> -
> - /*
> - * 1. Enable Power Wells
> - *
> - * This was handled at the beginning of intel_atomic_commit_tail(),
> - * before we called down into this function.
> - */
> -
> - /* 2. Enable Panel Power if PPS is required */
> - intel_pps_on(intel_dp);
> -
> - /*
> - * 3. Enable the port PLL.
> - */
> - intel_ddi_enable_clock(encoder, crtc_state);
> -
> - /* 4. Enable IO power */
> - if (!intel_tc_port_in_tbt_alt_mode(dig_port))
> - dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
> -
> dig_port->ddi_io_power_domain);
> -
> - /*
> - * 5. The rest of the below are substeps under the bspec's "Enable and
> - * Train Display Port" step. Note that steps that are specific to
> - * MST will be handled by intel_mst_pre_enable_dp() before/after it
> - * calls into this function. Also intel_mst_pre_enable_dp() only calls
> - * us when active_mst_links==0, so any steps designated for "single
> - * stream or multi-stream master transcoder" can just be performed
> - * unconditionally here.
> - */
> -
> - /*
> - * 5.a Configure Transcoder Clock Select to direct the Port clock to the
> - * Transcoder.
> - */
> - intel_ddi_enable_pipe_clock(encoder, crtc_state);
> -
> - /* 5.b Configure transcoder for DP 2.0 128b/132b */
> - intel_ddi_config_transcoder_dp2(encoder, crtc_state);
> -
> - /*
> - * 5.c Configure TRANS_DDI_FUNC_CTL DDI Select, DDI Mode Select & MST
> - * Transport Select
> - */
> - intel_ddi_config_transcoder_func(encoder, crtc_state);
> -
> - /*
> - * 5.d Configure & enable DP_TP_CTL with link training pattern 1
> - * selected
> - *
> - * This will be handled by the intel_dp_start_link_train() farther
> - * down this function.
> - */
> -
> - /* 5.e Configure voltage swing and related IO settings */
> - encoder->set_signal_levels(encoder, crtc_state);
> -
> - if (!is_mst)
> - intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
> -
> - intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> - intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
> - /*
> - * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
> - * in the FEC_CONFIGURATION register to 1 before initiating link
> - * training
> - */
> -
Re: [Intel-gfx] [PATCH 6/7] drm: Document fdinfo format specification
On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Proposal to standardise the fdinfo text format as optionally output by DRM > drivers. > > Idea is that a simple but, well defined, spec will enable generic > userspace tools to be written while at the same time avoiding a more heavy > handed approach of adding a mid-layer to DRM. > > i915 implements a subset of the spec, everything apart from the memory > stats currently, and a matching intel_gpu_top tool exists. > > Open is to see if AMD can migrate to using the proposed GPU utilisation > key-value pairs, or if they are not workable to see whether to go > vendor specific, or if a standardised alternative can be found which is > workable for both drivers. > > Same for the memory utilisation key-value pairs proposal. > > v2: > * Update for removal of name and pid. > > v3: > * 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel) > > Signed-off-by: Tvrtko Ursulin > Cc: David M Nieto > Cc: Christian König > Cc: Daniel Vetter > Cc: Daniel Stone > Cc: Chris Healy > Acked-by: Christian König I'm assuming this ack here and later on is a "amdgpu plans to use this too" kind of affair. Especially also in the lights of eventually using matching semantics for cgroups and everything else tied to gpu execution resource management. If not I'm mildly worried that we're creating fake-standard stuff here which cannot actually be used by anything resembling driver-agnostic userspace. -Daniel > --- > Documentation/gpu/drm-usage-stats.rst | 97 +++ > Documentation/gpu/index.rst | 1 + > 2 files changed, 98 insertions(+) > create mode 100644 Documentation/gpu/drm-usage-stats.rst > > diff --git a/Documentation/gpu/drm-usage-stats.rst > b/Documentation/gpu/drm-usage-stats.rst > new file mode 100644 > index ..c669026be244 > --- /dev/null > +++ b/Documentation/gpu/drm-usage-stats.rst > @@ -0,0 +1,97 @@ > +.. _drm-client-usage-stats: > + > +== > +DRM client usage stats > +== > + > +DRM drivers can choose to export partly standardised text output via the > +`fops->show_fdinfo()` as part of the driver specific file operations > registered > +in the `struct drm_driver` object registered with the DRM core. > + > +One purpose of this output is to enable writing as generic as practicaly > +feasible `top(1)` like userspace monitoring tools. > + > +Given the differences between various DRM drivers the specification of the > +output is split between common and driver specific parts. Having said that, > +wherever possible effort should still be made to standardise as much as > +possible. > + > +File format specification > += > + > +- File shall contain one key value pair per one line of text. > +- Colon character (`:`) must be used to delimit keys and values. > +- All keys shall be prefixed with `drm-`. > +- Whitespace between the delimiter and first non-whitespace character shall > be > + ignored when parsing. > +- Neither keys or values are allowed to contain whitespace characters. > +- Numerical key value pairs can end with optional unit string. > +- Data type of the value is fixed as defined in the specification. > + > +Key types > +- > + > +1. Mandatory, fully standardised. > +2. Optional, fully standardised. > +3. Driver specific. > + > +Data types > +-- > + > +- - Unsigned integer without defining the maximum value. > +- - String excluding any above defined reserved characters or > whitespace. > + > +Mandatory fully standardised keys > +- > + > +- drm-driver: > + > +String shall contain the name this driver registered as via the respective > +`struct drm_driver` data structure. > + > +Optional fully standardised keys > + > + > +- drm-pdev: > + > +For PCI devices this should contain the PCI slot address of the device in > +question. > + > +- drm-client-id: > + > +Unique value relating to the open DRM file descriptor used to distinguish > +duplicated and shared file descriptors. Conceptually the value should map 1:1 > +to the in kernel representation of `struct drm_file` instances. > + > +Uniqueness of the value shall be either globally unique, or unique within the > +scope of each device, in which case `drm-pdev` shall be present as well. > + > +Userspace should make sure to not double account any usage statistics by > using > +the above described criteria in order to associate data to individual > clients. > + > +- drm-engine-: ns > + > +GPUs usually contain multiple execution engines. Each shall be given a stable > +and unique name (str), with possible values documented in the driver specific > +documentation. > + > +Value shall be in specified time units which the respective GPU engine spent > +busy executing workloads belonging to this client. > + > +Values are not required to be constantly monotonic
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 19 Jan 2022 11:18:59 +0200 Sakari Ailus wrote: > On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote: > > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct > > tomoyo_io_buffer *head, > > case 3: > > if (cond->grant_log != TOMOYO_GRANTLOG_AUTO) > > tomoyo_io_printf(head, " grant_log=%s", > > -tomoyo_yesno(cond->grant_log == > > - TOMOYO_GRANTLOG_YES)); > > +yesno(cond->grant_log == > > TOMOYO_GRANTLOG_YES)); > > This would be better split on two lines. Really? Yuck! I thought the "max line size" guideline was going to grow to a 100, but I still see it as 80. But anyway... cond->grant_log == TOMOYO_GRANTLOG_YES is not readable at all. Not compared to cond->grant_log == TOMOYO_GRANTLOG_YES I say keep it one line! Reviewed-by: Steven Rostedt (Google) -- Steve > > Then, > > Reviewed-by: Sakari Ailus
Re: [Intel-gfx] [PATCH] drm/i915: Remove zombie async flip vt-d w/a
On Wed, 08 Dec 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This async flip vt-d w/a was moved to a different place in
> commit 7d396cacaea6 ("drm/i195: Make the async flip VT-d workaround
> dynamic") but the drm-intel-fixes cherry-pick commit b2d73debfdc1
> ("drm/i915: Extend the async flip VT-d w/a to skl/bxt") resurrected
> the original code as well. So now we have this w/a in two places.
> Remove the resurrected zombie code.
>
> Not done as a revert to hopefully prevent any kind of
> automagic stable backport.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_pm.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fe3787425780..31767c583cd0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -78,8 +78,6 @@ struct intel_wm_config {
>
> static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - enum pipe pipe;
> -
> if (HAS_LLC(dev_priv)) {
> /*
>* WaCompressedResourceDisplayNewHashMode:skl,kbl
> @@ -93,16 +91,6 @@ static void gen9_init_clock_gating(struct drm_i915_private
> *dev_priv)
> SKL_DE_COMPRESSED_HASH_MODE);
> }
>
> - for_each_pipe(dev_priv, pipe) {
> - /*
> - * "Plane N strech max must be programmed to 11b (x1)
> - * when Async flips are enabled on that plane."
> - */
> - if (!IS_GEMINILAKE(dev_priv) && intel_vtd_active(dev_priv))
> - intel_uncore_rmw(_priv->uncore,
> CHICKEN_PIPESL_1(pipe),
> - SKL_PLANE1_STRETCH_MAX_MASK,
> SKL_PLANE1_STRETCH_MAX_X1);
> - }
> -
> /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl,cfl */
> intel_uncore_write(_priv->uncore, CHICKEN_PAR1_1,
> intel_uncore_read(_priv->uncore, CHICKEN_PAR1_1) |
> SKL_EDP_PSR_FIX_RDWRAP);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 19 Jan 2022 11:15:08 +0200
Andy Shevchenko wrote:
> > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
>
>
> Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others
> (enable/disable) it will not be possible to keep on one line. And hence
> style will be broken among similar functions.
Agreed. Functions should always be of the normal format:
type func(params)
{
body;
}
Unless it is a stub function.
type func(params) { return 0; }
-- Steve
Re: [Intel-gfx] [PATCH 0/3] lib/string_helpers: Add a few string helpers
On Wed, 19 Jan 2022, Petr Mladek wrote: > On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote: >> Add some helpers under lib/string_helpers.h so they can be used >> throughout the kernel. When I started doing this there were 2 other >> previous attempts I know of, not counting the iterations each of them >> had: >> >> 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/ >> 2) >> https://lore.kernel.org/all/20210215142137.64476-1-andriy.shevche...@linux.intel.com/#t >> >> Going through the comments I tried to find some common ground and >> justification for what is in here, addressing some of the concerns >> raised. >> >> d. This doesn't bring onoff() helper as there are some places in the >>kernel with onoff as variable - another name is probably needed for >>this function in order not to shadow the variable, or those variables >>could be renamed. Or if people wanting >>try to find a short one > > I would call it str_on_off(). > > And I would actually suggest to use the same style also for > the other helpers. > > The "str_" prefix would make it clear that it is something with > string. There are other _on_off() that affect some > functionality, e.g. mute_led_on_off(), e1000_vlan_filter_on_off(). > > The dash '_' would significantly help to parse the name. yesno() and > onoff() are nicely short and kind of acceptable. But "enabledisable()" > is a puzzle. > > IMHO, str_yes_no(), str_on_off(), str_enable_disable() are a good > compromise. > > The main motivation should be code readability. You write the > code once. But many people will read it many times. Open coding > is sometimes better than misleading macro names. > > That said, I do not want to block this patchset. If others like > it... ;-) I don't mind the names either way. Adding the prefix and dashes is helpful in that it's possible to add the functions first and convert users at leisure, though with a bunch of churn, while using names that collide with existing ones requires the changes to happen in one go. What I do mind is grinding this series to a halt once again. I sent a handful of versions of this three years ago, with inconclusive bikeshedding back and forth, eventually threw my hands up in disgust, and walked away. > > >> e. One alternative to all of this suggested by Christian König >>(43456ba7-c372-84cc-4949-dcb817188...@amd.com) would be to add a >>printk format. But besides the comment, he also seemed to like >>the common function. This brought the argument from others that the >>simple yesno()/enabledisable() already used in the code is easier to >>remember and use than e.g. %py[DOY] > > Thanks for not going this way :-) > >> Last patch also has some additional conversion of open coded cases. I >> preferred starting with drm/ since this is "closer to home". >> >> I hope this is a good summary of the previous attempts and a way we can >> move forward. >> >> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my >> proposal is to take first 2 patches either through mm tree or maybe >> vsprintf. Last patch can be taken later through drm. > > I agree with Andy that it should go via drm tree. It would make it > easier to handle potential conflicts. > > Just in case, you decide to go with str_yes_no() or something similar. > Mass changes are typically done at the end on the merge window. > The best solution is when it can be done by a script. > > Best Regards, > Petr -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Nuke dg2_ddi_pre_enable_dp()
== Series Details == Series: drm/i915: Nuke dg2_ddi_pre_enable_dp() URL : https://patchwork.freedesktop.org/series/99041/ State : success == Summary == CI Bug Log - changes from CI_DRM_11104 -> Patchwork_22022 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/index.html Participating hosts (46 -> 41) -- Missing(5): shard-tglu fi-bsw-cyan fi-pnv-d510 bat-jsl-2 fi-bdw-samus Known issues Here are the changes found in Patchwork_22022 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_engines: - bat-dg1-6: [PASS][1] -> [INCOMPLETE][2] ([i915#4418]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/bat-dg1-6/igt@i915_selftest@live@gt_engines.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/bat-dg1-6/igt@i915_selftest@live@gt_engines.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#4269]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: [PASS][5] -> [FAIL][6] ([i915#4547]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/fi-skl-6600u/igt@kms_psr@primary_page_flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@runner@aborted: - bat-dg1-6: NOTRUN -> [FAIL][7] ([i915#4214] / [i915#4312]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/bat-dg1-6/igt@run...@aborted.html - fi-skl-6600u: NOTRUN -> [FAIL][8] ([i915#4312]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/fi-skl-6600u/igt@run...@aborted.html Possible fixes * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [DMESG-FAIL][9] ([i915#295]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-cfl-8109u: [DMESG-WARN][11] ([i915#295]) -> [PASS][12] +10 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11104/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#4214]: https://gitlab.freedesktop.org/drm/intel/issues/4214 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 Build changes - * Linux: CI_DRM_11104 -> Patchwork_22022 CI-20190529: 20190529 CI_DRM_11104: 78b8a3e2f4543ecf92fe5a59dbd0255503c97dcc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22022: 9cb5445f65a3da28d449ed175505f9db29940290 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9cb5445f65a3 drm/i915: Nuke dg2_ddi_pre_enable_dp() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22022/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Nuke dg2_ddi_pre_enable_dp()
== Series Details == Series: drm/i915: Nuke dg2_ddi_pre_enable_dp() URL : https://patchwork.freedesktop.org/series/99041/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9cb5445f65a3 drm/i915: Nuke dg2_ddi_pre_enable_dp() -:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #19: - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on DG2 total: 0 errors, 1 warnings, 0 checks, 135 lines checked
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dpll: make intel_shared_dpll_funcs internal to intel_dpll_mgr.c
== Series Details ==
Series: drm/i915/dpll: make intel_shared_dpll_funcs internal to intel_dpll_mgr.c
URL : https://patchwork.freedesktop.org/series/99034/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11094_full -> Patchwork_22021_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22021_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22021_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22021_full:
### IGT changes ###
Possible regressions
* igt@gem_softpin@noreloc-s3:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11094/shard-skl7/igt@gem_soft...@noreloc-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-skl10/igt@gem_soft...@noreloc-s3.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_persistence@smoketest:
- {shard-tglu}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11094/shard-tglu-1/igt@gem_ctx_persiste...@smoketest.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-tglu-7/igt@gem_ctx_persiste...@smoketest.html
* igt@i915_selftest@live@gt_pm:
- {shard-rkl}:[PASS][5] -> ([DMESG-FAIL][6], [PASS][7])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11094/shard-rkl-6/igt@i915_selftest@live@gt_pm.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-rkl-6/igt@i915_selftest@live@gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-rkl-4/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_22021_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][8] -> [SKIP][9] ([i915#4525]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11094/shard-iclb2/igt@gem_exec_balan...@parallel-out-fence.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-iclb6/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_capture@pi@vecs0:
- shard-skl: NOTRUN -> [INCOMPLETE][10] ([i915#4547])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-skl4/igt@gem_exec_capture@p...@vecs0.html
* igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([i915#3778])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11094/shard-iclb2/igt@gem_exec_endless@dispa...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-iclb4/igt@gem_exec_endless@dispa...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-skl: NOTRUN -> [FAIL][13] ([i915#2846])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-skl10/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-apl: NOTRUN -> [FAIL][14] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-apl4/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl: NOTRUN -> [FAIL][15] ([i915#2842]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11094/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_huc_copy@huc-copy:
- shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-kbl7/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +4
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22021/shard-skl5/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +1
similar issue
[20]:
[Intel-gfx] [PATCH] drm/i915: Nuke dg2_ddi_pre_enable_dp()
From: Ville Syrjälä
dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate
it.
The one thing that tgl_ddi_pre_enable_dp() is missing that we
need is intel_ddi_config_transcoder_dp2(). So we'll bring that
over.
tgl_ddi_pre_enable_dp() does also have a few things that
dg2_ddi_pre_enable_dp() didn't have:
- icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2
- intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on DG2
- intel_ddi_mso_configure() -> only matters for MSO panels
Another slight difference is that dg2_ddi_pre_enable_dp() was
missing a bigjoiner check around intel_dsc_enable(), which
tgl_ddi_pre_enable_dp() does have.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 117 +--
1 file changed, 4 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4e93eac926a5..2f20abc5122d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2289,116 +2289,6 @@ static void intel_ddi_mso_configure(const struct
intel_crtc_state *crtc_state)
OVERLAP_PIXELS_MASK, dss1);
}
-static void dg2_ddi_pre_enable_dp(struct intel_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
-{
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
- bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
-
- intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
-crtc_state->lane_count);
-
- /*
-* We only configure what the register value will be here. Actual
-* enabling happens during link training farther down.
-*/
- intel_ddi_init_dp_buf_reg(encoder, crtc_state);
-
- /*
-* 1. Enable Power Wells
-*
-* This was handled at the beginning of intel_atomic_commit_tail(),
-* before we called down into this function.
-*/
-
- /* 2. Enable Panel Power if PPS is required */
- intel_pps_on(intel_dp);
-
- /*
-* 3. Enable the port PLL.
-*/
- intel_ddi_enable_clock(encoder, crtc_state);
-
- /* 4. Enable IO power */
- if (!intel_tc_port_in_tbt_alt_mode(dig_port))
- dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
-
dig_port->ddi_io_power_domain);
-
- /*
-* 5. The rest of the below are substeps under the bspec's "Enable and
-* Train Display Port" step. Note that steps that are specific to
-* MST will be handled by intel_mst_pre_enable_dp() before/after it
-* calls into this function. Also intel_mst_pre_enable_dp() only calls
-* us when active_mst_links==0, so any steps designated for "single
-* stream or multi-stream master transcoder" can just be performed
-* unconditionally here.
-*/
-
- /*
-* 5.a Configure Transcoder Clock Select to direct the Port clock to the
-* Transcoder.
-*/
- intel_ddi_enable_pipe_clock(encoder, crtc_state);
-
- /* 5.b Configure transcoder for DP 2.0 128b/132b */
- intel_ddi_config_transcoder_dp2(encoder, crtc_state);
-
- /*
-* 5.c Configure TRANS_DDI_FUNC_CTL DDI Select, DDI Mode Select & MST
-* Transport Select
-*/
- intel_ddi_config_transcoder_func(encoder, crtc_state);
-
- /*
-* 5.d Configure & enable DP_TP_CTL with link training pattern 1
-* selected
-*
-* This will be handled by the intel_dp_start_link_train() farther
-* down this function.
-*/
-
- /* 5.e Configure voltage swing and related IO settings */
- encoder->set_signal_levels(encoder, crtc_state);
-
- if (!is_mst)
- intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
-
- intel_dp_configure_protocol_converter(intel_dp, crtc_state);
- intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
- /*
-* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
-* in the FEC_CONFIGURATION register to 1 before initiating link
-* training
-*/
- intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
- intel_dp_check_frl_training(intel_dp);
- intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
-
- /*
-* 5.h Follow DisplayPort specification training sequence (see notes for
-* failure handling)
-* 5.i If DisplayPort multi-stream - Set DP_TP_CTL link training
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Don't allocate extra ddb during async flip for DG2
On Tue, Jan 18, 2022 at 12:48:39PM +0200, Stanislav Lisovskiy wrote:
> In terms of async flip optimization we don't to allocate
> extra ddb space, so lets skip it.
>
> v2: - Extracted min ddb async flip check to separate function
> (Ville Syrjälä)
> - Used this function to prevent false positive WARN
> to be triggered(Ville Syrjälä)
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 34 ++---
> 1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5d350ddc447f..4922c9108f08 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5118,6 +5118,12 @@ static bool icl_need_wm1_wa(struct drm_i915_private
> *i915,
> (IS_DISPLAY_VER(i915, 12, 13) && plane_id == PLANE_CURSOR);
> }
>
> +static bool dg2_need_min_ddb(struct drm_i915_private *i915,
> + struct intel_crtc_state *crtc_state)
> +{
> + return IS_DG2(i915) && crtc_state->uapi.async_flip;
Why are we using IS_DG2 here vs. DISPLAY>=13 for the wm0 only decision?
> +}
> +
> static int
> skl_allocate_plane_ddb(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> @@ -5226,9 +5232,15 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
> break;
>
> rate = crtc_state->plane_data_rate[plane_id];
> - extra = min_t(u16, alloc_size,
> - DIV64_U64_ROUND_UP(alloc_size * rate,
> - total_data_rate));
> +
> + if (dg2_need_min_ddb(dev_priv, crtc_state)) {
> + extra = 0;
> + } else {
> + extra = min_t(u16, alloc_size,
> + DIV64_U64_ROUND_UP(alloc_size * rate,
> + total_data_rate));
> + }
Hmm. I wonder if we should just set rate=0 instead. That would
let the other planes pick up the now unused extra ddb space. Would
also avoid having to skip the WARN since we'd still allocate the
full ddb.
> +
> total[plane_id] = wm->wm[level].min_ddb_alloc + extra;
> alloc_size -= extra;
> total_data_rate -= rate;
> @@ -5237,14 +5249,22 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
> break;
>
> rate = crtc_state->uv_plane_data_rate[plane_id];
> - extra = min_t(u16, alloc_size,
> - DIV64_U64_ROUND_UP(alloc_size * rate,
> - total_data_rate));
> +
> + if (dg2_need_min_ddb(dev_priv, crtc_state)) {
> + extra = 0;
> + } else {
> + extra = min_t(u16, alloc_size,
> + DIV64_U64_ROUND_UP(alloc_size * rate,
> + total_data_rate));
> + }
> +
> uv_total[plane_id] = wm->uv_wm[level].min_ddb_alloc + extra;
> alloc_size -= extra;
> total_data_rate -= rate;
> }
> - drm_WARN_ON(_priv->drm, alloc_size != 0 || total_data_rate != 0);
> +
> + if (!dg2_need_min_ddb(dev_priv, crtc_state))
> + drm_WARN_ON(_priv->drm, alloc_size != 0 || total_data_rate
> != 0);
>
> /* Set the actual DDB start/end points for each plane */
> start = alloc->start;
> --
> 2.24.1.485.gad05a3d8e5
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2
On Tue, Jan 18, 2022 at 12:48:38PM +0200, Stanislav Lisovskiy wrote:
> This optimization allows to achieve higher perfomance
> during async flips.
> For the first async flip we have to still temporarily
> switch to sync flip, in order to reprogram plane
> watermarks, so this requires taking into account
> old plane state's do_async_flip flag.
>
> v2: - Removed redundant new_plane_state->do_async_flip
> check from needs_async_flip_wm_override condition
> (Ville Syrjälä)
> - Extract dg2_async_flip_optimization to separate
> function(Ville Syrjälä)
> - Check for plane->async_flip instead of plane_id
> (Ville Syrjälä)
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
> drivers/gpu/drm/i915/intel_pm.c | 12 +++-
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f3ce29c42bc3..9a5126310014 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4908,6 +4908,15 @@ static bool needs_scaling(const struct
> intel_plane_state *state)
> return (src_w != dst_w || src_h != dst_h);
> }
>
> +static bool needs_async_flip_wm_override(struct intel_plane *plane,
> + const struct intel_plane_state
> *new_plane_state,
> + const struct intel_plane_state
> *old_plane_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
I'd probably put all the require logic into this one function.
Perhaps somehting like?
intel_plane_do_async_flip()
{
if (!plane->async_flip)
return false;
if (!new_crtc_state->uapi.async_flip)
return false;
/* some explanation what's going on here */
return DISPLAY_VER < 13 || old_crtc_state->uapi.async_flip;
}
>+
> + return DISPLAY_VER(dev_priv) >= 13 && !old_plane_state->do_async_flip;
> +}
> +
> int intel_plane_atomic_calc_changes(const struct intel_crtc_state
> *old_crtc_state,
> struct intel_crtc_state *new_crtc_state,
> const struct intel_plane_state
> *old_plane_state,
> @@ -5027,7 +5036,8 @@ int intel_plane_atomic_calc_changes(const struct
> intel_crtc_state *old_crtc_stat
>needs_scaling(new_plane_state
> new_crtc_state->disable_lp_wm = true;
>
> - if (new_crtc_state->uapi.async_flip && plane->async_flip)
> + if (new_crtc_state->uapi.async_flip &&
> + !needs_async_flip_wm_override(plane, new_plane_state,
> old_plane_state))
> new_plane_state->do_async_flip = true;
> else
> new_plane_state->do_async_flip = false;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index dc1203d21c46..5d350ddc447f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5510,6 +5510,15 @@ static int skl_wm_max_lines(struct drm_i915_private
> *dev_priv)
> return 31;
> }
>
> +bool dg2_async_flip_optimization(struct drm_i915_private *i915,
> + const struct intel_crtc_state *crtc_state,
> + const struct intel_plane *plane)
I'd drop the platform specific suffix from this since it's more of
a policy quesion rather than really a platform specific question.
We may or may not want to extend this to other platforms too if we
figure out that it can actually help (although my initial quick
tests did show a potentially negative impact for some unknown reason).
In fact maybe it should be just called use_minimal_wm0_only()
or something since the callers don't really need to know why it's
being done, only that we want to limit to just wm0 with minimal ddb
allocation?
> +{
> + return DISPLAY_VER(i915) >= 13 &&
> +crtc_state->uapi.async_flip &&
> +plane->async_flip;
> +}
> +
> static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
>const struct intel_plane *plane,
>int level,
> @@ -5523,7 +5532,8 @@ static void skl_compute_plane_wm(const struct
> intel_crtc_state *crtc_state,
> uint_fixed_16_16_t selected_result;
> u32 blocks, lines, min_ddb_alloc = 0;
>
> - if (latency == 0) {
> + if (latency == 0 ||
> + (dg2_async_flip_optimization(dev_priv, crtc_state, plane) && level
> > 0)) {
> /* reject it */
> result->min_ddb_alloc = U16_MAX;
> return;
> --
> 2.24.1.485.gad05a3d8e5
--
Ville Syrjälä
Intel
