[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates
== Series Details == Series: i915: SSEU handling updates URL : https://patchwork.freedesktop.org/series/104244/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11682 -> Patchwork_104244v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104244v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104244v1, 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_104244v1/index.html Participating hosts (44 -> 46) -- Additional (2): bat-dg2-9 fi-tgl-u2 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104244v1: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - fi-glk-dsi: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-glk-dsi/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-glk-dsi/igt@debugfs_test@read_all_entries.html - fi-kbl-guc: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-kbl-guc/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-kbl-guc/igt@debugfs_test@read_all_entries.html - fi-bdw-gvtdvm: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-bdw-gvtdvm/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-bdw-gvtdvm/igt@debugfs_test@read_all_entries.html - fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-bsw-kefka/igt@debugfs_test@read_all_entries.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-bsw-kefka/igt@debugfs_test@read_all_entries.html - fi-bdw-5557u: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-bdw-5557u/igt@debugfs_test@read_all_entries.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-bdw-5557u/igt@debugfs_test@read_all_entries.html - fi-rkl-11600: [PASS][11] -> [DMESG-WARN][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-rkl-11600/igt@debugfs_test@read_all_entries.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-rkl-11600/igt@debugfs_test@read_all_entries.html - fi-skl-guc: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-skl-guc/igt@debugfs_test@read_all_entries.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-skl-guc/igt@debugfs_test@read_all_entries.html - fi-kbl-7567u: [PASS][15] -> [DMESG-WARN][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html - fi-glk-j4005: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-glk-j4005/igt@debugfs_test@read_all_entries.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-glk-j4005/igt@debugfs_test@read_all_entries.html - fi-kbl-8809g: [PASS][19] -> [DMESG-WARN][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html - fi-bsw-nick:[PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-bsw-nick/igt@debugfs_test@read_all_entries.html - fi-tgl-1115g4: [PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-tgl-1115g4/igt@debugfs_test@read_all_entries.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-tgl-1115g4/igt@debugfs_test@read_all_entries.html - fi-cfl-8109u: [PASS][25] -> [DMESG-WARN][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v1/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html - fi-skl-6600u: [PASS][27] -> [DMESG-WARN][28] [27]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: SSEU handling updates
== Series Details == Series: i915: SSEU handling updates URL : https://patchwork.freedesktop.org/series/104244/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates
== Series Details ==
Series: i915: SSEU handling updates
URL : https://patchwork.freedesktop.org/series/104244/
State : warning
== Summary ==
Error: dim checkpatch failed
715c882f826e drm/i915/xehp: Use separate sseu init function
194ba3678abd drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
c1bbe76c5724 drm/i915/sseu: Simplify gen11+ SSEU handling
cb927114d301 drm/i915/sseu: Don't try to store EU mask internally in UAPI format
a0263df1c5fd drm/i915/sseu: Disassociate internal subslice mask representation
from uapi
-:514: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#514: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:846:
+void intel_sseu_print_ss_info(const char* type,
-:602: WARNING:NEW_TYPEDEFS: do not add new typedefs
#602: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:59:
+typedef union {
-:710: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#710: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:176:
+void intel_sseu_print_ss_info(const char* type,
total: 2 errors, 1 warnings, 0 checks, 837 lines checked
2e230636389f drm/i915/pvc: Add SSEU changes
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Enable DC5
On Fri, May 20, 2022 at 05:11:22PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dg2: Enable DC5
> URL : https://patchwork.freedesktop.org/series/104233/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11681 -> Patchwork_104233v1
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_104233v1 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_104233v1, 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_104233v1/index.html
>
> Participating hosts (46 -> 44)
> --
>
> Missing(2): bat-dg2-8 fi-rkl-11600
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_104233v1:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@fbdev@read:
> - fi-icl-u2: [PASS][1] -> [DMESG-WARN][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-icl-u2/igt@fb...@read.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-icl-u2/igt@fb...@read.html
It looks like this is an error coming from a bluetooth driver, not
related to graphics:
<3> [26.916574] Bluetooth: hci0: Reading Intel version command failed (-110)
<4> [26.916689] general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: [#1] PREEMPT SMP NOPTI
<4> [26.916726] CPU: 2 PID: 99 Comm: kworker/2:2 Not tainted
5.18.0-rc7-Patchwork_104233v1-gba369855d857+ #1
<4> [26.916731] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS
ICLSFWR1.R00.3183.A00.1905020411 05/02/2019
<4> [26.916737] Workqueue: events hci_cmd_timeout [bluetooth]
<4> [26.916755] RIP: 0010:hci_cmd_timeout+0x30/0xa0 [bluetooth]
<4> [26.916806] Code: ff ff 53 48 8b 87 10 05 00 00 48 89 fb 48 85 c0 74 63
48 8b 80 b8 00 00 00 48 8d b5 a0 00 00 00 48 85 ed 48 c7 c7 c8 6c 38 a0 <0f> b7
10 48 c7 c0 53 38 38 a0 48 0f 44 f0 e8 91 13 06 00 48 8b 83
<4> [26.916814] RSP: 0018:c9ae3e50 EFLAGS: 00010286
<4> [26.916818] RAX: 6b6b6b6b6b6b6b6b RBX: 88810ef5aac8 RCX:
<4> [26.916821] RDX: 0001 RSI: 88810ef5a0a0 RDI:
a0386cc8
<4> [26.916825] RBP: 88810ef5a000 R08: 88810700ba38 R09:
fffe
<4> [26.916828] R10: 0001 R11: dfbbfb17 R12:
88849fb3afc0
<4> [26.916832] R13: 88849fb3fc00 R14: R15:
88849fb3fc05
<4> [26.916835] FS: () GS:88849fb0()
knlGS:
<4> [26.916839] CS: 0010 DS: ES: CR0: 80050033
<4> [26.916842] CR2: 7fcc6837e1a0 CR3: 06612006 CR4:
00770ee0
<4> [26.916846] PKRU: 5554
<4> [26.916848] Call Trace:
<4> [26.916850]
<4> [26.916852] process_one_work+0x272/0x5c0
<4> [26.916857] worker_thread+0x37/0x370
<4> [26.916861] ? process_one_work+0x5c0/0x5c0
<4> [26.916864] kthread+0xed/0x120
<4> [26.916867] ? kthread_complete_and_exit+0x20/0x20
<4> [26.916870] ret_from_fork+0x1f/0x30
<4> [26.916875]
Looks like this might be
https://gitlab.freedesktop.org/drm/intel/-/issues/4890 ?
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@kms_busy@basic@modeset:
> - {bat-dg2-9}:[PASS][3] -> [DMESG-WARN][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg2-9/igt@kms_busy@ba...@modeset.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/bat-dg2-9/igt@kms_busy@ba...@modeset.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_104233v1 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@i915_selftest@live@hangcheck:
> - bat-dg1-5: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
> [i915#4957])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
> - bat-dg1-6: [PASS][7] -> [DMESG-FAIL][8] ([i915#4494] /
> [i915#4957])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
>
> * igt@i915_selftest@live@mman:
> - fi-bdw-5557u: [PASS][9] ->
[Intel-gfx] [PATCH v4 0/6] i915: SSEU handling updates
This series reworks i915's internal handling of slice/subslice/EU (SSEU)
data to represent platforms like Xe_HP in a more natural manner and to
prepare for future platforms where the masks will need to grow in size.
One key idea of this series is that although we have a fixed ABI to
convey SSEU data to userspace (i.e., multiple u8[] arrays with data
stored at different strides), we don't need to use this cumbersome
format for the driver's own internal storage. As long as we can convert
into the uapi form properly when responding to the I915_QUERY ioctl,
it's preferable to use an internal storage format that's easier for the
driver to work with.
Another key point here is that we're reaching the point where subslice
(DSS) masks will soon not fit within simple u32/u64 integer values.
Xe_HP SDV and DG2 platforms today have subslice (DSS) masks that are 32
bits, which maxes out the current storage of a u32. With PVC the masks
are represented by a pair of 32-bit registers, requiring a bump up to at
least 64-bits of storage internally. We could switch to u64 for that in
the short term, but since we already know that upcoming architectures
intend to provide DSS fuse bits via three or more registers it's best to
switch to a representation that's more future-proof but still easy to
work with in the driver code. To accomodate this, we start storing our
subslice mask for Xe_HP and beyond in a new typedef that can be
processed by the linux/bitmap.h operations.
Finally, since no userspace for Xe_HP or beyond is using the legacy
I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and
I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible
I915_QUERY ioctl that can return more than a simple u32 value), we take
the opportunity to officially drop support for those GETPARAM lookups on
modern platforms. Maintaining support for these GETPARAM lookups don't
make sense for a number of reasons:
* Traditional slices no longer exist, and newer ideas like gslices,
cslices, mslices, etc. aren't something userspace needs to query
since it can be inferred from other information.
* The GETPARAM ioctl doesn't have a way to distinguish between geometry
subslice masks and compute subslice masks, which are distinct on
Xe_HP and beyond.
* The I915_GETPARAM ioctl is limited to returning a 32-bit value, so
when subslice masks begin to exceed 32-bits (on PVC), it simply can't
return the entire mask.
* The GETPARAM ioctl doesn't have a way to give sensible information
for multi-tile devices.
v2:
- Switch to union of hsw/xehp formats to keep the representation in a
natural format for different types of hardware.
- Avoid accessing internals of intel_sseu_ss_mask_t directly outside of
intel_sseu.[ch].
- Include PVC SSEU which needs the larger SS mask storage enabled by
this series.
v3:
- Correct a BIT(s) typo that should have been BIT(ss), causing
incorrect handling on gen9 platforms.
v4:
- Eliminate sseu->{ss,eu}_stride fields and just calculate the proper
value in the UAPI code that needs them.
- Handle unwanted ~u8 sign extension at the callsite instead of inside
sseu_set_eus.
- Use BITMAP_BITS() macro rather than passing I915_MAX_SS_FUSE_BITS
around directly to bitmap operations.
- Improved debugfs / dmesg reporting for Xe_HP dumps
- Various assertion check improvements.
Cc: Tvrtko Ursulin
Matt Roper (6):
drm/i915/xehp: Use separate sseu init function
drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
drm/i915/sseu: Simplify gen11+ SSEU handling
drm/i915/sseu: Don't try to store EU mask internally in UAPI format
drm/i915/sseu: Disassociate internal subslice mask representation from
uapi
drm/i915/pvc: Add SSEU changes
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 450 ---
drivers/gpu/drm/i915/gt/intel_sseu.h | 94 ++--
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_getparam.c | 11 +-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 26 +-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
13 files changed, 398 insertions(+), 265 deletions(-)
--
2.35.3
[Intel-gfx] [PATCH v4 4/6] drm/i915/sseu: Don't try to store EU mask internally in UAPI format
Storing the EU mask internally in the same format the I915_QUERY
topology queries use makes the final copy_to_user() a bit simpler, but
makes the rest of the driver's SSEU more complicated and harder to
follow. Let's switch to an internal representation that's more natural:
Xe_HP platforms will be a simple array of u16 masks, whereas pre-Xe_HP
platforms will be a two-dimensional array, indexed by [slice][subslice].
We'll convert to the uapi format only when the query uapi is called.
v2:
- Drop has_common_ss_eumask. We waste some space repeating identical
EU masks for every single DSS, but the code is simpler without it.
(Tvrtko)
v3:
- Mask down EUs passed to sseu_set_eus at the callsite rather than
inside the function. (Tvrtko)
- Eliminate sseu->eu_stride and calculate it when needed. (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 88 ++--
drivers/gpu/drm/i915/gt/intel_sseu.h | 10 +++-
drivers/gpu/drm/i915/i915_query.c| 13 ++--
3 files changed, 73 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 7e5222ad2f98..285cfd758bdc 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -19,8 +19,6 @@ void intel_sseu_set_info(struct sseu_dev_info *sseu, u8
max_slices,
sseu->ss_stride = GEN_SSEU_STRIDE(sseu->max_subslices);
GEM_BUG_ON(sseu->ss_stride > GEN_MAX_SUBSLICE_STRIDE);
- sseu->eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
- GEM_BUG_ON(sseu->eu_stride > GEN_MAX_EU_STRIDE);
}
unsigned int
@@ -78,47 +76,77 @@ intel_sseu_subslices_per_slice(const struct sseu_dev_info
*sseu, u8 slice)
return hweight32(intel_sseu_get_subslices(sseu, slice));
}
-static int sseu_eu_idx(const struct sseu_dev_info *sseu, int slice,
- int subslice)
-{
- int slice_stride = sseu->max_subslices * sseu->eu_stride;
-
- return slice * slice_stride + subslice * sseu->eu_stride;
-}
-
static u16 sseu_get_eus(const struct sseu_dev_info *sseu, int slice,
int subslice)
{
- int i, offset = sseu_eu_idx(sseu, slice, subslice);
- u16 eu_mask = 0;
-
- for (i = 0; i < sseu->eu_stride; i++)
- eu_mask |=
- ((u16)sseu->eu_mask[offset + i]) << (i * BITS_PER_BYTE);
-
- return eu_mask;
+ if (sseu->has_xehp_dss) {
+ WARN_ON(slice > 0);
+ return sseu->eu_mask.xehp[subslice];
+ } else {
+ return sseu->eu_mask.hsw[slice][subslice];
+ }
}
static void sseu_set_eus(struct sseu_dev_info *sseu, int slice, int subslice,
u16 eu_mask)
{
- int i, offset = sseu_eu_idx(sseu, slice, subslice);
-
- for (i = 0; i < sseu->eu_stride; i++)
- sseu->eu_mask[offset + i] =
- (eu_mask >> (BITS_PER_BYTE * i)) & 0xff;
+ GEM_WARN_ON(eu_mask && __fls(eu_mask) >= sseu->max_eus_per_subslice);
+ if (sseu->has_xehp_dss) {
+ GEM_WARN_ON(slice > 0);
+ sseu->eu_mask.xehp[subslice] = eu_mask;
+ } else {
+ sseu->eu_mask.hsw[slice][subslice] = eu_mask;
+ }
}
static u16 compute_eu_total(const struct sseu_dev_info *sseu)
{
- u16 i, total = 0;
+ int s, ss, total = 0;
- for (i = 0; i < ARRAY_SIZE(sseu->eu_mask); i++)
- total += hweight8(sseu->eu_mask[i]);
+ for (s = 0; s < sseu->max_slices; s++)
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (sseu->has_xehp_dss)
+ total += hweight16(sseu->eu_mask.xehp[ss]);
+ else
+ total += hweight16(sseu->eu_mask.hsw[s][ss]);
return total;
}
+/**
+ * intel_sseu_copy_eumask_to_user - Copy EU mask into a userspace buffer
+ * @to: Pointer to userspace buffer to copy to
+ * @sseu: SSEU structure containing EU mask to copy
+ *
+ * Copies the EU mask to a userspace buffer in the format expected by
+ * the query ioctl's topology queries.
+ *
+ * Returns the result of the copy_to_user() operation.
+ */
+int intel_sseu_copy_eumask_to_user(void __user *to,
+ const struct sseu_dev_info *sseu)
+{
+ u8 eu_mask[GEN_SS_MASK_SIZE * GEN_MAX_EU_STRIDE] = {};
+ int eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
+ int len = sseu->max_slices * sseu->max_subslices * eu_stride;
+ int s, ss, i;
+
+ for (s = 0; s < sseu->max_slices; s++) {
+ for (ss = 0; ss < sseu->max_subslices; ss++) {
+ int uapi_offset =
+ s * sseu->max_subslices * eu_stride +
+ ss * eu_stride;
+ u16 mask = sseu_get_eus(sseu, s, ss);
+
+ for (i
[Intel-gfx] [PATCH v4 3/6] drm/i915/sseu: Simplify gen11+ SSEU handling
Although gen11 and gen12 architectures supported the concept of multiple
slices, in practice all the platforms that were actually designed only
had a single slice (i.e., note the parameters to 'intel_sseu_set_info'
that we pass for each platform). We can simplify the code slightly by
dropping the multi-slice logic from gen11+ platforms.
v2:
- Promote drm_dbg to drm_WARN_ON if the slice fuse register reports
unexpected fusing. (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 76 +---
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index b5fd479a7b85..7e5222ad2f98 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -119,52 +119,37 @@ static u16 compute_eu_total(const struct sseu_dev_info
*sseu)
return total;
}
-static u32 get_ss_stride_mask(struct sseu_dev_info *sseu, u8 s, u32 ss_en)
-{
- u32 ss_mask;
-
- ss_mask = ss_en >> (s * sseu->max_subslices);
- ss_mask &= GENMASK(sseu->max_subslices - 1, 0);
-
- return ss_mask;
-}
-
-static void gen11_compute_sseu_info(struct sseu_dev_info *sseu, u8 s_en,
+static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
u32 g_ss_en, u32 c_ss_en, u16 eu_en)
{
- int s, ss;
+ u32 valid_ss_mask = GENMASK(sseu->max_subslices - 1, 0);
+ int ss;
/* g_ss_en/c_ss_en represent entire subslice mask across all slices */
GEM_BUG_ON(sseu->max_slices * sseu->max_subslices >
sizeof(g_ss_en) * BITS_PER_BYTE);
- for (s = 0; s < sseu->max_slices; s++) {
- if ((s_en & BIT(s)) == 0)
- continue;
+ sseu->slice_mask |= BIT(0);
- sseu->slice_mask |= BIT(s);
-
- /*
-* XeHP introduces the concept of compute vs geometry DSS. To
-* reduce variation between GENs around subslice usage, store a
-* mask for both the geometry and compute enabled masks since
-* userspace will need to be able to query these masks
-* independently. Also compute a total enabled subslice count
-* for the purposes of selecting subslices to use in a
-* particular GEM context.
-*/
- intel_sseu_set_subslices(sseu, s, sseu->compute_subslice_mask,
-get_ss_stride_mask(sseu, s, c_ss_en));
- intel_sseu_set_subslices(sseu, s, sseu->geometry_subslice_mask,
-get_ss_stride_mask(sseu, s, g_ss_en));
- intel_sseu_set_subslices(sseu, s, sseu->subslice_mask,
-get_ss_stride_mask(sseu, s,
- g_ss_en | c_ss_en));
+ /*
+* XeHP introduces the concept of compute vs geometry DSS. To reduce
+* variation between GENs around subslice usage, store a mask for both
+* the geometry and compute enabled masks since userspace will need to
+* be able to query these masks independently. Also compute a total
+* enabled subslice count for the purposes of selecting subslices to
+* use in a particular GEM context.
+*/
+ intel_sseu_set_subslices(sseu, 0, sseu->compute_subslice_mask,
+c_ss_en & valid_ss_mask);
+ intel_sseu_set_subslices(sseu, 0, sseu->geometry_subslice_mask,
+g_ss_en & valid_ss_mask);
+ intel_sseu_set_subslices(sseu, 0, sseu->subslice_mask,
+(g_ss_en | c_ss_en) & valid_ss_mask);
+
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (intel_sseu_has_subslice(sseu, 0, ss))
+ sseu_set_eus(sseu, 0, ss, eu_en);
- for (ss = 0; ss < sseu->max_subslices; ss++)
- if (intel_sseu_has_subslice(sseu, s, ss))
- sseu_set_eus(sseu, s, ss, eu_en);
- }
sseu->eu_per_subslice = hweight16(eu_en);
sseu->eu_total = compute_eu_total(sseu);
}
@@ -196,7 +181,7 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
- gen11_compute_sseu_info(sseu, 0x1, g_dss_en, c_dss_en, eu_en);
+ gen11_compute_sseu_info(sseu, g_dss_en, c_dss_en, eu_en);
}
static void gen12_sseu_info_init(struct intel_gt *gt)
@@ -216,8 +201,13 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
*/
intel_sseu_set_info(sseu, 1, 6, 16);
+ /*
+* Although gen12 architecture supported multiple slices, TGL, RKL,
+* DG1, and ADL only had a single slice.
+*/
s_en =
[Intel-gfx] [PATCH v4 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose between the old "hsw-style" subslice masks or the newer xehp
mask. HSW-style masks will be stored in an array of u8's, indexed by
slice (there's never more than 6 subslices per slice on older
platforms). For Xe_HP and beyond where slices no longer exist, we only
need a single bitmask. However we already know that this mask is
eventually going to grow too large for a simple u64 to hold, so we'll
represent it in a manner that can be operated on by the utilities in
linux/bitmap.h.
v2:
- Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
v3:
- Eliminate sseu->ss_stride and just calculate the stride while
specifically handling uapi. (Tvrtko)
- Use BITMAP_BITS() macro to refer to size of masks rather than
passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko)
- Report compute/geometry DSS masks separately when dumping Xe_HP SSEU
info. (Tvrtko)
- Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 261 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 81 +++---
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_getparam.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 13 +-
9 files changed, 244 insertions(+), 189 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..a3bb73f5d53b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
{
const struct sseu_dev_info *device = >info.sseu;
struct drm_i915_private *i915 = gt->i915;
+ unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
0);
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
if (user->slice_mask & ~device->slice_mask)
return -EINVAL;
- if (user->subslice_mask & ~device->subslice_mask[0])
+ if (user->subslice_mask & ~dev_subslice_mask)
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
/* Part specific restrictions. */
if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
- unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
+ unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
unsigned int req_s = hweight8(context->slice_mask);
unsigned int req_ss = hweight8(context->subslice_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1adbf34c3632..f0acf8518a51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct intel_gt
*gt)
if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
return;
- ccs_mask =
intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
- ss_per_ccs);
+ ccs_mask =
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
+ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
* engine is not available for use.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 034182f85501..2921f510642f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -133,13 +133,6 @@ static const struct intel_mmio_range
dg2_lncf_steering_table[] = {
{},
};
-static u16 slicemask(struct intel_gt *gt, int count)
-{
- u64 dss_mask = intel_sseu_get_subslices(>info.sseu, 0);
-
- return intel_slicemask_from_dssmask(dss_mask, count);
-}
-
int intel_gt_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -155,9 +148,12 @@ int intel_gt_init_mmio(struct intel_gt *gt)
*/
if (HAS_MSLICES(i915)) {
gt->info.mslice_mask =
- slicemask(gt,
[Intel-gfx] [PATCH v4 1/6] drm/i915/xehp: Use separate sseu init function
Xe_HP has enough fundamental differences from previous platforms that it
makes sense to use a separate SSEU init function to keep things
straightforward and easy to understand. We'll also add a has_xehp_dss
flag to the SSEU structure that will be used by other upcoming changes.
v2:
- Add has_xehp_dss flag
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 86
drivers/gpu/drm/i915/gt/intel_sseu.h | 5 ++
2 files changed, 54 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index fdd25691beda..b5fd479a7b85 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -169,13 +169,43 @@ static void gen11_compute_sseu_info(struct sseu_dev_info
*sseu, u8 s_en,
sseu->eu_total = compute_eu_total(sseu);
}
-static void gen12_sseu_info_init(struct intel_gt *gt)
+static void xehp_sseu_info_init(struct intel_gt *gt)
{
struct sseu_dev_info *sseu = >info.sseu;
struct intel_uncore *uncore = gt->uncore;
u32 g_dss_en, c_dss_en = 0;
u16 eu_en = 0;
u8 eu_en_fuse;
+ int eu;
+
+ /*
+* The concept of slice has been removed in Xe_HP. To be compatible
+* with prior generations, assume a single slice across the entire
+* device. Then calculate out the DSS for each workload type within
+* that software slice.
+*/
+ intel_sseu_set_info(sseu, 1, 32, 16);
+ sseu->has_xehp_dss = 1;
+
+ g_dss_en = intel_uncore_read(uncore, GEN12_GT_GEOMETRY_DSS_ENABLE);
+ c_dss_en = intel_uncore_read(uncore, GEN12_GT_COMPUTE_DSS_ENABLE);
+
+ eu_en_fuse = intel_uncore_read(uncore, XEHP_EU_ENABLE) &
XEHP_EU_ENA_MASK;
+
+ for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
+ if (eu_en_fuse & BIT(eu))
+ eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
+
+ gen11_compute_sseu_info(sseu, 0x1, g_dss_en, c_dss_en, eu_en);
+}
+
+static void gen12_sseu_info_init(struct intel_gt *gt)
+{
+ struct sseu_dev_info *sseu = >info.sseu;
+ struct intel_uncore *uncore = gt->uncore;
+ u32 g_dss_en;
+ u16 eu_en = 0;
+ u8 eu_en_fuse;
u8 s_en;
int eu;
@@ -183,43 +213,23 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
* Gen12 has Dual-Subslices, which behave similarly to 2 gen11 SS.
* Instead of splitting these, provide userspace with an array
* of DSS to more closely represent the hardware resource.
-*
-* In addition, the concept of slice has been removed in Xe_HP.
-* To be compatible with prior generations, assume a single slice
-* across the entire device. Then calculate out the DSS for each
-* workload type within that software slice.
*/
- if (IS_DG2(gt->i915) || IS_XEHPSDV(gt->i915))
- intel_sseu_set_info(sseu, 1, 32, 16);
- else
- intel_sseu_set_info(sseu, 1, 6, 16);
+ intel_sseu_set_info(sseu, 1, 6, 16);
- /*
-* As mentioned above, Xe_HP does not have the concept of a slice.
-* Enable one for software backwards compatibility.
-*/
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
- s_en = 0x1;
- else
- s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
- GEN11_GT_S_ENA_MASK;
+ s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
+ GEN11_GT_S_ENA_MASK;
g_dss_en = intel_uncore_read(uncore, GEN12_GT_GEOMETRY_DSS_ENABLE);
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
- c_dss_en = intel_uncore_read(uncore,
GEN12_GT_COMPUTE_DSS_ENABLE);
/* one bit per pair of EUs */
- if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50))
- eu_en_fuse = intel_uncore_read(uncore, XEHP_EU_ENABLE) &
XEHP_EU_ENA_MASK;
- else
- eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
- GEN11_EU_DIS_MASK);
+ eu_en_fuse = ~(intel_uncore_read(uncore, GEN11_EU_DISABLE) &
+ GEN11_EU_DIS_MASK);
for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
- gen11_compute_sseu_info(sseu, s_en, g_dss_en, c_dss_en, eu_en);
+ gen11_compute_sseu_info(sseu, s_en, g_dss_en, 0, eu_en);
/* TGL only supports slice-level power gating */
sseu->has_slice_pg = 1;
@@ -574,18 +584,20 @@ void intel_sseu_info_init(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
- if (IS_HASWELL(i915))
- hsw_sseu_info_init(gt);
- else if (IS_CHERRYVIEW(i915))
- cherryview_sseu_info_init(gt);
- else if (IS_BROADWELL(i915))
-
[Intel-gfx] [PATCH v4 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support traditional slices (and we make no attempt to return the various new units like gslices, cslices, mslices, etc.) here. The subslice mask lookup is even more problematic; given the distinct masks for geometry vs compute purposes, the combined mask returned here is likely not what userspace would want to act upon anyway. The value is also limited to 32-bits by the nature of the GETPARAM ioctl which is sufficient for the initial Xe_HP platforms, but is unable to convey the larger masks that will be needed on other upcoming platforms. Finally, the value returned here becomes even less meaningful when used on multi-tile platforms where each tile will have its own masks. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_getparam.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index c12a0adefda5..ac9767c56619 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -148,11 +148,19 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = intel_engines_has_context_isolation(i915); break; case I915_PARAM_SLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + value = sseu->slice_mask; if (!value) return -ENODEV; break; case I915_PARAM_SUBSLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + /* Only copy bits from the first slice */ memcpy(, sseu->subslice_mask, min(sseu->ss_stride, (u8)sizeof(value))); -- 2.35.3
[Intel-gfx] [PATCH v4 6/6] drm/i915/pvc: Add SSEU changes
PVC splits the mask of enabled DSS over two registers. It also changes
the meaning of the EU fuse register such that each bit represents a
single EU rather than a pair of EUs.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 31 ++--
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
6 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7246eb870c7e..3f2b46c884f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -561,6 +561,7 @@
#define GEN11_GT_VEBOX_DISABLE_MASK (0x0f <<
GEN11_GT_VEBOX_DISABLE_SHIFT)
#define GEN12_GT_COMPUTE_DSS_ENABLE_MMIO(0x9144)
+#define XEHPC_GT_COMPUTE_DSS_ENABLE_EXT_MMIO(0x9148)
#define GEN6_UCGCTL1 _MMIO(0x9400)
#define GEN6_GAMUNIT_CLOCK_GATE_DISABLE (1 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 6fbc2ac507b7..82e6f324b2ef 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -212,27 +212,44 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
u16 eu_en = 0;
u8 eu_en_fuse;
+ int num_compute_regs, num_geometry_regs;
int eu;
+ if (IS_PONTEVECCHIO(gt->i915)) {
+ num_geometry_regs = 0;
+ num_compute_regs = 2;
+ } else {
+ num_geometry_regs = 1;
+ num_compute_regs = 1;
+ }
+
/*
* The concept of slice has been removed in Xe_HP. To be compatible
* with prior generations, assume a single slice across the entire
* device. Then calculate out the DSS for each workload type within
* that software slice.
*/
- intel_sseu_set_info(sseu, 1, 32, 16);
+ intel_sseu_set_info(sseu, 1,
+ 32 * max(num_geometry_regs, num_compute_regs),
+ 16);
sseu->has_xehp_dss = 1;
- xehp_load_dss_mask(uncore, >geometry_subslice_mask, 1,
+ xehp_load_dss_mask(uncore, >geometry_subslice_mask,
+ num_geometry_regs,
GEN12_GT_GEOMETRY_DSS_ENABLE);
- xehp_load_dss_mask(uncore, >compute_subslice_mask, 1,
- GEN12_GT_COMPUTE_DSS_ENABLE);
+ xehp_load_dss_mask(uncore, >compute_subslice_mask,
+ num_compute_regs,
+ GEN12_GT_COMPUTE_DSS_ENABLE,
+ XEHPC_GT_COMPUTE_DSS_ENABLE_EXT);
eu_en_fuse = intel_uncore_read(uncore, XEHP_EU_ENABLE) &
XEHP_EU_ENA_MASK;
- for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
- if (eu_en_fuse & BIT(eu))
- eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
+ if (HAS_ONE_EU_PER_FUSE_BIT(gt->i915))
+ eu_en = eu_en_fuse;
+ else
+ for (eu = 0; eu < sseu->max_eus_per_subslice / 2; eu++)
+ if (eu_en_fuse & BIT(eu))
+ eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
xehp_compute_sseu_info(sseu, eu_en);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 0d3def55e770..79732c1af6c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -33,7 +33,7 @@ struct drm_printer;
* Maximum number of 32-bit registers used by hardware to express the
* enabled/disabled subslices.
*/
-#define I915_MAX_SS_FUSE_REGS 1
+#define I915_MAX_SS_FUSE_REGS 2
#define I915_MAX_SS_FUSE_BITS (I915_MAX_SS_FUSE_REGS * 32)
/* Maximum number of EUs that can exist within a subslice or DSS. */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c5fc402d9c50..1f8422e9511b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1405,6 +1405,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
+#define HAS_ONE_EU_PER_FUSE_BIT(i915)
(INTEL_INFO(i915)->has_one_eu_per_fuse_bit)
+
/* i915_gem.c */
void i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5ad9884874c2..9cee3c69edde 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1079,7 +1079,8 @@ static const struct intel_device_info ats_m_info = {
#define XE_HPC_FEATURES \
XE_HP_FEATURES, \
.dma_mask_size =
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
On Fri, May 20, 2022 at 10:15:32AM +0100, Tvrtko Ursulin wrote: > > On 17/05/2022 04:20, Matt Roper wrote: > > Slice/subslice/EU information should be obtained via the topology > > queries provided by the I915_QUERY interface; let's turn off support for > > the old GETPARAM lookups on Xe_HP and beyond where we can't return > > meaningful values. > > > > The slice mask lookup is meaningless since Xe_HP doesn't support > > traditional slices (and we make no attempt to return the various new > > units like gslices, cslices, mslices, etc.) here. > > > > The subslice mask lookup is even more problematic; given the distinct > > masks for geometry vs compute purposes, the combined mask returned here > > is likely not what userspace would want to act upon anyway. The value > > is also limited to 32-bits by the nature of the GETPARAM ioctl which is > > sufficient for the initial Xe_HP platforms, but is unable to convey the > > larger masks that will be needed on other upcoming platforms. Finally, > > the value returned here becomes even less meaningful when used on > > multi-tile platforms where each tile will have its own masks. > > > > Signed-off-by: Matt Roper > > --- > > drivers/gpu/drm/i915/i915_getparam.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_getparam.c > > b/drivers/gpu/drm/i915/i915_getparam.c > > index c12a0adefda5..ac9767c56619 100644 > > --- a/drivers/gpu/drm/i915/i915_getparam.c > > +++ b/drivers/gpu/drm/i915/i915_getparam.c > > @@ -148,11 +148,19 @@ int i915_getparam_ioctl(struct drm_device *dev, void > > *data, > > value = intel_engines_has_context_isolation(i915); > > break; > > case I915_PARAM_SLICE_MASK: > > + /* Not supported from Xe_HP onward; use topology queries */ > > + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) > > + return -EINVAL; > > + > > value = sseu->slice_mask; > > if (!value) > > return -ENODEV; > > break; > > case I915_PARAM_SUBSLICE_MASK: > > + /* Not supported from Xe_HP onward; use topology queries */ > > + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) > > + return -EINVAL; > > + > > /* Only copy bits from the first slice */ > > memcpy(, sseu->subslice_mask, > >min(sseu->ss_stride, (u8)sizeof(value))); > > Just in case lets run this by Jordan and Lionel since it affects DG2. Anyone > else on the userspace side who might be affected? When I grep'd Mesa, I found two uses of I915_PARAM_SLICE_MASK and I915_PARAM_SUBSLICE_MASK: * oa_metrics_kernel_support: The topology query is used on gen10+ so the getparam code is only called on gen9 and below * getparam_topology: Invoked via intel_get_device_info_from_fd(). The topology query is attempted first. Only if that fails _and_ we're on a pre-gen10 platform does it fall back to GETPARAM. I also checked https://github.com/intel/compute-runtime and only see these being issued in one place: * HwInfoConfig::configureHwInfoDrm: Only used if drm->queryTopology() returns a failure first. I think those are the only relevant userspace for SSEU topology, so as far as I can tell nobody is still relying on the legacy getparams by the time we get to Xe_HP hardware. Matt > > Regards, > > Tvrtko -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Support 4k@30 on HDMI
On Wed, May 11, 2022 at 02:01:21PM +0530, Ankit Nautiyal wrote:
> From: Vandita Kulkarni
>
> This patch adds a fix to support 297MHz of dot clock by calculating
> the pll values using synopsis algorithm.
> This will help to support 4k@30 mode for HDMI monitors on DG2.
>
> Signed-off-by: Vandita Kulkarni
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index 0dd4775e8195..ec1700dd3bc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -517,6 +517,36 @@ static const struct intel_mpllb_state dg2_hdmi_148_5 = {
> REG_FIELD_PREP(SNPS_PHY_MPLLB_SSC_UP_SPREAD, 1),
> };
>
> +/* values in the below table are calculted using the algo */
> +static const struct intel_mpllb_state dg2_hdmi_297 = {
> + .clock = 297000,
> + .ref_control =
> + REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 3),
> + .mpllb_cp =
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 6) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 14) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 64) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 124),
> + .mpllb_div =
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 1) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2),
When I calculate these tables out by hand, I also have
REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3)
as part of mpllb_div. Can you double check that?
Matt
> + .mpllb_div2 =
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 86) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_HDMI_DIV, 1),
> + .mpllb_fracn1 =
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 65535),
> + .mpllb_fracn2 =
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 26214) |
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_REM, 26214),
> + .mpllb_sscen =
> + REG_FIELD_PREP(SNPS_PHY_MPLLB_SSC_UP_SPREAD, 1),
> +};
> +
> static const struct intel_mpllb_state dg2_hdmi_594 = {
> .clock = 594000,
> .ref_control =
> @@ -551,6 +581,7 @@ static const struct intel_mpllb_state * const
> dg2_hdmi_tables[] = {
> _hdmi_27_0,
> _hdmi_74_25,
> _hdmi_148_5,
> + _hdmi_297,
> _hdmi_594,
> NULL,
> };
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Enable DC5
== Series Details ==
Series: drm/i915/dg2: Enable DC5
URL : https://patchwork.freedesktop.org/series/104233/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11681 -> Patchwork_104233v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104233v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104233v1, 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_104233v1/index.html
Participating hosts (46 -> 44)
--
Missing(2): bat-dg2-8 fi-rkl-11600
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104233v1:
### IGT changes ###
Possible regressions
* igt@fbdev@read:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-icl-u2/igt@fb...@read.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-icl-u2/igt@fb...@read.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_busy@basic@modeset:
- {bat-dg2-9}:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg2-9/igt@kms_busy@ba...@modeset.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/bat-dg2-9/igt@kms_busy@ba...@modeset.html
Known issues
Here are the changes found in Patchwork_104233v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [PASS][7] -> [DMESG-FAIL][8] ([i915#4494] /
[i915#4957])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@mman:
- fi-bdw-5557u: [PASS][9] -> [INCOMPLETE][10] ([i915#5704])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@vma:
- fi-bdw-5557u: [PASS][13] -> [INCOMPLETE][14] ([i915#5681])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-bdw-5557u/igt@i915_selftest@l...@vma.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-bdw-5557u/igt@i915_selftest@l...@vma.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2: [PASS][15] -> [DMESG-WARN][16] ([i915#402]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@runner@aborted:
- fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#3690])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-icl-u2/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#2403] /
[i915#4312])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][19] ([i915#5122]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-1115g4: [DMESG-FAIL][21] ([i915#5334]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-tgl-1115g4/igt@i915_selftest@live@gt_heartbeat.html
[22]:
Re: [Intel-gfx] [PATCH] drm/i915/dsi: fix VBT send packet port selection for ICL+
On Fri, May 20, 2022 at 12:46:00PM +0300, Jani Nikula wrote:
> The VBT send packet port selection was never updated for ICL+ where the
> 2nd link is on port B instead of port C as in VLV+ DSI.
>
> First, single link DSI needs to use the configured port instead of
> relying on the VBT sequence block port. Remove the hard-coded port C
> check here and make it generic. For reference, see commit f915084edc5a
> ("drm/i915: Changes related to the sequence port no for") for the
> original VLV specific fix.
>
> Second, the sequence block port number is either 0 or 1, where 1
> indicates the 2nd link. Remove the hard-coded port C here for 2nd
> link. (This could be a "find second set bit" on DSI ports, but just
> check the two possible options.)
>
> Third, sanity check the result with a warning to avoid a NULL pointer
> dereference.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5984
> Cc: sta...@vger.kernel.org # v4.19+
> Cc: Ville Syrjala
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 33 +---
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index f370e9c4350d..dd24aef925f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -125,9 +125,25 @@ struct i2c_adapter_lookup {
> #define ICL_GPIO_DDPA_CTRLCLK_2 8
> #define ICL_GPIO_DDPA_CTRLDATA_29
>
> -static enum port intel_dsi_seq_port_to_port(u8 port)
> +static enum port intel_dsi_seq_port_to_port(struct intel_dsi *intel_dsi,
> + u8 seq_port)
> {
> - return port ? PORT_C : PORT_A;
> + /*
> + * If single link DSI is being used on any port, the VBT sequence block
> + * send packet apparently always has 0 for the port. Just use the port
> + * we have configured, and ignore the sequence block port.
> + */
> + if (hweight8(intel_dsi->ports) == 1)
> + return ffs(intel_dsi->ports) - 1;
> +
> + if (seq_port) {
> + if (intel_dsi->ports & PORT_B)
> + return PORT_B;
> + else if (intel_dsi->ports & PORT_C)
> + return PORT_C;
> + }
> +
> + return PORT_A;
Hmm. I guess a bit more generic way to express that could be
to just pick the Nth set bit from intel_dsi->ports, where N==seq_port.
Assuming seq_port is just an index. But I guess we're not really
expecting to grow more DSI ports any time soon, so this seems
sufficient for the current situation.
Reviewed-by: Ville Syrjälä
> }
>
> static const u8 *mipi_exec_send_packet(struct intel_dsi *intel_dsi,
> @@ -149,15 +165,10 @@ static const u8 *mipi_exec_send_packet(struct intel_dsi
> *intel_dsi,
>
> seq_port = (flags >> MIPI_PORT_SHIFT) & 3;
>
> - /* For DSI single link on Port A & C, the seq_port value which is
> - * parsed from Sequence Block#53 of VBT has been set to 0
> - * Now, read/write of packets for the DSI single link on Port A and
> - * Port C will based on the DVO port from VBT block 2.
> - */
> - if (intel_dsi->ports == (1 << PORT_C))
> - port = PORT_C;
> - else
> - port = intel_dsi_seq_port_to_port(seq_port);
> + port = intel_dsi_seq_port_to_port(intel_dsi, seq_port);
> +
> + if (drm_WARN_ON(_priv->drm, !intel_dsi->dsi_hosts[port]))
> + goto out;
>
> dsi_device = intel_dsi->dsi_hosts[port]->device;
> if (!dsi_device) {
> --
> 2.30.2
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH] drm/i915/dg2: Enable DC5
Enable DC5 on dg2. Cc: Imre Deak Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index fb17439bd4f8..f58e277fdadf 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -908,7 +908,7 @@ static u32 get_allowed_dc_mask(const struct drm_i915_private *dev_priv, return 0; if (IS_DG2(dev_priv)) - max_dc = 0; + max_dc = 1; else if (IS_DG1(dev_priv)) max_dc = 3; else if (DISPLAY_VER(dev_priv) >= 12) -- 2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: fix VBT send packet port selection for ICL+
== Series Details == Series: drm/i915/dsi: fix VBT send packet port selection for ICL+ URL : https://patchwork.freedesktop.org/series/104220/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11681_full -> Patchwork_104220v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104220v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104220v1_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 -> 11) -- Missing(2): shard-rkl shard-dg1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104220v1_full: ### IGT changes ### Possible regressions * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-kbl6/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-kbl6/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html Known issues Here are the changes found in Patchwork_104220v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [FAIL][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk8/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/shard-glk7/boot.html [35]:
Re: [Intel-gfx] [RFC PATCH] drm/i915: Debugfs statistics interface for psr
Hello Jose, Thank you for your comments, see my response below. On Thu, 2022-05-19 at 13:47 +, Souza, Jose wrote: > On Thu, 2022-05-19 at 12:17 +, Hogander, Jouni wrote: > > On Wed, 2022-05-18 at 20:00 +, Souza, Jose wrote: > > > On Wed, 2022-05-18 at 10:45 +0300, Jouni Högander wrote: > > > > Currently there is no mean to get understanding how psr is > > > > utilized. > > > > E.g. How much psr is actually enabled or how often driver falls > > > > back > > > > to full update. > > > > > > But with this information what can you do? > > > > If you are doing pnp analysis for use cases with PSR2 capable > > panel. > > Having such information telling you how PSR is utilized is valuable > > to > > make your statement if there is room for optimization. > > > > or > > > > you are doing power measurement follow-up and facing regression in > > certain use case. You can check possible changes in PSR utilization > > and make your statement if it's involved or not. E.g. recent > > changes to > > fall back to full update if area calculation fails or the one where > > using continuous full update instead of psr disable would have been > > visible in these statistics. > > The goal is to get rid of all full frame update cases, knowing that > it have 10% of full updates do not adds anything. I was thinking it could help us to determine where to invest our time. Possibly also estimate impact of changes we are planning to take in the future. > About PNP this information is not helpful, most of the power saved > with PSR is when display is idle and it goes to DC5/DC6 states that > can be measured > in i915_dmc_info and by pkg10 residency from the SOC. Yes, this is true. PSR is not the only factor affecting DC5/DC6 usage, right? I.e. when you see a change in DC5/DC6 recidencies: we have currently nothing available to determine if it's due to PSR or something else. Of course this can be debugged, but having proper information on PSR utilization could give us some trace. As an example I have taken snapshot of stats over psr_stress_test written by you. Comparison is for recent patches into psr code (cff + sff on calc failure): Without recent patches: PSR disabled vblank count : 48 Total vblank count : 371 Selective update count : 152 Full update count : 148 With those WA:s PSR disabled vblank count : 7 Total vblank count : 326 Selective update count : 152 Full update count : 63 "PSR disabled vblank count" drop is quite obvious due to changes in those patches. "Full update count" was a bit surprice at least to me. > > Other thing is this only covers Tigerlake and Alderlake-P, I guess it > would only print the number of vblanks for older platforms. Interface is targeted to tell how many vblank periods there were with PSR disabled on devices with PSR1/without selective fetch. > > Addition to these I have been thinking extending this to gather > > statistics or history over used update area as well. Considering > > recent > > bugs we have fixed in psr code: As a first step you need to start > > instrumenting psr code and ask reporter to take trace with your > > instrumentation. Instead we could have some statistic or even last > > SU > > areas when CRC error is triggered and make these available in logs > > or > > via some debugfs interface. > > > > I'm pretty sure we will revisit psr code in the future and > > introduce > > new bugs and new workarounds among new features. I'm trying to > > figure > > out something to ease up analyzing their impact and maybe even > > rootcausing bugs. > > If you have something that proved to be useful in a few bugs I would > consider this. > But merge a bunch of code to returns information that will not be > useful is not good and would bring more maintenance burden in future. > If you check the psr debugfs we already have some of it that was not > much useful. This valid point/requirement. I can keep this patch on my own and maybe add that SU area trace into it. > > > > I don't see much value on it. > > > We have now some cases that leads to full update, that needs to > > > be > > > properly fixed so it can always do partial updates. > > > > There are still these cases, but also frontbuffer invalidate/flush > > callbacks are there. e.g. currently there is no way to say how > > often we > > are doing full update. Before the "continuous full update" we > > didn't > > know how much psr is actually disabled due to invalidate/flush. > > > > > Did not checked the implementation details. > > > > > > > This patch addresses this by adding new debugfs interface > > > > i915_edp_psr_stats. Statistics gathering is started by writing > > > > 1/y/Y and > > > > stopped by writing 0/n/N into this new interface. > > > > > > > > Following fields are provided for reading by this new > > > > interface: > > > > > > > > "PSR disabled vblank count" > > > > > > > > Over how many vblank periods PSR was disabled after statistics > > > > gathering got started. I.e. How many normal
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: fix VBT send packet port selection for ICL+
== Series Details ==
Series: drm/i915/dsi: fix VBT send packet port selection for ICL+
URL : https://patchwork.freedesktop.org/series/104220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11681 -> Patchwork_104220v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/index.html
Participating hosts (46 -> 47)
--
Additional (1): bat-adlm-1
Known issues
Here are the changes found in Patchwork_104220v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([i915#4890])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-icl-u2/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-icl-u2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u: [PASS][3] -> [INCOMPLETE][4] ([i915#5502] /
[i915#5801])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5: [PASS][7] -> [DMESG-FAIL][8] ([i915#4494] /
[i915#4957])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][9] -> [DMESG-FAIL][10] ([i915#4528])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#402])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#2403] /
[i915#4312])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][14] ([i915#5122]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@dmabuf:
- {bat-dg2-9}:[DMESG-WARN][16] ([i915#5763]) -> [PASS][17] +5
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-dg2-9/igt@i915_selftest@l...@dmabuf.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/bat-dg2-9/igt@i915_selftest@l...@dmabuf.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-1115g4: [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-tgl-1115g4/igt@i915_selftest@live@gt_heartbeat.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-tgl-1115g4/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_busy@basic@modeset:
- {bat-adlp-6}: [DMESG-WARN][20] ([i915#3576]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/bat-adlp-6/igt@kms_busy@ba...@modeset.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/bat-adlp-6/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-u2: [DMESG-WARN][22] ([i915#402]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-tgl-u2/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104220v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]:
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Add smem fallback allocation for dpt
On Fri, 20 May 2022 at 12:23, Juha-Pekka Heikkilä
wrote:
>
>
>
> Matthew Auld kirjoitti 11.5.2022 klo 13.41:
> > On Fri, 6 May 2022 at 14:11, Juha-Pekka Heikkila
> > wrote:
> >>
> >> Add fallback smem allocation for dpt if stolen memory allocation failed.
> >>
> >> Signed-off-by: Juha-Pekka Heikkila
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dpt.c | 16
> >> 1 file changed, 12 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >> index fb0e7e79e0cd..10008699656e 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >> @@ -10,6 +10,7 @@
> >> #include "intel_display_types.h"
> >> #include "intel_dpt.h"
> >> #include "intel_fb.h"
> >> +#include "gem/i915_gem_internal.h"
> >
> > Nit: Keep these ordered.
> >
> >>
> >> struct i915_dpt {
> >> struct i915_address_space vm;
> >> @@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct
> >> i915_address_space *vm)
> >> void __iomem *iomem;
> >> struct i915_gem_ww_ctx ww;
> >> int err;
> >> + u64 pin_flags = 0;
> >
> > Nit: Christmas tree-ish. Move this above the err.
> >
> >> +
> >> + if (!i915_gem_object_is_lmem(dpt->obj))
> >> + pin_flags |= PIN_MAPPABLE;
> >
> > If we do this then we don't need the second patch ;)
> >
> > I guess the second patch was meant to make this is_stolen? Maybe just
> > move the second patch to be the first in the series?
> >
>
> Hi Matthew, thanks for the comments. I think I'm still missing some
> essential part. Without marking PIN_MAPPABLE when !lmem I was hitting
> WARN_ON() in gem code when doing this pinning.
What was the WARN_ON? Got a paste?
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Add smem fallback allocation for dpt
Matthew Auld kirjoitti 11.5.2022 klo 13.41:
On Fri, 6 May 2022 at 14:11, Juha-Pekka Heikkila
wrote:
Add fallback smem allocation for dpt if stolen memory allocation failed.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_dpt.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index fb0e7e79e0cd..10008699656e 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -10,6 +10,7 @@
#include "intel_display_types.h"
#include "intel_dpt.h"
#include "intel_fb.h"
+#include "gem/i915_gem_internal.h"
Nit: Keep these ordered.
struct i915_dpt {
struct i915_address_space vm;
@@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space
*vm)
void __iomem *iomem;
struct i915_gem_ww_ctx ww;
int err;
+ u64 pin_flags = 0;
Nit: Christmas tree-ish. Move this above the err.
+
+ if (!i915_gem_object_is_lmem(dpt->obj))
+ pin_flags |= PIN_MAPPABLE;
If we do this then we don't need the second patch ;)
I guess the second patch was meant to make this is_stolen? Maybe just
move the second patch to be the first in the series?
Hi Matthew, thanks for the comments. I think I'm still missing some
essential part. Without marking PIN_MAPPABLE when !lmem I was hitting
WARN_ON() in gem code when doing this pinning. Weird thing with it was I
got everything working with y-tile but x-tile was 100% fail. I'll need
to repro those results and see why I got that. There was recently fixed
regression on igt side which may have affected my results but I'll
probably anyway need to have another round for these patches including
fixes to those parts you pointed out.
/Juha-Pekka
wakeref = intel_runtime_pm_get(>runtime_pm);
atomic_inc(>gpu_error.pending_fb_pin);
@@ -138,7 +143,7 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space
*vm)
continue;
vma = i915_gem_object_ggtt_pin_ww(dpt->obj, , NULL, 0, 4096,
- HAS_LMEM(i915) ? 0 :
PIN_MAPPABLE);
+ pin_flags);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
continue;
@@ -248,10 +253,13 @@ intel_dpt_create(struct intel_framebuffer *fb)
size = round_up(size * sizeof(gen8_pte_t), I915_GTT_PAGE_SIZE);
- if (HAS_LMEM(i915))
- dpt_obj = i915_gem_object_create_lmem(i915, size,
I915_BO_ALLOC_CONTIGUOUS);
- else
+ dpt_obj = i915_gem_object_create_lmem(i915, size,
I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(dpt_obj) && i915_ggtt_has_aperture(to_gt(i915)->ggtt))
dpt_obj = i915_gem_object_create_stolen(i915, size);
+ if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
+ drm_dbg_kms(>drm, "Allocating dpt from smem\n");
Hopefully this is not too noisy?
With the s/is_lmem/is_stolen/, or however you want to deal with that,
Reviewed-by: Matthew Auld
+ dpt_obj = i915_gem_object_create_internal(i915, size);
+ }
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
--
2.25.1
[Intel-gfx] [PULL] drm-intel-next -> drm-intel-gt-next cross-merge sync
Hi all,
This is for Tvrtko to pull to cross-merge sync drm-intel-next to
drm-intel-gt-next.
Dave, Daniel, IIUC this is what you prefer over having topic branches
for all the small things that are needed between drm-intel branches. I
don't think we've done this direct cross-merge before, so decided to
send a pull request for transparency. Do you want us to do it this way
going forward, or can we just do direct merges in git branches without
tagged pull requests?
Looks like drm-intel-next is ahead wrt backmerges too, so this pulls in
some drm-next to drm-intel-gt-next too.
BR,
Jani.
PS. For future reference, generated using:
$ dim pull-request drm-intel-next drm-intel/drm-intel-gt-next
The following changes since commit c54b39a565227538c52ead2349eb17d54aadd6f7:
Merge tag 'drm-intel-next-2022-04-13-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-04-14 12:03:09
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-05-20
for you to fetch changes up to 5f38c3fb55ce3814b4353320d7a205068a420e48:
drm/i915/pcode: Add a couple of pcode helpers (2022-05-20 09:11:45 +0100)
drm/i915 drm-intel-next -> drm-intel-gt-next cross-merge sync
Anshuman Gupta (1):
drm/i915: Use drm_dbg for rpm logging
Anusha Srivatsa (2):
drm/i915/dmc: Load DMC on DG2
drm/i915/dmc: Add MMIO range restrictions
Arunpravin Paneer Selvam (2):
drm/amdgpu: add drm buddy support to amdgpu
drm: add a check to verify the size alignment
Ashutosh Dixit (2):
drm/i915: Introduce has_media_ratio_mode
drm/i915/pcode: Extend pcode functions for multiple gt's
Biju Das (1):
drm: bridge: adv7511: Enable DRM_BRIDGE_OP_HPD based on HPD interrupt
Changcheng Deng (1):
fbcon: use min() to make code cleaner
Chen-Yu Tsai (4):
dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.
dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106
drm/ssd130x: Support page addressing mode
drm/ssd130x: Add support for SINO WEALTH SH1106
Christian König (16):
dma-buf: add enum dma_resv_usage v4
dma-buf: specify usage while adding fences to dma_resv obj v7
dma-buf & drm/amdgpu: remove dma_resv workaround
dma-buf: add DMA_RESV_USAGE_KERNEL v3
drm/amdgpu: use DMA_RESV_USAGE_KERNEL
drm/radeon: use DMA_RESV_USAGE_KERNEL
RDMA: use DMA_RESV_USAGE_KERNEL
dma-buf: add DMA_RESV_USAGE_BOOKKEEP v3
dma-buf: wait for map to complete for static attachments
drm/i915: drop bo->moving dependency
drm/ttm: remove bo->moving
dma-buf: drop seq count based update
seqlock: drop seqcount_ww_mutex_t
futex: add missing rtmutex.h include
drm/ttm: fix logic inversion in ttm_eu_reserve_buffers
drm/ttm: fix kerneldoc for ttm_lru_bulk_move
Christoph Hellwig (27):
drm/i915/gvt: remove module refcounting in
intel_gvt_{,un}register_hypervisor
drm/i915/gvt: remove enum hypervisor_type
drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
drm/i915/gvt: move the gvt code into kvmgt.ko
drm/i915/gvt: remove intel_gvt_ops
drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
drm/i915/gvt: remove the unused from_virt_to_mfn op
drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
drm/i915/gvt: remove vgpu->handle
drm/i915/gvt: devirtualize ->{read,write}_gpa
drm/i915/gvt: devirtualize ->{get,put}_vfio_device
drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
drm/i915/gvt: devirtualize ->detach_vgpu
drm/i915/gvt: devirtualize ->inject_msi
drm/i915/gvt: devirtualize ->is_valid_gfn
drm/i915/gvt: devirtualize ->gfn_to_mfn
drm/i915/gvt: devirtualize ->{enable,disable}_page_track
drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
drm/i915/gvt: devirtualize dma_pin_guest_page
drm/i915/gvt: remove struct intel_gvt_mpt
drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
drm/i915/gvt: streamline intel_vgpu_create
drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
drm/i915/gvt: remove kvmgt_guest_{init,exit}
drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
drm/i915/gvt: merge gvt.c into kvmgvt.c
Colin Ian King (1):
drm: sti: fix spelling mistake: rejec -> rejection
Dale B Stimson (1):
drm/i915/pcode: Add a couple of pcode helpers
Daniel Vetter (18):
fbcon: delete a few unneeded forward decl
fbcon: Move fbcon_bmove(_rec) functions
fbcon: Introduce wrapper for console->fb_info lookup
fbcon: delete delayed loading code
fbdev/sysfs: Fix locking
fbcon:
Re: [Intel-gfx] [PATCH v3 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
On 17/05/2022 16:15, Matt Roper wrote:
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose between the old "hsw-style" subslice masks or the newer xehp
mask. HSW-style masks will be stored in an array of u8's, indexed by
slice (there's never more than 6 subslices per slice on older
platforms). For Xe_HP and beyond where slices no longer exist, we only
need a single bitmask. However we already know that this mask is
eventually going to grow too large for a simple u64 to hold, so we'll
represent it in a manner that can be operated on by the utilities in
linux/bitmap.h.
v3:
- Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 246 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 78 +++---
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_getparam.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 8 +-
9 files changed, 226 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..a3bb73f5d53b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
{
const struct sseu_dev_info *device = >info.sseu;
struct drm_i915_private *i915 = gt->i915;
+ unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
0);
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
if (user->slice_mask & ~device->slice_mask)
return -EINVAL;
- if (user->subslice_mask & ~device->subslice_mask[0])
+ if (user->subslice_mask & ~dev_subslice_mask)
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
/* Part specific restrictions. */
if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
- unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
+ unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
unsigned int req_s = hweight8(context->slice_mask);
unsigned int req_ss = hweight8(context->subslice_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1adbf34c3632..f0acf8518a51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct intel_gt
*gt)
if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
return;
- ccs_mask = intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
- ss_per_ccs);
+ ccs_mask =
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
+ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
* engine is not available for use.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 034182f85501..2921f510642f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -133,13 +133,6 @@ static const struct intel_mmio_range
dg2_lncf_steering_table[] = {
{},
};
-static u16 slicemask(struct intel_gt *gt, int count)
-{
- u64 dss_mask = intel_sseu_get_subslices(>info.sseu, 0);
-
- return intel_slicemask_from_dssmask(dss_mask, count);
-}
-
int intel_gt_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -155,9 +148,12 @@ int intel_gt_init_mmio(struct intel_gt *gt)
*/
if (HAS_MSLICES(i915)) {
gt->info.mslice_mask =
- slicemask(gt, GEN_DSS_PER_MSLICE) |
+
intel_slicemask_from_xehp_dssmask(gt->info.sseu.subslice_mask,
+ GEN_DSS_PER_MSLICE);
+ gt->info.mslice_mask |=
(intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) &
GEN12_MEML3_EN_MASK);
+
[Intel-gfx] [PATCH] drm/i915/dsi: fix VBT send packet port selection for ICL+
The VBT send packet port selection was never updated for ICL+ where the
2nd link is on port B instead of port C as in VLV+ DSI.
First, single link DSI needs to use the configured port instead of
relying on the VBT sequence block port. Remove the hard-coded port C
check here and make it generic. For reference, see commit f915084edc5a
("drm/i915: Changes related to the sequence port no for") for the
original VLV specific fix.
Second, the sequence block port number is either 0 or 1, where 1
indicates the 2nd link. Remove the hard-coded port C here for 2nd
link. (This could be a "find second set bit" on DSI ports, but just
check the two possible options.)
Third, sanity check the result with a warning to avoid a NULL pointer
dereference.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5984
Cc: sta...@vger.kernel.org # v4.19+
Cc: Ville Syrjala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 33 +---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index f370e9c4350d..dd24aef925f2 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -125,9 +125,25 @@ struct i2c_adapter_lookup {
#define ICL_GPIO_DDPA_CTRLCLK_2 8
#define ICL_GPIO_DDPA_CTRLDATA_2 9
-static enum port intel_dsi_seq_port_to_port(u8 port)
+static enum port intel_dsi_seq_port_to_port(struct intel_dsi *intel_dsi,
+ u8 seq_port)
{
- return port ? PORT_C : PORT_A;
+ /*
+* If single link DSI is being used on any port, the VBT sequence block
+* send packet apparently always has 0 for the port. Just use the port
+* we have configured, and ignore the sequence block port.
+*/
+ if (hweight8(intel_dsi->ports) == 1)
+ return ffs(intel_dsi->ports) - 1;
+
+ if (seq_port) {
+ if (intel_dsi->ports & PORT_B)
+ return PORT_B;
+ else if (intel_dsi->ports & PORT_C)
+ return PORT_C;
+ }
+
+ return PORT_A;
}
static const u8 *mipi_exec_send_packet(struct intel_dsi *intel_dsi,
@@ -149,15 +165,10 @@ static const u8 *mipi_exec_send_packet(struct intel_dsi
*intel_dsi,
seq_port = (flags >> MIPI_PORT_SHIFT) & 3;
- /* For DSI single link on Port A & C, the seq_port value which is
-* parsed from Sequence Block#53 of VBT has been set to 0
-* Now, read/write of packets for the DSI single link on Port A and
-* Port C will based on the DVO port from VBT block 2.
-*/
- if (intel_dsi->ports == (1 << PORT_C))
- port = PORT_C;
- else
- port = intel_dsi_seq_port_to_port(seq_port);
+ port = intel_dsi_seq_port_to_port(intel_dsi, seq_port);
+
+ if (drm_WARN_ON(_priv->drm, !intel_dsi->dsi_hosts[port]))
+ goto out;
dsi_device = intel_dsi->dsi_hosts[port]->device;
if (!dsi_device) {
--
2.30.2
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/sseu: Don't try to store EU mask internally in UAPI format
On 17/05/2022 04:20, Matt Roper wrote:
Storing the EU mask internally in the same format the I915_QUERY
topology queries use makes the final copy_to_user() a bit simpler, but
makes the rest of the driver's SSEU more complicated and harder to
follow. Let's switch to an internal representation that's more natural:
Xe_HP platforms will be a simple array of u16 masks, whereas pre-Xe_HP
platforms will be a two-dimensional array, indexed by [slice][subslice].
We'll convert to the uapi format only when the query uapi is called.
v2:
- Drop has_common_ss_eumask. We waste some space repeating identical
EU masks for every single DSS, but the code is simpler without it.
(Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 77 +++-
drivers/gpu/drm/i915/gt/intel_sseu.h | 9 +++-
drivers/gpu/drm/i915/i915_query.c| 8 +--
3 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index ade3e1805782..d89e2e0f05e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -78,47 +78,76 @@ intel_sseu_subslices_per_slice(const struct sseu_dev_info
*sseu, u8 slice)
return hweight32(intel_sseu_get_subslices(sseu, slice));
}
-static int sseu_eu_idx(const struct sseu_dev_info *sseu, int slice,
- int subslice)
-{
- int slice_stride = sseu->max_subslices * sseu->eu_stride;
-
- return slice * slice_stride + subslice * sseu->eu_stride;
-}
-
static u16 sseu_get_eus(const struct sseu_dev_info *sseu, int slice,
int subslice)
{
- int i, offset = sseu_eu_idx(sseu, slice, subslice);
- u16 eu_mask = 0;
-
- for (i = 0; i < sseu->eu_stride; i++)
- eu_mask |=
- ((u16)sseu->eu_mask[offset + i]) << (i * BITS_PER_BYTE);
-
- return eu_mask;
+ if (sseu->has_xehp_dss) {
+ WARN_ON(slice > 0);
+ return sseu->eu_mask.xehp[subslice];
+ } else {
+ return sseu->eu_mask.hsw[slice][subslice];
+ }
}
static void sseu_set_eus(struct sseu_dev_info *sseu, int slice, int subslice,
u16 eu_mask)
{
- int i, offset = sseu_eu_idx(sseu, slice, subslice);
-
- for (i = 0; i < sseu->eu_stride; i++)
- sseu->eu_mask[offset + i] =
- (eu_mask >> (BITS_PER_BYTE * i)) & 0xff;
+ if (sseu->has_xehp_dss) {
+ WARN_ON(slice > 0);
+ sseu->eu_mask.xehp[subslice] = eu_mask;
+ } else {
+ eu_mask &= GENMASK(sseu->max_eus_per_subslice - 1, 0);
Is this masking required? Oh I remember.. it's the type expansion! I thought
that was wrong. I mean the callers are wrong. Some use u8 for the mask and then
do ~mask passing it into u16 here. I don't think this function should account
for that but callers should stop passing in garbage.
I had this in my patch:
GEM_WARN_ON(mask && (__fls(mask) >= sseu->max_eus_per_subslice));
And in the callers like:
- sseu_set_eus(sseu, 0, 0, ~disabled_mask);
+ sseu_set_eus(sseu, 0, 0, ~disabled_mask & 0xff);
- sseu_set_eus(sseu, s, ss, ~eu_disabled_mask);
+ sseu_set_eus(sseu, s, ss, ~eu_disabled_mask & eu_mask);
+ sseu->eu_mask.hsw[slice][subslice] = eu_mask;
+ }
}
static u16 compute_eu_total(const struct sseu_dev_info *sseu)
{
- u16 i, total = 0;
+ int s, ss, total = 0;
- for (i = 0; i < ARRAY_SIZE(sseu->eu_mask); i++)
- total += hweight8(sseu->eu_mask[i]);
+ for (s = 0; s < sseu->max_slices; s++)
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (sseu->has_xehp_dss)
+ total += hweight16(sseu->eu_mask.xehp[ss]);
+ else
+ total += hweight16(sseu->eu_mask.hsw[s][ss]);
return total;
}
+/**
+ * intel_sseu_copy_eumask_to_user - Copy EU mask into a userspace buffer
+ * @to: Pointer to userspace buffer to copy to
+ * @sseu: SSEU structure containing EU mask to copy
+ *
+ * Copies the EU mask to a userspace buffer in the format expected by
+ * the query ioctl's topology queries.
+ *
+ * Returns the result of the copy_to_user() operation.
+ */
+int intel_sseu_copy_eumask_to_user(void __user *to,
+ const struct sseu_dev_info *sseu)
+{
+ u8 eu_mask[GEN_SS_MASK_SIZE * GEN_MAX_EU_STRIDE] = {};
+ int len = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
How compilcated to kick eu_stride out of kernel struct sseu_dev_info and just
calculate it here? Since I don't think it belongs in the kernel struct.
What about ss_stride - is that still in use at this point, or by the end of the
series, and could it
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/sseu: Simplify gen11+ SSEU handling
On 17/05/2022 04:20, Matt Roper wrote:
Although gen11 and gen12 architectures supported the concept of multiple
slices, in practice all the platforms that were actually designed only
had a single slice (i.e., note the parameters to 'intel_sseu_set_info'
that we pass for each platform). We can simplify the code slightly by
dropping the multi-slice logic from gen11+ platforms.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 80 ++--
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index b5fd479a7b85..ade3e1805782 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -119,52 +119,37 @@ static u16 compute_eu_total(const struct sseu_dev_info
*sseu)
return total;
}
-static u32 get_ss_stride_mask(struct sseu_dev_info *sseu, u8 s, u32 ss_en)
-{
- u32 ss_mask;
-
- ss_mask = ss_en >> (s * sseu->max_subslices);
- ss_mask &= GENMASK(sseu->max_subslices - 1, 0);
-
- return ss_mask;
-}
-
-static void gen11_compute_sseu_info(struct sseu_dev_info *sseu, u8 s_en,
+static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
u32 g_ss_en, u32 c_ss_en, u16 eu_en)
{
- int s, ss;
+ u32 valid_ss_mask = GENMASK(sseu->max_subslices - 1, 0);
+ int ss;
/* g_ss_en/c_ss_en represent entire subslice mask across all slices */
GEM_BUG_ON(sseu->max_slices * sseu->max_subslices >
sizeof(g_ss_en) * BITS_PER_BYTE);
- for (s = 0; s < sseu->max_slices; s++) {
- if ((s_en & BIT(s)) == 0)
- continue;
+ sseu->slice_mask |= BIT(0);
- sseu->slice_mask |= BIT(s);
-
- /*
-* XeHP introduces the concept of compute vs geometry DSS. To
-* reduce variation between GENs around subslice usage, store a
-* mask for both the geometry and compute enabled masks since
-* userspace will need to be able to query these masks
-* independently. Also compute a total enabled subslice count
-* for the purposes of selecting subslices to use in a
-* particular GEM context.
-*/
- intel_sseu_set_subslices(sseu, s, sseu->compute_subslice_mask,
-get_ss_stride_mask(sseu, s, c_ss_en));
- intel_sseu_set_subslices(sseu, s, sseu->geometry_subslice_mask,
-get_ss_stride_mask(sseu, s, g_ss_en));
- intel_sseu_set_subslices(sseu, s, sseu->subslice_mask,
-get_ss_stride_mask(sseu, s,
- g_ss_en | c_ss_en));
+ /*
+* XeHP introduces the concept of compute vs geometry DSS. To reduce
+* variation between GENs around subslice usage, store a mask for both
+* the geometry and compute enabled masks since userspace will need to
+* be able to query these masks independently. Also compute a total
+* enabled subslice count for the purposes of selecting subslices to
+* use in a particular GEM context.
+*/
+ intel_sseu_set_subslices(sseu, 0, sseu->compute_subslice_mask,
+c_ss_en & valid_ss_mask);
+ intel_sseu_set_subslices(sseu, 0, sseu->geometry_subslice_mask,
+g_ss_en & valid_ss_mask);
+ intel_sseu_set_subslices(sseu, 0, sseu->subslice_mask,
+(g_ss_en | c_ss_en) & valid_ss_mask);
+
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (intel_sseu_has_subslice(sseu, 0, ss))
+ sseu_set_eus(sseu, 0, ss, eu_en);
- for (ss = 0; ss < sseu->max_subslices; ss++)
- if (intel_sseu_has_subslice(sseu, s, ss))
- sseu_set_eus(sseu, s, ss, eu_en);
- }
sseu->eu_per_subslice = hweight16(eu_en);
sseu->eu_total = compute_eu_total(sseu);
}
@@ -196,7 +181,7 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
if (eu_en_fuse & BIT(eu))
eu_en |= BIT(eu * 2) | BIT(eu * 2 + 1);
- gen11_compute_sseu_info(sseu, 0x1, g_dss_en, c_dss_en, eu_en);
+ gen11_compute_sseu_info(sseu, g_dss_en, c_dss_en, eu_en);
}
static void gen12_sseu_info_init(struct intel_gt *gt)
@@ -216,8 +201,15 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
*/
intel_sseu_set_info(sseu, 1, 6, 16);
+ /*
+* Although gen12 architecture supported multiple slices, TGL, RKL,
+* DG1, and ADL only had a single slice.
+*/
s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
GEN11_GT_S_ENA_MASK;
+ if (s_en !=
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
On 17/05/2022 04:20, Matt Roper wrote: Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support traditional slices (and we make no attempt to return the various new units like gslices, cslices, mslices, etc.) here. The subslice mask lookup is even more problematic; given the distinct masks for geometry vs compute purposes, the combined mask returned here is likely not what userspace would want to act upon anyway. The value is also limited to 32-bits by the nature of the GETPARAM ioctl which is sufficient for the initial Xe_HP platforms, but is unable to convey the larger masks that will be needed on other upcoming platforms. Finally, the value returned here becomes even less meaningful when used on multi-tile platforms where each tile will have its own masks. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_getparam.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index c12a0adefda5..ac9767c56619 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -148,11 +148,19 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = intel_engines_has_context_isolation(i915); break; case I915_PARAM_SLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + value = sseu->slice_mask; if (!value) return -ENODEV; break; case I915_PARAM_SUBSLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + /* Only copy bits from the first slice */ memcpy(, sseu->subslice_mask, min(sseu->ss_stride, (u8)sizeof(value))); Just in case lets run this by Jordan and Lionel since it affects DG2. Anyone else on the userspace side who might be affected? Regards, Tvrtko
[Intel-gfx] [CI] Maintenance: Intel-GFX-CI down on weekend 27.5.-29.5.
This is early warning about GFX-CI going down for maintenance on next week weekend Fri 27.5. to Sun 29.5. GFX-CI will be migrating to new hardware starting Friday 27.5. and estimated downtime is at least 48h (CIBuglog database dump/import). During downtime, no new builds are done and no testing is performed. If all goes well, CI will be running on new server on Monday 30.5. If not, the old server is rolled back by changing IP and the services will be restarted on old hardware. Visible improvement will be doubling of disk space, which allows us to have more history stored. Weekends usually are quiet on mailing lists, so I hope this won't be too much of an inconvenience. Best Regards, Tomi Sarvela -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Re: [Intel-gfx] [PATCH] drm/i915: Sanitycheck PCI BARs on probe
Jani Nikula wrote on pią [2022-maj-20 10:40:01
+0300]:
> On Thu, 20 Jan 2022, "Piorkowski, Piotr" wrote:
> > From: Piotr Piórkowski
> >
> > For proper operation of i915 we need usable PCI BARs:
> > - GTTMMADDR BAR 0 (1 for GEN2)
> > - GFXMEM BAR 2.
> > Lets check before we start the i915 probe that these BARs are set,
> > and that they have a size greater than 0.
> >
> > Signed-off-by: Piotr Piórkowski
> > Cc: Michal Wajdeczko
> > Cc: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 33 +
> > drivers/gpu/drm/i915/intel_pci_config.h | 5
> > 2 files changed, 38 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 8261b6455747..ad60c69d9dd8 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -29,6 +29,8 @@
> > #include "i915_drv.h"
> > #include "i915_pci.h"
> >
>
> Superfluous blank line.
>
> > +#include "intel_pci_config.h"
>
> Please put the includes together and sort.
>
ok
> > +
> > #define PLATFORM(x) .platform = (x)
> > #define GEN(x) \
> > .graphics.ver = (x), \
> > @@ -1181,6 +1183,34 @@ static bool force_probe(u16 device_id, const char
> > *devices)
> > return ret;
> > }
> >
> > +static bool __pci_resource_valid(struct pci_dev *pdev, int bar)
> > +{
> > + if (!pci_resource_flags(pdev, bar))
> > + return false;
> > +
> > + if (pci_resource_flags(pdev, bar) & IORESOURCE_UNSET)
> > + return false;
> > +
> > + if (!pci_resource_len(pdev, bar))
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > +static bool intel_bars_valid(struct pci_dev *pdev, struct
> > intel_device_info *intel_info)
> > +{
> > + const int gttmmaddr_bar = intel_info->graphics.ver == 2 ?
> > GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
> > + const int gfxmem_bar = GFXMEM_BAR;
>
> We don't usually bother with const for non-pointer local variables.
ok
>
> > +
> > + if (!__pci_resource_valid(pdev, gttmmaddr_bar))
> > + return false;
> > +
> > + if (!__pci_resource_valid(pdev, gfxmem_bar))
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> > *ent)
> > {
> > struct intel_device_info *intel_info =
> > @@ -1206,6 +1236,9 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> > struct pci_device_id *ent)
> > if (PCI_FUNC(pdev->devfn))
> > return -ENODEV;
> >
> > + if (!intel_bars_valid(pdev, intel_info))
> > + return -ENODEV;
> > +
> > /* Detect if we need to wait for other drivers early on */
> > if (intel_modeset_probe_defer(pdev))
> > return -EPROBE_DEFER;
> > diff --git a/drivers/gpu/drm/i915/intel_pci_config.h
> > b/drivers/gpu/drm/i915/intel_pci_config.h
> > index 12cd9d4f23de..c08fd5d48ada 100644
> > --- a/drivers/gpu/drm/i915/intel_pci_config.h
> > +++ b/drivers/gpu/drm/i915/intel_pci_config.h
> > @@ -6,6 +6,11 @@
> > #ifndef __INTEL_PCI_CONFIG_H__
> > #define __INTEL_PCI_CONFIG_H__
> >
> > +/* PCI BARs */
> > +#define GTTMMADR_BAR 0
> > +#define GEN2_GTTMMADR_BAR 1
> > +#define GFXMEM_BAR 2
>
> Is anyone outside of intel_pci_config.c going to need these? They could
> be there if not.
>
We could use this in all i915. There are lots of places where we use BAR numbers
instead of constants when operating on pci resources.
E.g. all intel_pci_resource calls, or directs calls pci_resource_start
and pci_resource_len.
For now, we use two ( and an exception for gen2) BARs in i915,
but there may be more in the future.
It may be useful to organize this.
Thanks for review!
Piotr
> BR,
> Jani.
>
>
> > +
> > /* BSM in include/drm/i915_drm.h */
> >
> > #define MCHBAR_I9150x44
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Re: [Intel-gfx] [PATCH] drm/i915: Sanitycheck PCI BARs on probe
On Thu, 20 Jan 2022, "Piorkowski, Piotr" wrote:
> From: Piotr Piórkowski
>
> For proper operation of i915 we need usable PCI BARs:
> - GTTMMADDR BAR 0 (1 for GEN2)
> - GFXMEM BAR 2.
> Lets check before we start the i915 probe that these BARs are set,
> and that they have a size greater than 0.
>
> Signed-off-by: Piotr Piórkowski
> Cc: Michal Wajdeczko
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_pci.c | 33 +
> drivers/gpu/drm/i915/intel_pci_config.h | 5
> 2 files changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 8261b6455747..ad60c69d9dd8 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -29,6 +29,8 @@
> #include "i915_drv.h"
> #include "i915_pci.h"
>
Superfluous blank line.
> +#include "intel_pci_config.h"
Please put the includes together and sort.
> +
> #define PLATFORM(x) .platform = (x)
> #define GEN(x) \
> .graphics.ver = (x), \
> @@ -1181,6 +1183,34 @@ static bool force_probe(u16 device_id, const char
> *devices)
> return ret;
> }
>
> +static bool __pci_resource_valid(struct pci_dev *pdev, int bar)
> +{
> + if (!pci_resource_flags(pdev, bar))
> + return false;
> +
> + if (pci_resource_flags(pdev, bar) & IORESOURCE_UNSET)
> + return false;
> +
> + if (!pci_resource_len(pdev, bar))
> + return false;
> +
> + return true;
> +}
> +
> +static bool intel_bars_valid(struct pci_dev *pdev, struct intel_device_info
> *intel_info)
> +{
> + const int gttmmaddr_bar = intel_info->graphics.ver == 2 ?
> GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
> + const int gfxmem_bar = GFXMEM_BAR;
We don't usually bother with const for non-pointer local variables.
> +
> + if (!__pci_resource_valid(pdev, gttmmaddr_bar))
> + return false;
> +
> + if (!__pci_resource_valid(pdev, gfxmem_bar))
> + return false;
> +
> + return true;
> +}
> +
> static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> struct intel_device_info *intel_info =
> @@ -1206,6 +1236,9 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> if (PCI_FUNC(pdev->devfn))
> return -ENODEV;
>
> + if (!intel_bars_valid(pdev, intel_info))
> + return -ENODEV;
> +
> /* Detect if we need to wait for other drivers early on */
> if (intel_modeset_probe_defer(pdev))
> return -EPROBE_DEFER;
> diff --git a/drivers/gpu/drm/i915/intel_pci_config.h
> b/drivers/gpu/drm/i915/intel_pci_config.h
> index 12cd9d4f23de..c08fd5d48ada 100644
> --- a/drivers/gpu/drm/i915/intel_pci_config.h
> +++ b/drivers/gpu/drm/i915/intel_pci_config.h
> @@ -6,6 +6,11 @@
> #ifndef __INTEL_PCI_CONFIG_H__
> #define __INTEL_PCI_CONFIG_H__
>
> +/* PCI BARs */
> +#define GTTMMADR_BAR 0
> +#define GEN2_GTTMMADR_BAR1
> +#define GFXMEM_BAR 2
Is anyone outside of intel_pci_config.c going to need these? They could
be there if not.
BR,
Jani.
> +
> /* BSM in include/drm/i915_drm.h */
>
> #define MCHBAR_I915 0x44
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915: Reject the atomic modeset if an associated Type-C port is disconnected
Hi Imre,
> On Wed, May 18, 2022 at 10:04:14AM +0300, Kasireddy, Vivek wrote:
> > Hi Imre,
> >
> > > On Mon, May 16, 2022 at 01:54:02AM -0700, Vivek Kasireddy wrote:
> > > > Although, doing a modeset on any disconnected connector might be futile,
> > > > it can be particularly problematic if the connector is a Type-C port
> > > > without a sink. And, the spec only says "Display software must not use
> > > > a disconnected port" while referring to the Type-C DDI seqeuence, it
> > > > does
> > > > not spell out what happens if such an attempt is made. Experimental
> > > > results
> > > > have shown that this can lead to serious issues including a system hang.
> > > > Therefore, reject the atomic modeset if we detect that the Type-C port
> > > > is not connected.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Vivek Kasireddy
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_atomic.c | 20
> > > > 1 file changed, 20 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > index 40da7910f845..40576964b8c1 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > @@ -114,6 +114,8 @@ int
> > > > intel_digital_connector_atomic_set_property(struct
> > > drm_connector *connector,
> > > > int intel_digital_connector_atomic_check(struct drm_connector *conn,
> > > > struct drm_atomic_state *state)
> > > > {
> > > > + struct drm_device *dev = conn->dev;
> > > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > > struct drm_connector_state *new_state =
> > > > drm_atomic_get_new_connector_state(state, conn);
> > > > struct intel_digital_connector_state *new_conn_state =
> > > > @@ -122,6 +124,10 @@ int intel_digital_connector_atomic_check(struct
> > > drm_connector *conn,
> > > > drm_atomic_get_old_connector_state(state, conn);
> > > > struct intel_digital_connector_state *old_conn_state =
> > > > to_intel_digital_connector_state(old_state);
> > > > + struct intel_encoder *encoder =
> > > > + intel_attached_encoder(to_intel_connector(conn));
> > > > + struct intel_digital_port *dig_port =
> > > > + encoder ? enc_to_dig_port(encoder) : NULL;
> > > > struct drm_crtc_state *crtc_state;
> > > >
> > > > intel_hdcp_atomic_check(conn, old_state, new_state);
> > > > @@ -131,6 +137,20 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> > > >
> > > > crtc_state = drm_atomic_get_new_crtc_state(state,
> > > > new_state->crtc);
> > > >
> > > > + /*
> > > > +* The spec says that it is not safe to use a disconnected
> > > > Type-C port.
> > > > +* Therefore, check to see if this connector is connected and
> > > > reject
> > > > +* the modeset if there is no sink detected.
> > > > +*/
> > > > + if (dig_port && !dig_port->connected(encoder) &&
> > >
> > > This check is racy, as right after dig_port->connected() returns true,
> > > the port can become disconnected.
> >
> > [Kasireddy, Vivek] Given that, do you think the only way to reliably
> > determine
> > if the Type-C port has a sink is to check the live status and ignore
> > dig_port->tc_mode?
> >
> > If that is the case, should I just add a function pointer to dig_port to
> > call
> > tc_port_live_status_mask()? Or, should I just change
> > intel_tc_port_connected()
> > to ignore dig_port->tc_mode like below:
> > @@ -764,8 +764,7 @@ bool intel_tc_port_connected(struct intel_encoder
> > *encoder)
> >
> > intel_tc_port_lock(dig_port);
> >
> > - is_connected = tc_port_live_status_mask(dig_port) &
> > - BIT(dig_port->tc_mode);
> > + is_connected = tc_port_live_status_mask(dig_port);
> >
> > Or, are there any other elegant ways that you can think of to determine
> > whether
> > a tc port has a sink or not?
>
> I meant that I don't think there is a way to prevent a modeset on a
> disconnected port.
But we need to find a way right given that the spec clearly states that the
driver
must not use or access (PHY/FIA registers of) a disconnected tc port.
> Live status is what provides the connected state, but
> it can change right after it is read out.
Does this change happen after giving up the ownership (in
icl_tc_phy_disconnect)?
But shouldn't we distinguish between the cases where we are deliberately
disconnecting
the phy for power-savings reason vs when the port actually becomes disconnected?
The port can still be considered connected in the former case right?
Under what other situations would the live status change or become unreliable
after the port has a connected sink? And, since we rely on SDEISR to detect the
live status for tc legacy ports, could this not be
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2022-05-20:
Fix for a memory leak in dp_mst, a (userspace) build fix for
DMA_BUF_SET_NAME defines and a directory name generation fix for dmabuf
stats
The following changes since commit 6fed53de560768bde6d701a7c79c253b45b259e3:
drm/vc4: hdmi: Fix build error for implicit function declaration (2022-05-12
11:01:19 +0200)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-05-20
for you to fetch changes up to 6e03b13cc7d9427c2c77feed1549191015615202:
drm/dp/mst: fix a possible memory leak in fetch_monitor_name() (2022-05-17
15:56:18 -0400)
Fix for a memory leak in dp_mst, a (userspace) build fix for
DMA_BUF_SET_NAME defines and a directory name generation fix for dmabuf
stats
Charan Teja Kalla (1):
dma-buf: ensure unique directory name for dmabuf stats
Hangyu Hua (1):
drm/dp/mst: fix a possible memory leak in fetch_monitor_name()
Jérôme Pouiller (1):
dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspace
drivers/dma-buf/dma-buf.c| 8
drivers/gpu/drm/dp/drm_dp_mst_topology.c | 1 +
include/uapi/linux/dma-buf.h | 4 ++--
3 files changed, 11 insertions(+), 2 deletions(-)
signature.asc
Description: PGP signature
[Intel-gfx] [linux-next:master] BUILD REGRESSION 21498d01d045c5b95b93e0a0625ae965b4330ebe
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 21498d01d045c5b95b93e0a0625ae965b4330ebe Add linux-next specific files for 20220519 Error/Warning reports: https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https://lore.kernel.org/linux-mm/202205041248.wgcwpcev-...@intel.com https://lore.kernel.org/linux-mm/202205122113.ulkzd3sz-...@intel.com https://lore.kernel.org/linux-mm/202205172344.3gfeaum1-...@intel.com https://lore.kernel.org/linux-mm/202205192041.eajgoxsy-...@intel.com https://lore.kernel.org/linux-mm/202205192334.dnijfntc-...@intel.com https://lore.kernel.org/linux-mm/202205200219.llzx7zfy-...@intel.com https://lore.kernel.org/llvm/202205052057.2tyesxsl-...@intel.com https://lore.kernel.org/llvm/202205060132.uhqyux1l-...@intel.com https://lore.kernel.org/llvm/202205170352.5yjubp5h-...@intel.com https://lore.kernel.org/llvm/202205200012.68rphrep-...@intel.com Error/Warning: (recently discovered and may have been fixed) : fatal error: ./include/generated/utsrelease.h: No such file or directory ERROR: modpost: "devm_ioremap_resource" [drivers/net/can/ctucanfd/ctucanfd_platform.ko] undefined! arch/x86/kvm/hyperv.c:1983:22: error: shift count >= width of type [-Werror,-Wshift-count-overflow] arch/x86/kvm/pmu.h:20:32: warning: 'vmx_icl_pebs_cpu' defined but not used [-Wunused-const-variable=] drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1364:5: warning: no previous prototype for 'amdgpu_discovery_get_mall_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:1986:6: warning: no previous prototype for function 'gfx_v11_0_rlc_stop' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/soc21.c:171:6: warning: no previous prototype for 'soc21_grbm_select' [-Wmissing-prototypes] drivers/gpu/drm/solomon/ssd130x-spi.c:154:35: warning: 'ssd130x_spi_table' defined but not used [-Wunused-const-variable=] drivers/hwmon/nct6775-platform.c:199:9: sparse:unsigned char drivers/hwmon/nct6775-platform.c:199:9: sparse:void drivers/net/ethernet/dec/tulip/eeprom.c:120:54: error: 'struct pci_dev' has no member named 'pdev'; did you mean 'dev'? drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.h:22:6: warning: no previous prototype for function 'mlx5_lag_mpesw_init' [-Wmissing-prototypes] drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.h:23:6: warning: no previous prototype for function 'mlx5_lag_mpesw_cleanup' [-Wmissing-prototypes] drivers/nvme/host/fc.c:1914: undefined reference to `blkcg_get_fc_appid' drivers/video/fbdev/omap/hwa742.c:492:5: warning: no previous prototype for 'hwa742_update_window_async' [-Wmissing-prototypes] include/asm-generic/bitops/const_hweight.h:21:76: warning: right shift count >= width of type [-Wshift-count-overflow] kernel/trace/fgraph.c:37:12: warning: no previous prototype for function 'ftrace_enable_ftrace_graph_caller' [-Wmissing-prototypes] kernel/trace/fgraph.c:46:12: warning: no previous prototype for function 'ftrace_disable_ftrace_graph_caller' [-Wmissing-prototypes] Unverified Error/Warning (likely false positive, please contact us if interested): Makefile:686: arch/h8300/Makefile: No such file or directory arch/Kconfig:10: can't open file "arch/h8300/Kconfig" arch/riscv/include/asm/tlbflush.h:23:2: error: expected assembly-time absolute expression drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1364:5: warning: no previous prototype for function 'amdgpu_discovery_get_mall_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous prototype for function 'amdgpu_ucode_print_imu_hdr' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/imu_v11_0.c:302:6: warning: no previous prototype for function 'program_imu_rlc_ram' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/soc21.c:171:6: warning: no previous prototype for function 'soc21_grbm_select' [-Wmissing-prototypes] drivers/gpu/drm/bridge/adv7511/adv7511.h:229:17: warning: 'ADV7511_REG_CEC_RX_FRAME_HDR' defined but not used [-Wunused-const-variable=] drivers/gpu/drm/bridge/adv7511/adv7511.h:235:17: warning: 'ADV7511_REG_CEC_RX_FRAME_LEN' defined but not used [-Wunused-const-variable=] drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:276:27: error: implicit declaration of function 'sysfs_gt_attribute_r_max_func' [-Werror=implicit-function-declaration] drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:327:16: error: implicit declaration of function 'sysfs_gt_attribute_w_func' [-Werror=implicit-function-declaration] drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:416:24: error: implicit declaration of function 'sysfs_gt_attribute_r_min_func' [-Werror=implicit-function-declaration] drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:47 sysfs_gt_attribute_w_func() error: uninitialized symbol 'ret'. drivers/gpu/drm/i915/gt/intel_rps.c:2325 rps_read_mmio() error: uninitialized symbol 'val'. drivers/infiniband/hw/hns/hns_roce_hw_v2.c:309:9: sparse: sparse: dubious: x & !y
