[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Try to guess PCH type even without ISA bridge (rev3)
== Series Details == Series: drm/i915: Try to guess PCH type even without ISA bridge (rev3) URL : https://patchwork.freedesktop.org/series/84886/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9596 -> Patchwork_19330 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19330 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19330, 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_19330/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19330: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9596/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_19330 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-y: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html * igt@gem_linear_blits@basic: - fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9596/fi-tgl-y/igt@gem_linear_bl...@basic.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-tgl-y/igt@gem_linear_bl...@basic.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271]) +30 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-snb-2600/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-snb-2600:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-snb-2600/igt@kms_chamel...@hdmi-crc-fast.html * igt@runner@aborted: - fi-bsw-kefka: NOTRUN -> [FAIL][8] ([i915#1436]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-bsw-kefka/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-snb-2600:[DMESG-WARN][9] ([i915#2772]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9596/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9596/fi-tgl-y/igt@gem_m...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/fi-tgl-y/igt@gem_m...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#2772]: https://gitlab.freedesktop.org/drm/intel/issues/2772 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9596 -> Patchwork_19330 CI-20190529: 20190529 CI_DRM_9596: 6acb53490b1d09467acf0862c33880a92a3e596e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5957: 2a2b3418f7458dfa1fac255cc5c71603f617690a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19330: 588e2c98139216a4b7dad4c19d4f15b3268bbb80 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 588e2c981392 drm/i915: Try to guess PCH type even without ISA bridge == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19330/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Try to guess PCH type even without ISA bridge (rev3)
== Series Details == Series: drm/i915: Try to guess PCH type even without ISA bridge (rev3) URL : https://patchwork.freedesktop.org/series/84886/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/intel_pch.c:188:13: warning: Using plain integer as NULL pointer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Try to guess PCH type even without ISA bridge
From: Zhenyu Wang
Some vmm like hyperv and crosvm don't supply any ISA bridge to their guest,
when igd passthrough is equipped on these vmm, guest i915 display may
couldn't work as guest i915 detects PCH_NONE pch type.
When i915 runs as guest, this patch guess pch type through gpu type even
without ISA bridge.
v2: Fix CI warning
v3: Add HAS_DISPLAY()= true condition beforce guessing virt pch, then
refactor.
Signed-off-by: Zhenyu Wang
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/i915_drv.h | 7 +-
drivers/gpu/drm/i915/intel_pch.c | 39 ++--
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5a7df5621aa3..df0b8f9268b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1758,6 +1758,11 @@ tgl_revids_get(struct drm_i915_private *dev_priv)
#define INTEL_DISPLAY_ENABLED(dev_priv) \
(drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),
!(dev_priv)->params.disable_display)
+static inline bool run_as_guest(void)
+{
+ return !hypervisor_is_type(X86_HYPER_NATIVE);
+}
+
static inline bool intel_vtd_active(void)
{
#ifdef CONFIG_INTEL_IOMMU
@@ -1766,7 +1771,7 @@ static inline bool intel_vtd_active(void)
#endif
/* Running as a guest, we assume the host is enforcing VT'd */
- return !hypervisor_is_type(X86_HYPER_NATIVE);
+ return run_as_guest();
}
static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private
*dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index f31c0dabd0cc..3306c1bca800 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -143,8 +143,9 @@ static bool intel_is_virt_pch(unsigned short id,
sdevice == PCI_SUBDEVICE_ID_QEMU));
}
-static unsigned short
-intel_virt_detect_pch(const struct drm_i915_private *dev_priv)
+static void
+intel_virt_detect_pch(const struct drm_i915_private *dev_priv,
+ unsigned short *pch_id, enum intel_pch *pch_type)
{
unsigned short id = 0;
@@ -181,12 +182,21 @@ intel_virt_detect_pch(const struct drm_i915_private
*dev_priv)
else
drm_dbg_kms(_priv->drm, "Assuming no PCH\n");
- return id;
+ *pch_type = intel_pch_type(dev_priv, id);
+
+ /* Sanity check virtual PCH id */
+ if (drm_WARN_ON(_priv->drm,
+ id && pch_type == PCH_NONE))
+ id = 0;
+
+ *pch_id = id;
}
void intel_detect_pch(struct drm_i915_private *dev_priv)
{
struct pci_dev *pch = NULL;
+ unsigned short id;
+ enum intel_pch pch_type;
/* DG1 has south engine display on the same PCI device */
if (IS_DG1(dev_priv)) {
@@ -206,9 +216,6 @@ void intel_detect_pch(struct drm_i915_private *dev_priv)
* of only checking the first one.
*/
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
- unsigned short id;
- enum intel_pch pch_type;
-
if (pch->vendor != PCI_VENDOR_ID_INTEL)
continue;
@@ -221,14 +228,7 @@ void intel_detect_pch(struct drm_i915_private *dev_priv)
break;
} else if (intel_is_virt_pch(id, pch->subsystem_vendor,
pch->subsystem_device)) {
- id = intel_virt_detect_pch(dev_priv);
- pch_type = intel_pch_type(dev_priv, id);
-
- /* Sanity check virtual PCH id */
- if (drm_WARN_ON(_priv->drm,
- id && pch_type == PCH_NONE))
- id = 0;
-
+ intel_virt_detect_pch(dev_priv, , _type);
dev_priv->pch_type = pch_type;
dev_priv->pch_id = id;
break;
@@ -244,10 +244,15 @@ void intel_detect_pch(struct drm_i915_private *dev_priv)
"Display disabled, reverting to NOP PCH\n");
dev_priv->pch_type = PCH_NOP;
dev_priv->pch_id = 0;
+ } else if (!pch) {
+ if (run_as_guest() && HAS_DISPLAY(dev_priv)) {
+ intel_virt_detect_pch(dev_priv, , _type);
+ dev_priv->pch_type = pch_type;
+ dev_priv->pch_id = id;
+ } else {
+ drm_dbg_kms(_priv->drm, "No PCH found.\n");
+ }
}
- if (!pch)
- drm_dbg_kms(_priv->drm, "No PCH found.\n");
-
pci_dev_put(pch);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev9)
Sparse warning was not related to this patch series. Pushed to drm-intel-next. Thanks for Reviews and Ack. Thanks, Anshuman Gupta > -Original Message- > From: Patchwork > Sent: Monday, January 11, 2021 2:07 PM > To: Gupta, Anshuman > Cc: intel-gfx@lists.freedesktop.org > Subject: ✗ Fi.CI.SPARSE: warning for HDCP 2.2 and HDCP 1.4 Gen12 DP MST > support (rev9) > > == Series Details == > > Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev9) > URL : https://patchwork.freedesktop.org/series/82998/ > State : warning > > == Summary == > > $ dim sparse --fast origin/drm-tip > Sparse version: v0.6.2 > Fast mode used, each commit won't be checked separately. > - > +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: > error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" > +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: > error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB" > +drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context > imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic > block > +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte > count of 279040 > +drivers/gpu/drm/i915/i915_perf.c:1450:15: warning: memset with byte > count of 16777216 > +drivers/gpu/drm/i915/i915_perf.c:1504:15: warning: memset with byte > count of 16777216 > +./include/linux/seqlock.h:843:24: warning: trying to copy expression type > 31 > +./include/linux/seqlock.h:843:24: warning: trying to copy expression type > 31 > +./include/linux/seqlock.h:869:16: warning: trying to copy expression type > 31 > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_read16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_read32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_read64' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_read8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_write16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_write32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'fwtable_write8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_read16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_read32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_read64' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_read8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_write16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_write32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen11_fwtable_write8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_read16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_read32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_read64' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_read8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_write16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_write32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen12_fwtable_write8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen6_read16' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen6_read32' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen6_read64' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen6_read8' - different lock contexts for basic block > +./include/linux/spinlock.h:409:9: warning: context imbalance in > 'gen6_write16' -
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/4] drm/i915/guc: Delete GuC code unused in future patches
== Series Details == Series: series starting with [v2,1/4] drm/i915/guc: Delete GuC code unused in future patches URL : https://patchwork.freedesktop.org/series/85778/ State : failure == Summary == Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/lmem: make intel_region_lmem_ops static
== Series Details == Series: drm/i915/lmem: make intel_region_lmem_ops static URL : https://patchwork.freedesktop.org/series/85763/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9595_full -> Patchwork_19327_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19327_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19327_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19327_full: ### IGT changes ### Possible regressions * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-a: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-skl7/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-skl4/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-a.html ### Piglit changes ### Possible regressions * spec@glsl-1.30@execution@texelfetch fs sampler2d 71x1-71x281: - pig-glk-j5005: NOTRUN -> [INCOMPLETE][3] +4 similar issues [3]: None New tests - New tests have been introduced between CI_DRM_9595_full and Patchwork_19327_full: ### New Piglit tests (1) ### * spec@arb_depth_buffer_float@depthstencil-render-miplevels 292 s=z24_s8_d=z32f: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_19327_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#658]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-iclb2/igt@feature_discov...@psr2.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-iclb5/igt@feature_discov...@psr2.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-snb: [PASS][6] -> [DMESG-WARN][7] ([i915#42]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-snb7/igt@gem_ctx_isolation@preservation...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-snb4/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1436] / [i915#716]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-skl5/igt@gen9_exec_pa...@allowed-single.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-skl1/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [FAIL][10] ([i915#454]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-skl2/igt@i915_pm...@dc6-psr.html * igt@kms_async_flips@test-time-stamp: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2574]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-tglb1/igt@kms_async_fl...@test-time-stamp.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-tglb6/igt@kms_async_fl...@test-time-stamp.html * igt@kms_big_fb@y-tiled-64bpp-rotate-90: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +13 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-apl3/igt@kms_big...@y-tiled-64bpp-rotate-90.html * igt@kms_chamelium@dp-mode-timings: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-apl3/igt@kms_chamel...@dp-mode-timings.html * igt@kms_chamelium@hdmi-audio-edid: - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +9 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-skl2/igt@kms_chamel...@hdmi-audio-edid.html * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> [TIMEOUT][16] ([i915#1319]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-apl3/igt@kms_content_protect...@atomic-dpms.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-random: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x21-random.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-64x21-random.html * igt@kms_cursor_crc@pipe-a-cursor-alpha-opaque: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#54]) [19]:
[Intel-gfx] [PATCH v2 4/4] drm/i915/guc: stop calling execlists_set_default_submission
Initialize all required entries from guc_set_default_submission, instead
of calling the execlists function. The previously inherited setup has
been copied over from the execlist code and simplified by removing the
execlists submission-specific parts.
v2: move setting of relative_mmio flag to engine_setup_common (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Brost
Cc: John Harrison
Reviewed-by: Chris Wilson #v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +
.../drm/i915/gt/intel_execlists_submission.c | 9 +--
.../drm/i915/gt/intel_execlists_submission.h | 2 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 60 +--
4 files changed, 48 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 6b4483b72c3f..f531207971d1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -727,6 +727,9 @@ static int engine_setup_common(struct intel_engine_cs
*engine)
intel_engine_init_whitelist(engine);
intel_engine_init_ctx_wa(engine);
+ if (INTEL_GEN(engine->i915) >= 12)
+ engine->flags |= I915_ENGINE_HAS_RELATIVE_MMIO;
+
return 0;
err_status:
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 10e9940cf3f5..d7d5a58990bb 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3100,7 +3100,7 @@ static bool can_preempt(struct intel_engine_cs *engine)
return engine->class != RENDER_CLASS;
}
-void intel_execlists_set_default_submission(struct intel_engine_cs *engine)
+static void execlists_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = execlists_submit_request;
engine->schedule = i915_schedule;
@@ -3124,9 +3124,6 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
}
}
- if (INTEL_GEN(engine->i915) >= 12)
- engine->flags |= I915_ENGINE_HAS_RELATIVE_MMIO;
-
if (intel_engine_has_preemption(engine))
engine->emit_bb_start = gen8_emit_bb_start;
else
@@ -3168,7 +3165,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->emit_fini_breadcrumb = gen12_emit_fini_breadcrumb_xcs;
engine->emit_flush = gen12_emit_flush_xcs;
}
- engine->set_default_submission = intel_execlists_set_default_submission;
+ engine->set_default_submission = execlists_set_default_submission;
if (INTEL_GEN(engine->i915) < 11) {
engine->irq_enable = gen8_logical_ring_enable_irq;
@@ -3924,7 +3921,7 @@ bool
intel_engine_in_execlists_submission_mode(const struct intel_engine_cs *engine)
{
return engine->set_default_submission ==
- intel_execlists_set_default_submission;
+ execlists_set_default_submission;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index 0c675bbff351..a8fd7adefd82 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -22,8 +22,6 @@ enum {
int intel_execlists_submission_setup(struct intel_engine_cs *engine);
-void intel_execlists_set_default_submission(struct intel_engine_cs *engine);
-
void intel_execlists_show_requests(struct intel_engine_cs *engine,
struct drm_printer *m,
void (*show_request)(struct drm_printer *m,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 29d58e1c9694..0c2216b1ce46 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -10,7 +10,6 @@
#include "gt/intel_breadcrumbs.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
-#include "gt/intel_execlists_submission.h" /* XXX */
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_lrc.h"
@@ -513,6 +512,34 @@ static int guc_request_alloc(struct i915_request *request)
return 0;
}
+static inline void queue_request(struct intel_engine_cs *engine,
+struct i915_request *rq,
+int prio)
+{
+ GEM_BUG_ON(!list_empty(>sched.link));
+ list_add_tail(>sched.link,
+ i915_sched_lookup_priolist(engine, prio));
+ set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+}
+
+static void guc_submit_request(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ unsigned long flags;
+
+ /* Will be called from irq-context when using foreign fences. */
+
[Intel-gfx] [PATCH v2 3/4] drm/i915/guc: init engine directly in GuC submission mode
Instead of starting the engine in execlists submission mode and then
switching to GuC, start directly in GuC submission mode. The initial
setup functions have been copied over from the execlists code
and simplified by removing the execlists submission-specific parts.
v2: remove unneeded unexpected starting state check (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Brost
Cc: John Harrison
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 224 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 1 +
3 files changed, 219 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f62303bf80b8..6b4483b72c3f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -40,6 +40,7 @@
#include "intel_lrc_reg.h"
#include "intel_reset.h"
#include "intel_ring.h"
+#include "uc/intel_guc_submission.h"
/* Haswell does have the CXT_SIZE register however it does not appear to be
* valid. Now, docs explain in dwords what is in the context object. The full
@@ -907,7 +908,9 @@ int intel_engines_init(struct intel_gt *gt)
enum intel_engine_id id;
int err;
- if (HAS_EXECLISTS(gt->i915))
+ if (intel_uc_uses_guc_submission(>uc))
+ setup = intel_guc_submission_setup;
+ else if (HAS_EXECLISTS(gt->i915))
setup = intel_execlists_submission_setup;
else
setup = intel_ring_submission_setup;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d4f88d2379e9..29d58e1c9694 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -6,12 +6,15 @@
#include
#include "gem/i915_gem_context.h"
+#include "gt/gen8_engine_cs.h"
+#include "gt/intel_breadcrumbs.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_execlists_submission.h" /* XXX */
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_lrc.h"
+#include "gt/intel_mocs.h"
#include "gt/intel_ring.h"
#include "intel_guc_submission.h"
@@ -55,6 +58,8 @@
*
*/
+#define GUC_REQUEST_SIZE 64 /* bytes */
+
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
{
return rb_entry(rb, struct i915_priolist, node);
@@ -446,6 +451,134 @@ static void guc_interrupts_release(struct intel_gt *gt)
intel_uncore_rmw(uncore, GEN11_VCS_VECS_INTR_ENABLE, 0, dmask);
}
+static int guc_context_alloc(struct intel_context *ce)
+{
+ return lrc_alloc(ce, ce->engine);
+}
+
+static int guc_context_pre_pin(struct intel_context *ce,
+struct i915_gem_ww_ctx *ww,
+void **vaddr)
+{
+ return lrc_pre_pin(ce, ce->engine, ww, vaddr);
+}
+
+static int guc_context_pin(struct intel_context *ce, void *vaddr)
+{
+ return lrc_pin(ce, ce->engine, vaddr);
+}
+
+static const struct intel_context_ops guc_context_ops = {
+ .alloc = guc_context_alloc,
+
+ .pre_pin = guc_context_pre_pin,
+ .pin = guc_context_pin,
+ .unpin = lrc_unpin,
+ .post_unpin = lrc_post_unpin,
+
+ .enter = intel_context_enter_engine,
+ .exit = intel_context_exit_engine,
+
+ .reset = lrc_reset,
+ .destroy = lrc_destroy,
+};
+
+static int guc_request_alloc(struct i915_request *request)
+{
+ int ret;
+
+ GEM_BUG_ON(!intel_context_is_pinned(request->context));
+
+ /*
+* Flush enough space to reduce the likelihood of waiting after
+* we start building the request - in which case we will just
+* have to repeat work.
+*/
+ request->reserved_space += GUC_REQUEST_SIZE;
+
+ /*
+* Note that after this point, we have committed to using
+* this request as it is being used to both track the
+* state of engine initialisation and liveness of the
+* golden renderstate above. Think twice before you try
+* to cancel/unwind this request now.
+*/
+
+ /* Unconditionally invalidate GPU caches and TLBs. */
+ ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
+ if (ret)
+ return ret;
+
+ request->reserved_space -= GUC_REQUEST_SIZE;
+ return 0;
+}
+
+static void sanitize_hwsp(struct intel_engine_cs *engine)
+{
+ struct intel_timeline *tl;
+
+ list_for_each_entry(tl, >status_page.timelines, engine_link)
+ intel_timeline_reset_seqno(tl);
+}
+
+static void guc_sanitize(struct intel_engine_cs *engine)
+{
+ /*
+* Poison residual state on resume, in case the suspend didn't!
+*
+* We have to assume that across suspend/resume (or other loss
+* of control) that the contents
[Intel-gfx] [PATCH v2 2/4] drm/i915/guc: do not dump execlists state with GuC submission
GuC owns the execlists state and the context IDs used for submission, so
the status of the ports and the CSB entries are not something we control
or can decode from the i915 side, therefore we can avoid dumping it. A
follow-up patch will also stop setting the csb pointers when using GuC
submission.
GuC dumps all the required events in the GuC logs when verbosity is set
high enough.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1847d3c2ea99..f62303bf80b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1470,7 +1470,9 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
drm_printf(m, "\tIPEHR: 0x%08x\n", ENGINE_READ(engine, IPEHR));
}
- if (HAS_EXECLISTS(dev_priv)) {
+ if (intel_engine_in_guc_submission_mode(engine)) {
+ /* nothing to print yet */
+ } else if (HAS_EXECLISTS(dev_priv)) {
struct i915_request * const *port, *rq;
const u32 *hws =
>status_page.addr[I915_HWS_CSB_BUF0_INDEX];
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/guc: Delete GuC code unused in future patches
From: Matthew Brost
Delete GuC code unused in future patches that rewrite the GuC interface
to work with the new firmware. Most of the code deleted relates to
workqueues or execlist port. The code is safe to remove because we still
don't allow GuC submission to be enabled, even when overriding the
modparam, so it currently can't be reached.
The defines + structs for the process descriptor and workqueue remain.
Although the new GuC interface does not require either of these for the
normal submission path multi-lrc submission does. The usage of the
process descriptor and workqueue for multi-lrc will be quite different
from the code that is deleted in this patch. A future patch will
implement multi-lrc submission.
v2: add a code in the commit message about the code being safe to
remove (Chris)
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 16 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 170 +-
3 files changed, 3 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2a343a977987..4545e90e3bf1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -579,20 +579,8 @@ int intel_guc_reset_engine(struct intel_guc *guc,
*/
int intel_guc_resume(struct intel_guc *guc)
{
- u32 action[] = {
- INTEL_GUC_ACTION_EXIT_S_STATE,
- GUC_POWER_D0,
- };
-
- /*
-* If GuC communication is enabled but submission is not supported,
-* we do not need to resume the GuC but we do need to enable the
-* GuC communication on resume (above).
-*/
- if (!intel_guc_submission_is_used(guc) || !intel_guc_is_ready(guc))
- return 0;
-
- return intel_guc_send(guc, action, ARRAY_SIZE(action));
+ /* XXX: to be implemented with submission interface rework */
+ return 0;
}
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e84ab67b317d..bc2ba7d0626c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -47,13 +47,6 @@ struct intel_guc {
struct i915_vma *stage_desc_pool;
void *stage_desc_pool_vaddr;
- struct i915_vma *workqueue;
- void *workqueue_vaddr;
- spinlock_t wq_lock;
-
- struct i915_vma *proc_desc;
- void *proc_desc_vaddr;
-
/* Control params for fw initialization */
u32 params[GUC_CTL_MAX_DWORDS];
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 694ee424b4ee..d4f88d2379e9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -67,58 +67,6 @@ static struct guc_stage_desc *__get_stage_desc(struct
intel_guc *guc, u32 id)
return [id];
}
-static int guc_workqueue_create(struct intel_guc *guc)
-{
- return intel_guc_allocate_and_map_vma(guc, GUC_WQ_SIZE, >workqueue,
- >workqueue_vaddr);
-}
-
-static void guc_workqueue_destroy(struct intel_guc *guc)
-{
- i915_vma_unpin_and_release(>workqueue, I915_VMA_RELEASE_MAP);
-}
-
-/*
- * Initialise the process descriptor shared with the GuC firmware.
- */
-static int guc_proc_desc_create(struct intel_guc *guc)
-{
- const u32 size = PAGE_ALIGN(sizeof(struct guc_process_desc));
-
- return intel_guc_allocate_and_map_vma(guc, size, >proc_desc,
- >proc_desc_vaddr);
-}
-
-static void guc_proc_desc_destroy(struct intel_guc *guc)
-{
- i915_vma_unpin_and_release(>proc_desc, I915_VMA_RELEASE_MAP);
-}
-
-static void guc_proc_desc_init(struct intel_guc *guc)
-{
- struct guc_process_desc *desc;
-
- desc = memset(guc->proc_desc_vaddr, 0, sizeof(*desc));
-
- /*
-* XXX: pDoorbell and WQVBaseAddress are pointers in process address
-* space for ring3 clients (set them as in mmap_ioctl) or kernel
-* space for kernel clients (map on demand instead? May make debug
-* easier to have it mapped).
-*/
- desc->wq_base_addr = 0;
- desc->db_base_addr = 0;
-
- desc->wq_size_bytes = GUC_WQ_SIZE;
- desc->wq_status = WQ_STATUS_ACTIVE;
- desc->priority = GUC_CLIENT_PRIORITY_KMD_NORMAL;
-}
-
-static void guc_proc_desc_fini(struct intel_guc *guc)
-{
- memset(guc->proc_desc_vaddr, 0, sizeof(struct guc_process_desc));
-}
-
static int guc_stage_desc_pool_create(struct intel_guc *guc)
{
u32 size = PAGE_ALIGN(sizeof(struct guc_stage_desc) *
@@ -154,8 +102,6 @@ static void guc_stage_desc_init(struct intel_guc *guc)
desc->stage_id = 0;
desc->priority =
[Intel-gfx] [PATCH v2 0/4]
Now that we have a common set of function for general lrc management, the only remaining dependency the guc submission code has towards the execlists submission is the engine setup. This series gets rid of that by copying the required execlists setup function in the GuC submission file; the copied functions have been further simplified by removing all the parts that are specific to the execlists submission back-end. To make the work easier, a bunch of GuC code that is not applicable to the latest GuC submission flow (which should be posted soon-ish) is removed as part of the series. v2: address comments from Chris. I've also removed the interrupt patch from teh series; I'm playing with a couple of possible alternatives and will send the patch on its own later. There is no issue in not including the patch yet since GuC submission can't be turned on. Cc: John Harrison Cc: Matthew Brost Cc: Michal Wajdeczko Cc: Chris Wilson Daniele Ceraolo Spurio (3): drm/i915/guc: do not dump execlists state with GuC submission drm/i915/guc: init engine directly in GuC submission mode drm/i915/guc: stop calling execlists_set_default_submission Matthew Brost (1): drm/i915/guc: Delete GuC code unused in future patches drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +- .../drm/i915/gt/intel_execlists_submission.c | 9 +- .../drm/i915/gt/intel_execlists_submission.h | 2 - drivers/gpu/drm/i915/gt/uc/intel_guc.c| 16 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 - .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 442 ++ .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 1 + 7 files changed, 267 insertions(+), 222 deletions(-) -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/region: make intel_region_map static
== Series Details == Series: drm/i915/region: make intel_region_map static URL : https://patchwork.freedesktop.org/series/85761/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9595_full -> Patchwork_19326_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19326_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19326_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19326_full: ### IGT changes ### Possible regressions * igt@kms_cursor_edge_walk@pipe-c-64x64-left-edge: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-iclb8/igt@kms_cursor_edge_w...@pipe-c-64x64-left-edge.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-iclb7/igt@kms_cursor_edge_w...@pipe-c-64x64-left-edge.html Known issues Here are the changes found in Patchwork_19326_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-iclb2/igt@feature_discov...@psr2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-iclb5/igt@feature_discov...@psr2.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-skl5/igt@gen9_exec_pa...@allowed-single.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [FAIL][7] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-skl4/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@live@blt: - shard-snb: [PASS][8] -> [DMESG-FAIL][9] ([i915#1409]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-snb7/igt@i915_selftest@l...@blt.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-snb5/igt@i915_selftest@l...@blt.html * igt@kms_async_flips@test-time-stamp: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2597]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-tglb1/igt@kms_async_fl...@test-time-stamp.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-tglb3/igt@kms_async_fl...@test-time-stamp.html * igt@kms_big_fb@y-tiled-64bpp-rotate-90: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +13 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-apl6/igt@kms_big...@y-tiled-64bpp-rotate-90.html * igt@kms_chamelium@dp-mode-timings: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-apl6/igt@kms_chamel...@dp-mode-timings.html * igt@kms_color@pipe-c-ctm-0-75: - shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-skl7/igt@kms_co...@pipe-c-ctm-0-75.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-skl2/igt@kms_co...@pipe-c-ctm-0-75.html * igt@kms_color_chamelium@pipe-d-ctm-red-to-blue: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-skl7/igt@kms_color_chamel...@pipe-d-ctm-red-to-blue.html * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> [TIMEOUT][17] ([i915#1319]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-apl6/igt@kms_content_protect...@atomic-dpms.html * igt@kms_cursor_crc@pipe-a-cursor-256x256-offscreen: - shard-skl: NOTRUN -> [FAIL][18] ([i915#54]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-256x256-offscreen.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-random: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) +9 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x21-random.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-64x21-random.html * igt@kms_cursor_crc@pipe-a-cursor-alpha-opaque: - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#54]) [21]:
Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: do not dump execlists state with GuC submission
On 1/6/2021 11:43 AM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2021-01-06 17:21:16) On 1/5/2021 6:55 PM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2021-01-06 02:32:28) On 1/5/2021 4:58 PM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2021-01-05 23:19:44) GuC owns the execlists state and the context IDs used for submission, so the status of the ports and the CSB entries are not something we control or can decode from the i915 side, therefore we can avoid dumping it. A follow-up patch will also stop setting the csb pointers when using GuC submission. GuC dumps all the required events in the GuC logs when verbosity is set high enough. Would not be worth including, or is it not very helpful for debugging curious engine stalls? GuC is going to reset the engine if it stalls, so we should get the GuC logs and the engine state included in the error state. Here we would be focusing on "why hasn't a request been submitted/executed". A bad request is usually self-evident, but a missing one is tricky. Agreed, but I still don't think we could use the CSB info even if we dumped it. We currently can't map CSB events in GuC submission mode to specific contexts, because the ctx IDs used by the GuC do not map to the ones used by i915. We've asked the GuC team to expose a way to do such a mapping, but that's still under discussion. In the meantime we plan to add a few traces to make sure the requests reach the GuC and use the GuC logs for what goes on inside the FW (GuC logs include the context IDs it uses for submission and all CSB events on high verbosity). I was more reflecting on what could be here instead. Details of the ctb? It would be great to have a snapshot of some relevant guc state, merely wonder if we could extract anything from the log automatically. As well as the usual what have we submitted to the guc. -Chris Just realized I hadn't replied to this. We're still discussing with the GuC team about what type of GuC status we can extract and/or ask GuC to provide. Request list aside, most of the i915-side of the GuC info is going to be global (single ctb channel, single submission queue into GuC), so it'll likely end up in a different printer function. Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/22] drm/i915/adl_s: Configure Port clock registers for ADL-S
On Fri, Dec 04, 2020 at 05:08:31PM -0800, Aditya Swarup wrote:
> Add changes to configure port clock registers for ADL-S. Combo phy port
> clocks are configured by DPCLKA_CFGCR0 and DPCLKA_CFGCR1 registers.
>
> The DDI to internal clock mappings in DPCLKA_CFGCR0 register for ADL-S
> translates to
> DDI A -> DDIA
> DDI B -> USBC1
> DDI I -> USBC2
>
> For DPCLKA_CFGCR1
> DDI J -> USBC3
> DDI K -> USBC4
>
> Bspec: 50287
> Bspec: 53812
> Bspec: 53723
>
> v2: Replace I915_READ() with intel_de_read().(Jani)
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 64 +---
> drivers/gpu/drm/i915/display/intel_display.c | 18 +-
> drivers/gpu/drm/i915/i915_reg.h | 23 ++-
> 3 files changed, 82 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 76e975b4765b..fdf692be2bc3 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3088,25 +3088,30 @@ static void icl_map_plls_to_ports(struct
> intel_encoder *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_shared_dpll *pll = crtc_state->shared_dpll;
> enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> - u32 val;
> + u32 val, mask, sel;
> + i915_reg_t reg;
> +
> + if (IS_ALDERLAKE_S(dev_priv)) {
> + reg = ADLS_DPCLKA_CFGCR(phy);
> + mask = ADLS_DPCLKA_CFGCR_DDI_CLK_SEL_MASK(phy);
> + sel = ((pll->info->id) << ADLS_DPCLKA_CFGCR_DDI_SHIFT(phy));
> + } else if (IS_ROCKETLAKE(dev_priv)) {
> + reg = ICL_DPCLKA_CFGCR0;
> + mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> + sel = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> + } else {
> + reg = ICL_DPCLKA_CFGCR0;
> + mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> + sel = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> + }
>
> mutex_lock(_priv->dpll.lock);
>
> - val = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0);
> + val = intel_de_read(dev_priv, reg);
> drm_WARN_ON(_priv->drm,
> (val & icl_dpclka_cfgcr0_clk_off(dev_priv, phy)) == 0);
>
> if (intel_phy_is_combo(dev_priv, phy)) {
> - u32 mask, sel;
> -
> - if (IS_ROCKETLAKE(dev_priv)) {
> - mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - sel = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> - } else {
> - mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
> - sel = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
> - }
> -
> /*
>* Even though this register references DDIs, note that we
>* want to pass the PHY rather than the port (DDI). For
> @@ -3119,12 +3124,12 @@ static void icl_map_plls_to_ports(struct
> intel_encoder *encoder,
>*/
> val &= ~mask;
> val |= sel;
> - intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
> - intel_de_posting_read(dev_priv, ICL_DPCLKA_CFGCR0);
> + intel_de_write(dev_priv, reg, val);
> + intel_de_posting_read(dev_priv, reg);
> }
>
> val &= ~icl_dpclka_cfgcr0_clk_off(dev_priv, phy);
> - intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
> + intel_de_write(dev_priv, reg, val);
>
> mutex_unlock(_priv->dpll.lock);
> }
> @@ -3150,9 +3155,17 @@ static void icl_unmap_plls_to_ports(struct
> intel_encoder *encoder)
>
> mutex_lock(_priv->dpll.lock);
>
> - val = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0);
> + if (IS_ALDERLAKE_S(dev_priv))
> + val = intel_de_read(dev_priv, ADLS_DPCLKA_CFGCR(phy));
> + else
> + val = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0);
> +
> val |= icl_dpclka_cfgcr0_clk_off(dev_priv, phy);
> - intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
> +
> + if (IS_ALDERLAKE_S(dev_priv))
> + intel_de_write(dev_priv, ADLS_DPCLKA_CFGCR(phy), val);
> + else
> + intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
We could potentially assign the register to a local at the top of the
function like we did in icl_map_plls_to_ports() to avoid having to do
two separate conditionals. Up to you though; it doesn't really matter
either way.
>
> mutex_unlock(_priv->dpll.lock);
> }
> @@ -3192,13 +3205,19 @@ static void icl_sanitize_port_clk_off(struct
> drm_i915_private *dev_priv,
> u32 port_mask, bool ddi_clk_needed)
> {
> enum port port;
> + bool ddi_clk_off;
> u32 val;
>
> - val = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0);
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/debugfs : PM_REQ and PM_RES registers (rev2)
== Series Details == Series: drm/i915/debugfs : PM_REQ and PM_RES registers (rev2) URL : https://patchwork.freedesktop.org/series/85437/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9594_full -> Patchwork_19324_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19324_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19324_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19324_full: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries_display_off: - shard-skl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-skl8/igt@debugfs_test@read_all_entries_display_off.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-skl2/igt@debugfs_test@read_all_entries_display_off.html - shard-iclb: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-iclb3/igt@debugfs_test@read_all_entries_display_off.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-iclb5/igt@debugfs_test@read_all_entries_display_off.html - shard-glk: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-glk1/igt@debugfs_test@read_all_entries_display_off.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-glk9/igt@debugfs_test@read_all_entries_display_off.html - shard-tglb: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-tglb1/igt@debugfs_test@read_all_entries_display_off.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-tglb8/igt@debugfs_test@read_all_entries_display_off.html - shard-apl: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-apl1/igt@debugfs_test@read_all_entries_display_off.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-apl7/igt@debugfs_test@read_all_entries_display_off.html * igt@kms_vblank@pipe-b-accuracy-idle: - shard-skl: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-skl9/igt@kms_vbl...@pipe-b-accuracy-idle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-skl8/igt@kms_vbl...@pipe-b-accuracy-idle.html Known issues Here are the changes found in Patchwork_19324_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#262]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-kbl4/igt@debugfs_test@read_all_entries_display_off.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-kbl7/igt@debugfs_test@read_all_entries_display_off.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#112283]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-iclb5/igt@gem_exec_par...@secure-non-master.html * igt@gem_render_copy@linear-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][16] ([i915#768]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-iclb5/igt@gem_render_c...@linear-to-vebox-yf-tiled.html * igt@gem_userptr_blits@mmap-offset-invalidate-idle@gtt: - shard-tglb: NOTRUN -> [SKIP][17] ([i915#1317]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-tglb5/igt@gem_userptr_blits@mmap-offset-invalidate-i...@gtt.html * igt@gem_workarounds@suspend-resume-context: - shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-kbl2/igt@gem_workarou...@suspend-resume-context.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-kbl7/igt@gem_workarou...@suspend-resume-context.html * igt@gen7_exec_parse@oacontrol-tracking: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-tglb5/igt@gen7_exec_pa...@oacontrol-tracking.html * igt@gen9_exec_parse@bb-large: - shard-apl: [PASS][21] -> [TIMEOUT][22] ([i915#2502]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/shard-apl3/igt@gen9_exec_pa...@bb-large.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/shard-apl1/igt@gen9_exec_pa...@bb-large.html *
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode
On Tue, 2021-01-12 at 22:35 +0200, Imre Deak wrote:
> On Tue, Jan 12, 2021 at 08:10:40PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 29, 2020 at 07:22:01PM +0200, Imre Deak wrote:
> > > The DP PHY vswing/pre-emphasis level programming the driver does
> > > is
> > > related to the DPTX -> first LTTPR link segment only. Accordingly
> > > it
> > > should be only programmed when link training the first LTTPR and
> > > kept
> > > as-is when training subsequent LTTPRs and the DPRX. For these
> > > latter
> > > PHYs the vs/pe levels will be set in response to writing the
> > > DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an
> > > upstream LTTPR
> > > TX PHY snooping this write access of its downstream LTTPR/DPRX RX
> > > PHY).
> > > The above is also described in DP Standard v2.0 under 3.6.6.1.
> > >
> > > While at it simplify and add the LTTPR that is link trained to
> > > the debug
> > > message in intel_dp_set_signal_levels().
> > >
> > > Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent
> > > mode link training")
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > > .../drm/i915/display/intel_dp_link_training.c | 19 +++
> > >
> > > .../drm/i915/display/intel_dp_link_training.h | 3 ++-
> > > 3 files changed, 14 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 88a6033d6867..16c563f1a515 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -6057,7 +6057,7 @@ static void
> > > intel_dp_process_phy_request(struct intel_dp *intel_dp,
> > >
> > > intel_dp_autotest_phy_ddi_disable(intel_dp, crtc_state);
> > >
> > > - intel_dp_set_signal_levels(intel_dp, crtc_state);
> > > + intel_dp_set_signal_levels(intel_dp, crtc_state, DP_PHY_DPRX);
> > >
> > > intel_dp_phy_pattern_update(intel_dp, crtc_state);
> > >
> > > diff --git
> > > a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > index 7876e781f698..d8c6d7054d11 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > @@ -335,21 +335,24 @@ intel_dp_set_link_train(struct intel_dp
> > > *intel_dp,
> > > }
> > >
> > > void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> > > - const struct intel_crtc_state
> > > *crtc_state)
> > > + const struct intel_crtc_state
> > > *crtc_state,
> > > + enum drm_dp_phy dp_phy)
> > > {
> > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > u8 train_set = intel_dp->train_set[0];
> > > + char phy_name[10];
> > >
> > > - drm_dbg_kms(_priv->drm, "Using vswing level %d%s\n",
> > > + drm_dbg_kms(_priv->drm, "Using vswing level %d%s, pre-
> > > emphasis level %d%s, at %s\n",
> > > train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
> > > - train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" :
> > > "");
> > > - drm_dbg_kms(_priv->drm, "Using pre-emphasis level %d%s\n",
> > > + train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" :
> > > "",
> > > (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
> > > DP_TRAIN_PRE_EMPHASIS_SHIFT,
> > > train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
> > > - " (max)" : "");
> > > + " (max)" : "",
> > > + intel_dp_phy_name(dp_phy, phy_name,
> > > sizeof(phy_name)));
> > >
> > > - intel_dp->set_signal_levels(intel_dp, crtc_state);
> > > + if (intel_dp_phy_is_downstream_of_source(intel_dp, dp_phy))
> > > + intel_dp->set_signal_levels(intel_dp, crtc_state);
> >
> > The function name is a bit misleading now I guess since we're not
> > actually setting the signal levels here for the LTTPRs. But since
> > the debug print is here I guess we want to still call this. And as
> > usual I can't think of a better name for this, so I'm willing
> > to accept that slight inconsistency.
>
> Agreed, will try to make that more consistent as a follow up.
>
> Btw, checking again the callers of the above, looks like
> intel_dp_process_phy_request() also misses the DPCD write for the
> vs/pe
> settings.
In older compliance design this is patch I used for Chrome in order for
retimer to snoop swing/pre-emphasis levels (VLK-11829)
https://patchwork.freedesktop.org/patch/387249/
Thanks
Khaled
>
> > Reviewed-by: Ville Syrjälä
> >
> > > }
> > >
> > > static bool
> > > @@ -359,7 +362,7 @@ intel_dp_reset_link_train(struct intel_dp
> > > *intel_dp,
> > > u8 dp_train_pat)
> > > {
> > > memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > - intel_dp_set_signal_levels(intel_dp, crtc_state);
> > > +
Re: [Intel-gfx] [PATCH] drm/i915/lmem: make intel_region_lmem_ops static
Quoting Matthew Auld (2021-01-12 17:26:41) > On Tue, 12 Jan 2021 at 17:23, Jani Nikula wrote: > > > > There are no users outside of intel_region_lmem.c. > > > > Signed-off-by: Jani Nikula > Reviewed-by: Matthew Auld I pushed this and its companion, and then applied Matthew's git mv. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: move region_lmem under gt
Quoting Matthew Auld (2021-01-12 16:43:00) > Device local-memory should be thought of as part the GT, which means it > should also sit under gt/. > > Suggested-by: Chris Wilson > Signed-off-by: Matthew Auld No significant change, yet. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Force a failed engine reset
Quoting Mika Kuoppala (2021-01-12 17:07:13)
> > + if (count & 1) {
> > + err = intel_engine_reset(engine, NULL);
> > + if (err) {
> > + GEM_TRACE_ERR("intel_engine_reset(%s)
> > failed, err:%d\n",
> > + engine->name, err);
> > + GEM_TRACE_DUMP();
> > + break;
> > + }
> > + } else {
> > + force_reset_timeout(engine);
> > + err = intel_engine_reset(engine, NULL);
>
> We dont promote to global here if the engine one fails?
>
> If not, what mechanism then guarantees the request completion.
We are testing that a failed engine reset (due to the request
preparation timing out) does not affect the status of inflight work.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Rearrange ktime_get to reduce latency against CS
Quoting Mika Kuoppala (2021-01-12 19:19:34) > Chris Wilson writes: > > > In our tests where we measure the elapsed time on both the CPU and CS > > using a udelay, our CS results match the udelay much more accurately > > than the ktime (even when using ktime_get_fast_ns). With preemption > > disabled, we can go one step lower than ktime and use local_clock. > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2919 > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c > > b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c > > index ca080445695e..c3d965279fc3 100644 > > --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c > > +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c > > @@ -112,11 +112,11 @@ static int __measure_timestamps(struct intel_context > > *ce, > > > > /* Run the request for a 100us, sampling timestamps before/after */ > > preempt_disable(); > > Do you need to promote this to local_irq_disable() ? Good suggestion. Will try to remember if we still see discrepancies... Interrupt handlers are meant to <5us, right??? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode
On Tue, Jan 12, 2021 at 08:10:40PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 29, 2020 at 07:22:01PM +0200, Imre Deak wrote:
> > The DP PHY vswing/pre-emphasis level programming the driver does is
> > related to the DPTX -> first LTTPR link segment only. Accordingly it
> > should be only programmed when link training the first LTTPR and kept
> > as-is when training subsequent LTTPRs and the DPRX. For these latter
> > PHYs the vs/pe levels will be set in response to writing the
> > DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
> > TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
> > The above is also described in DP Standard v2.0 under 3.6.6.1.
> >
> > While at it simplify and add the LTTPR that is link trained to the debug
> > message in intel_dp_set_signal_levels().
> >
> > Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> > training")
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> > .../drm/i915/display/intel_dp_link_training.c | 19 +++
> > .../drm/i915/display/intel_dp_link_training.h | 3 ++-
> > 3 files changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 88a6033d6867..16c563f1a515 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -6057,7 +6057,7 @@ static void intel_dp_process_phy_request(struct
> > intel_dp *intel_dp,
> >
> > intel_dp_autotest_phy_ddi_disable(intel_dp, crtc_state);
> >
> > - intel_dp_set_signal_levels(intel_dp, crtc_state);
> > + intel_dp_set_signal_levels(intel_dp, crtc_state, DP_PHY_DPRX);
> >
> > intel_dp_phy_pattern_update(intel_dp, crtc_state);
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 7876e781f698..d8c6d7054d11 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -335,21 +335,24 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > }
> >
> > void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> > - const struct intel_crtc_state *crtc_state)
> > + const struct intel_crtc_state *crtc_state,
> > + enum drm_dp_phy dp_phy)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > u8 train_set = intel_dp->train_set[0];
> > + char phy_name[10];
> >
> > - drm_dbg_kms(_priv->drm, "Using vswing level %d%s\n",
> > + drm_dbg_kms(_priv->drm, "Using vswing level %d%s, pre-emphasis
> > level %d%s, at %s\n",
> > train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
> > - train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "");
> > - drm_dbg_kms(_priv->drm, "Using pre-emphasis level %d%s\n",
> > + train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "",
> > (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
> > DP_TRAIN_PRE_EMPHASIS_SHIFT,
> > train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
> > - " (max)" : "");
> > + " (max)" : "",
> > + intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)));
> >
> > - intel_dp->set_signal_levels(intel_dp, crtc_state);
> > + if (intel_dp_phy_is_downstream_of_source(intel_dp, dp_phy))
> > + intel_dp->set_signal_levels(intel_dp, crtc_state);
>
> The function name is a bit misleading now I guess since we're not
> actually setting the signal levels here for the LTTPRs. But since
> the debug print is here I guess we want to still call this. And as
> usual I can't think of a better name for this, so I'm willing
> to accept that slight inconsistency.
Agreed, will try to make that more consistent as a follow up.
Btw, checking again the callers of the above, looks like
intel_dp_process_phy_request() also misses the DPCD write for the vs/pe
settings.
> Reviewed-by: Ville Syrjälä
>
> > }
> >
> > static bool
> > @@ -359,7 +362,7 @@ intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > u8 dp_train_pat)
> > {
> > memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > - intel_dp_set_signal_levels(intel_dp, crtc_state);
> > + intel_dp_set_signal_levels(intel_dp, crtc_state, dp_phy);
> > return intel_dp_set_link_train(intel_dp, crtc_state, dp_phy,
> > dp_train_pat);
> > }
> >
> > @@ -373,7 +376,7 @@ intel_dp_update_link_train(struct intel_dp *intel_dp,
> > DP_TRAINING_LANE0_SET_PHY_REPEATER(dp_phy);
> > int ret;
> >
> > - intel_dp_set_signal_levels(intel_dp, crtc_state);
> > + intel_dp_set_signal_levels(intel_dp, crtc_state, dp_phy);
> >
> > ret = drm_dp_dpcd_write(_dp->aux,
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lmem: make intel_region_lmem_ops static
== Series Details == Series: drm/i915/lmem: make intel_region_lmem_ops static URL : https://patchwork.freedesktop.org/series/85763/ State : success == Summary == CI Bug Log - changes from CI_DRM_9595 -> Patchwork_19327 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/index.html Known issues Here are the changes found in Patchwork_19327 that come from known issues: ### IGT changes ### Issues hit * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-tgl-y: [DMESG-WARN][3] ([i915#402]) -> [PASS][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-tgl-y/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][5] ([i915#1888]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 38) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9595 -> Patchwork_19327 CI-20190529: 20190529 CI_DRM_9595: 3cc2b1cffef4d3e0c2cc38285e94334d248c2c5d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5956: d9bc7773043d11d37ae5b03bf18979541a9c7ef4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19327: be6327982c466aed23952ad3efaa4880ca6a0e01 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == be6327982c46 drm/i915/lmem: make intel_region_lmem_ops static == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19327/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce Intel PXP component - Mesa single session (rev20)
== Series Details == Series: Introduce Intel PXP component - Mesa single session (rev20) URL : https://patchwork.freedesktop.org/series/84620/ State : failure == Summary == Applying: drm/i915/pxp: Introduce Intel PXP component Applying: drm/i915/pxp: set KCR reg init during the boot time Applying: drm/i915/pxp: Implement funcs to create the TEE channel Applying: drm/i915/pxp: Create the arbitrary session after boot Applying: drm/i915/pxp: Func to send hardware session termination error: patch failed: drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c:34 error: drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. hint: Use 'git am --show-current-patch=diff' to see the failed patch Using index info to reconstruct a base tree... A drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c Patch failed at 0005 drm/i915/pxp: Func to send hardware session termination When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/region: make intel_region_map static
== Series Details == Series: drm/i915/region: make intel_region_map static URL : https://patchwork.freedesktop.org/series/85761/ State : success == Summary == CI Bug Log - changes from CI_DRM_9595 -> Patchwork_19326 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/index.html Known issues Here are the changes found in Patchwork_19326 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [PASS][1] -> [INCOMPLETE][2] ([i915#142] / [i915#2405]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-byt-j1900/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html * igt@runner@aborted: - fi-byt-j1900: NOTRUN -> [FAIL][5] ([i915#1814] / [i915#2505]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/fi-byt-j1900/igt@run...@aborted.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-tgl-y: [DMESG-WARN][6] ([i915#402]) -> [PASS][7] +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-tgl-y/igt@debugfs_test@read_all_entries.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][8] ([i915#1888]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9595/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9595 -> Patchwork_19326 CI-20190529: 20190529 CI_DRM_9595: 3cc2b1cffef4d3e0c2cc38285e94334d248c2c5d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5956: d9bc7773043d11d37ae5b03bf18979541a9c7ef4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19326: 5625230459415c0f1d2b5fd58117fa781bdceee8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 562523045941 drm/i915/region: make intel_region_map static == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19326/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Rearrange ktime_get to reduce latency against CS
Chris Wilson writes:
> In our tests where we measure the elapsed time on both the CPU and CS
> using a udelay, our CS results match the udelay much more accurately
> than the ktime (even when using ktime_get_fast_ns). With preemption
> disabled, we can go one step lower than ktime and use local_clock.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2919
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> index ca080445695e..c3d965279fc3 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> @@ -112,11 +112,11 @@ static int __measure_timestamps(struct intel_context
> *ce,
>
> /* Run the request for a 100us, sampling timestamps before/after */
> preempt_disable();
Do you need to promote this to local_irq_disable() ?
-Mika
> - *dt = ktime_get_raw_fast_ns();
> + *dt = local_clock();
> write_semaphore([2], 0);
> udelay(100);
> + *dt = local_clock() - *dt;
> write_semaphore([2], 1);
> - *dt = ktime_get_raw_fast_ns() - *dt;
> preempt_enable();
>
> if (i915_request_wait(rq, 0, HZ / 2) < 0) {
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v19 08/13] drm/i915/pxp: Enable PXP power management
Hi Rodrigo,
According to our design we terminate the session after resume, and then
re-create the session at i915_pxp_tee_component_bind() in intel_pxp_tee.c
We only can terminate the session after resume, instead of during the
intel_pxp_pm_prepare_suspend() call, because there is a change that display is
stilling rendering/playing-back the protected buffer, and protected surfaces
turn corruption garbage if we terminate the session during the suspend().
Best regards,
Sean
-Original Message-
From: Vivi, Rodrigo
Sent: Thursday, January 7, 2021 9:53 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v19 08/13] drm/i915/pxp: Enable PXP power
management
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the software
> session state was marked as alive after resume. So to handle such
> case, PXP should terminate all the hardware sessions and cleanup all
> the software states after the power cycle.
>
> Signed-off-by: Huang, Sean Z
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 ++
> drivers/gpu/drm/i915/i915_drv.c| 4 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_pm.c| 65
> ++
> drivers/gpu/drm/i915/pxp/intel_pxp_pm.h| 31 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 1 +
> 6 files changed, 106 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile index 5599b92bea9b..7592fc8cbd89
> 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -265,6 +265,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp_arb.o \
> pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_context.o \
> + pxp/intel_pxp_pm.o \
> pxp/intel_pxp_tee.o
>
> # Post-mortem debug and GPU hang state capture diff --git
> a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index c94e8ac884eb..ae0387e419a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -20,6 +20,7 @@
> #include "intel_rc6.h"
> #include "intel_rps.h"
> #include "intel_wakeref.h"
> +#include "pxp/intel_pxp_pm.h"
>
> static void user_forcewake(struct intel_gt *gt, bool suspend) { @@
> -266,6 +267,8 @@ int intel_gt_resume(struct intel_gt *gt)
>
> intel_uc_resume(>uc);
>
> + intel_pxp_pm_resume(>pxp);
> +
> user_forcewake(gt, false);
>
> out_fw:
> @@ -300,6 +303,7 @@ void intel_gt_suspend_prepare(struct intel_gt
> *gt)
> user_forcewake(gt, true);
> wait_for_suspend(gt);
>
> + intel_pxp_pm_prepare_suspend(>pxp);
> intel_uc_suspend(>uc);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c index 207d50226e64..5923db004d9b
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -68,6 +68,8 @@
> #include "gt/intel_gt_pm.h"
> #include "gt/intel_rc6.h"
>
> +#include "pxp/intel_pxp_pm.h"
> +
> #include "i915_debugfs.h"
> #include "i915_drv.h"
> #include "i915_ioc32.h"
> @@ -1338,6 +1340,8 @@ static int i915_drm_resume_early(struct
> drm_device *dev)
>
> intel_power_domains_resume(dev_priv);
>
> + intel_pxp_pm_resume_early(_priv->gt.pxp);
> +
> enable_rpm_wakeref_asserts(_priv->runtime_pm);
>
> return ret;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> new file mode 100644
> index ..ebe89262485c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_arb.h"
> +#include "intel_pxp_pm.h"
> +
> +void intel_pxp_pm_prepare_suspend(struct intel_pxp *pxp) {
> + if (!pxp->ctx.inited)
> + return;
> +
> + mutex_lock(>ctx.mutex);
> +
> + /* Disable PXP-IOCTLs */
> + pxp->ctx.global_state_in_suspend = true;
> +
> + mutex_unlock(>ctx.mutex); }
> +
> +void intel_pxp_pm_resume_early(struct intel_pxp *pxp) {
> + if (!pxp->ctx.inited)
> + return;
> +
> + mutex_lock(>ctx.mutex);
> +
> + if (pxp->ctx.global_state_in_suspend) {
> + /* reset the attacked flag even there was a pending
> */
> + pxp->ctx.global_state_attacked = false;
> +
> + pxp->ctx.flag_display_hm_surface_keys = false;
> + }
> +
> + mutex_unlock(>ctx.mutex); }
> +
> +int intel_pxp_pm_resume(struct intel_pxp *pxp) {
> + int ret = 0;
> + struct intel_gt *gt =
Re: [Intel-gfx] [RFC-v19 05/13] drm/i915/pxp: Func to send hardware session termination
Hi Rodrigo,
I made the modification as below according to Chris and your suggestion, will
reflect at rev20. All my comments (// sean: ...) the won't be checked in.
This change can address part of the comment Chris provided. But please let me
go through the remaining comments at rev19 first.
Best regards,
Sean
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
index d9298cf5e1a7..6898b8826302 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
@@ -34,11 +34,7 @@ struct i915_vma *intel_pxp_cmd_get_batch(struct intel_pxp
*pxp,
memcpy(cmd, cmd_buf, cmd_size_in_dw * 4);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
// sean: my original intension just to print out the hex
command for debug. But let me remove this.
- print_hex_dump(KERN_DEBUG, "cmd binaries:",
- DUMP_PREFIX_OFFSET, 4, 4, cmd, cmd_size_in_dw *
4, true);
- }
-
+ i915_gem_object_flush_map(pool->obj);
// sean: we should flush map before unpin, thanks
Chris's suggestion.
i915_gem_object_unpin_map(pool->obj);
batch = i915_vma_instance(pool->obj, ce->vm, NULL);
@@ -56,103 +52,73 @@ int intel_pxp_cmd_submit(struct intel_pxp *pxp, u32 *cmd,
int cmd_size_in_dw)
struct i915_vma *batch;
struct i915_request *rq;
struct intel_context *ce = NULL;
- bool is_engine_pm_get = false;
// sean: replace bool with goto label.
- bool is_batch_vma_pin = false;
- bool is_skip_req_on_err = false;
- bool is_engine_get_pool = false;
struct intel_gt_buffer_pool_node *pool = NULL;
struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
+ int size = cmd_size_in_dw * 4;
ce = pxp->vcs_engine->kernel_context;
- if (!ce) {
- drm_err(>i915->drm, "VCS engine does not have context\n");
- err = -EINVAL;
- goto end;
- }
+ if (!ce)
+ return -EINVAL;
- if (!cmd || (cmd_size_in_dw * 4) > PAGE_SIZE) {
- drm_err(>i915->drm, "Failed to %s bad params\n", __func__);
+ if (!cmd || cmd_size_in_dw == 0)
return -EINVAL;
- }
intel_engine_pm_get(ce->engine);
- is_engine_pm_get = true;
- pool = intel_gt_get_buffer_pool(gt, PAGE_SIZE);
+ size = round_up(size, PAGE_SIZE);
// sean: I think this would be
better to handle the allocation size.
+ pool = intel_gt_get_buffer_pool(gt, size);
if (IS_ERR(pool)) {
- drm_err(>i915->drm, "Failed to intel_engine_get_pool()\n");
err = PTR_ERR(pool);
- goto end;
+ goto out_engine_pm_put;
}
- is_engine_get_pool = true;
batch = intel_pxp_cmd_get_batch(pxp, ce, pool, cmd, cmd_size_in_dw);
if (IS_ERR(batch)) {
- drm_err(>i915->drm, "Failed to
intel_pxp_cmd_get_batch()\n");
err = PTR_ERR(batch);
- goto end;
+ goto out_engine_pool_put;
}
err = i915_vma_pin(batch, 0, 0, PIN_USER);
- if (err) {
- drm_err(>i915->drm, "Failed to i915_vma_pin()\n");
- goto end;
- }
- is_batch_vma_pin = true;
+ if (err)
+ goto out_engine_pool_put;
rq = intel_context_create_request(ce);
if (IS_ERR(rq)) {
- drm_err(>i915->drm, "Failed to
intel_context_create_request()\n");
err = PTR_ERR(rq);
- goto end;
+ goto out_vma_unpin;
}
- is_skip_req_on_err = true;
err = intel_gt_buffer_pool_mark_active(pool, rq);
- if (err) {
- drm_err(>i915->drm, "Failed to
intel_engine_pool_mark_active()\n");
- goto end;
- }
+ if (err)
+ goto out_vma_unpin;
i915_vma_lock(batch);
err = i915_request_await_object(rq, batch->obj, false);
if (!err)
err = i915_vma_move_to_active(batch, rq, 0);
i915_vma_unlock(batch);
- if (err) {
- drm_err(>i915->drm, "Failed to
i915_request_await_object()\n");
- goto end;
- }
+ if (err)
+ goto out_vma_unpin;
if (ce->engine->emit_init_breadcrumb) {
err = ce->engine->emit_init_breadcrumb(rq);
- if (err) {
- drm_err(>i915->drm, "Failed to
emit_init_breadcrumb()\n");
- goto end;
- }
+ if (err)
+ goto out_vma_unpin;
}
err =
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode
On Tue, Dec 29, 2020 at 07:22:01PM +0200, Imre Deak wrote:
> The DP PHY vswing/pre-emphasis level programming the driver does is
> related to the DPTX -> first LTTPR link segment only. Accordingly it
> should be only programmed when link training the first LTTPR and kept
> as-is when training subsequent LTTPRs and the DPRX. For these latter
> PHYs the vs/pe levels will be set in response to writing the
> DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
> TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
> The above is also described in DP Standard v2.0 under 3.6.6.1.
>
> While at it simplify and add the LTTPR that is link trained to the debug
> message in intel_dp_set_signal_levels().
>
> Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> training")
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> .../drm/i915/display/intel_dp_link_training.c | 19 +++
> .../drm/i915/display/intel_dp_link_training.h | 3 ++-
> 3 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 88a6033d6867..16c563f1a515 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6057,7 +6057,7 @@ static void intel_dp_process_phy_request(struct
> intel_dp *intel_dp,
>
> intel_dp_autotest_phy_ddi_disable(intel_dp, crtc_state);
>
> - intel_dp_set_signal_levels(intel_dp, crtc_state);
> + intel_dp_set_signal_levels(intel_dp, crtc_state, DP_PHY_DPRX);
>
> intel_dp_phy_pattern_update(intel_dp, crtc_state);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 7876e781f698..d8c6d7054d11 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -335,21 +335,24 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> }
>
> void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *crtc_state)
> + const struct intel_crtc_state *crtc_state,
> + enum drm_dp_phy dp_phy)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u8 train_set = intel_dp->train_set[0];
> + char phy_name[10];
>
> - drm_dbg_kms(_priv->drm, "Using vswing level %d%s\n",
> + drm_dbg_kms(_priv->drm, "Using vswing level %d%s, pre-emphasis
> level %d%s, at %s\n",
> train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
> - train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "");
> - drm_dbg_kms(_priv->drm, "Using pre-emphasis level %d%s\n",
> + train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "",
> (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
> DP_TRAIN_PRE_EMPHASIS_SHIFT,
> train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
> - " (max)" : "");
> + " (max)" : "",
> + intel_dp_phy_name(dp_phy, phy_name, sizeof(phy_name)));
>
> - intel_dp->set_signal_levels(intel_dp, crtc_state);
> + if (intel_dp_phy_is_downstream_of_source(intel_dp, dp_phy))
> + intel_dp->set_signal_levels(intel_dp, crtc_state);
The function name is a bit misleading now I guess since we're not
actually setting the signal levels here for the LTTPRs. But since
the debug print is here I guess we want to still call this. And as
usual I can't think of a better name for this, so I'm willing
to accept that slight inconsistency.
Reviewed-by: Ville Syrjälä
> }
>
> static bool
> @@ -359,7 +362,7 @@ intel_dp_reset_link_train(struct intel_dp *intel_dp,
> u8 dp_train_pat)
> {
> memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> - intel_dp_set_signal_levels(intel_dp, crtc_state);
> + intel_dp_set_signal_levels(intel_dp, crtc_state, dp_phy);
> return intel_dp_set_link_train(intel_dp, crtc_state, dp_phy,
> dp_train_pat);
> }
>
> @@ -373,7 +376,7 @@ intel_dp_update_link_train(struct intel_dp *intel_dp,
> DP_TRAINING_LANE0_SET_PHY_REPEATER(dp_phy);
> int ret;
>
> - intel_dp_set_signal_levels(intel_dp, crtc_state);
> + intel_dp_set_signal_levels(intel_dp, crtc_state, dp_phy);
>
> ret = drm_dp_dpcd_write(_dp->aux, reg,
> intel_dp->train_set, crtc_state->lane_count);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index c3110c032bc2..6a1f76bd8c75 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -18,7 +18,8 @@
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c
On Tue, Dec 29, 2020 at 07:22:00PM +0200, Imre Deak wrote:
> intel_dp_set_signal_levels() is needed for link training, so move it to
> intel_dp_link_training.c.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c| 18 --
> drivers/gpu/drm/i915/display/intel_dp.h| 3 ---
> .../drm/i915/display/intel_dp_link_training.c | 18 ++
> .../drm/i915/display/intel_dp_link_training.h | 2 ++
> 4 files changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f0e8aaac413c..88a6033d6867 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5003,24 +5003,6 @@ ivb_cpu_edp_set_signal_levels(struct intel_dp
> *intel_dp,
> intel_de_posting_read(dev_priv, intel_dp->output_reg);
> }
>
> -void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *crtc_state)
> -{
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - u8 train_set = intel_dp->train_set[0];
> -
> - drm_dbg_kms(_priv->drm, "Using vswing level %d%s\n",
> - train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
> - train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "");
> - drm_dbg_kms(_priv->drm, "Using pre-emphasis level %d%s\n",
> - (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
> - DP_TRAIN_PRE_EMPHASIS_SHIFT,
> - train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
> - " (max)" : "");
> -
> - intel_dp->set_signal_levels(intel_dp, crtc_state);
> -}
> -
> void
> intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
> const struct intel_crtc_state
> *crtc_state,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 4280a09fd8fd..4ebda4e43003 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -96,9 +96,6 @@ void
> intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
> const struct intel_crtc_state
> *crtc_state,
> u8 dp_train_pat);
> -void
> -intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> -const struct intel_crtc_state *crtc_state);
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
> u8 *link_bw, u8 *rate_select);
> bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 91d3979902d0..7876e781f698 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -334,6 +334,24 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> return drm_dp_dpcd_write(_dp->aux, reg, buf, len) == len;
> }
>
> +void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state)
Can't it be static now? Hmm, apparently not due to the ad-hoc phy test
code. Oh well.
Reviewed-by: Ville Syrjälä
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + u8 train_set = intel_dp->train_set[0];
> +
> + drm_dbg_kms(_priv->drm, "Using vswing level %d%s\n",
> + train_set & DP_TRAIN_VOLTAGE_SWING_MASK,
> + train_set & DP_TRAIN_MAX_SWING_REACHED ? " (max)" : "");
> + drm_dbg_kms(_priv->drm, "Using pre-emphasis level %d%s\n",
> + (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) >>
> + DP_TRAIN_PRE_EMPHASIS_SHIFT,
> + train_set & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ?
> + " (max)" : "");
> +
> + intel_dp->set_signal_levels(intel_dp, crtc_state);
> +}
> +
> static bool
> intel_dp_reset_link_train(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index 86905aa24db7..c3110c032bc2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -17,6 +17,8 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state,
> enum drm_dp_phy dp_phy,
> const u8 link_status[DP_LINK_STATUS_SIZE]);
> +void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state);
> void intel_dp_start_link_train(struct intel_dp *intel_dp,
>
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST
Anshuman, please review.
BR,
Jani.
On Wed, 06 Jan 2021, Sean Paul wrote:
> From: Sean Paul
>
> The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
> check, it was always a nice-to-have. After deploying this across various
> devices, we've determined that some MST bridge chips do not properly
> support this call for HDCP 1.4 (namely Synaptics and Realtek).
>
> I had considered creating a quirk for this, but I think it's more
> prudent to just disable the check entirely since I don't have an idea
> how widespread support is.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 26 +---
> 1 file changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 03424d20e9f7..b6a9606bf09a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -640,30 +640,6 @@ intel_dp_mst_hdcp_toggle_signalling(struct
> intel_digital_port *dig_port,
> return ret;
> }
>
> -static
> -bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> - struct intel_connector *connector)
> -{
> - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - struct intel_dp *intel_dp = _port->dp;
> - struct drm_dp_query_stream_enc_status_ack_reply reply;
> - int ret;
> -
> - if (!intel_dp_hdcp_check_link(dig_port, connector))
> - return false;
> -
> - ret = drm_dp_send_query_stream_enc_status(_dp->mst_mgr,
> - connector->port, );
> - if (ret) {
> - drm_dbg_kms(>drm,
> - "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> - connector->base.base.id, connector->base.name, ret);
> - return false;
> - }
> -
> - return reply.auth_completed && reply.encryption_enabled;
> -}
> -
> static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> .read_bksv = intel_dp_hdcp_read_bksv,
> @@ -674,7 +650,7 @@ static const struct intel_hdcp_shim
> intel_dp_mst_hdcp_shim = {
> .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
> .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
> .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
> - .check_link = intel_dp_mst_hdcp_check_link,
> + .check_link = intel_dp_hdcp_check_link,
> .hdcp_capable = intel_dp_hdcp_capable,
>
> .protocol = HDCP_PROTOCOL_DP,
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave and Daniel,
A very short collection of patches, mostly with display fixes. Plus GVT.
The goal is to get both drm-intel-next and drm-intel-gt-next in sync again
through drm-next backports so we can continue with ADL enabling in a topic
branch.
Please be aware that there's a drm only patch here:
commit 7d8ac172d7f1 ("drm: Add function to convert rect in 16.16 fixed format
to regular format")
Here goes drm-intel-next-2021-01-12:
- PSR fixes and improvements for selective fetch (Jose)
- GVT build fixed and cleanup (Jani)
- RKL display fixes (Lee, Matt)
- DSI fix (Hans)
- Panel Power and Backlight fixes (Anshuman, Jani)
- RPM fix (Chris)
- Fix HTI port checking (Jose)
- Clean-up in cursor code (Ville)
- Once again, trying to use fast+narrow link on eDP (Ville)
- DG1 display fix (Matt)
Thanks,
Rodrigo.
The following changes since commit cb3cfbf79aff7decb4e5ee69a7c74864497f61dc:
Merge tag 'drm-misc-next-2021-01-06' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-01-07 13:40:20
+0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-01-12
for you to fetch changes up to cce73665eae238791f4342b29ca54188227717c8:
drm/i915/dg1: Update voltage swing tables for DP (2021-01-11 19:20:18 -0800)
- PSR fixes and improvements for selective fetch (Jose)
- GVT build fixed and cleanup (Jani)
- RKL display fixes (Lee, Matt)
- DSI fix (Hans)
- Panel Power and Backlight fixes (Anshuman, Jani)
- RPM fix (Chris)
- Fix HTI port checking (Jose)
- Clean-up in cursor code (Ville)
- Once again, trying to use fast+narrow link on eDP (Ville)
- DG1 display fix (Matt)
Anshuman Gupta (1):
drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}
Chris Wilson (1):
drm/i915: Disable RPM wakeref assertions during driver shutdown
Hans de Goede (1):
drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there
is no reset-deassert MIPI-sequence
Jani Nikula (10):
drm/i915/gvt: avoid useless use of inline
drm/i915/gvt: make execlist.h self-contained
drm/i915/gvt: make fb_decoder.h self-contained
drm/i915/gvt: make gtt.h self-contained
drm/i915/gvt: make interrupt.h self-contained
drm/i915/gvt: make mmio_context.h self-contained
drm/i915/gvt: make gvt.h self-contained
drm/i915/gvt: make scheduler.h self-contained
drm/i915/gvt: make mpt.h self-contained
drm/i915/backlight: fix CPU mode backlight takeover on LPT
José Roberto de Souza (5):
drm: Add function to convert rect in 16.16 fixed format to regular format
drm/i915/display/psr: Use plane damage clips to calculate damaged area
drm/i915/display: Split and export main surface calculation from
skl_check_main_surface()
drm/i915/display/psr: Program plane's calculated offset to plane SF
register
drm/i915: Fix HTI port checking
Lee Shawn C (1):
drm/i915/rkl: new rkl ddc map for different PCH
Matt Roper (2):
drm/i915/rkl: Add DP vswing programming tables
drm/i915/dg1: Update voltage swing tables for DP
Rodrigo Vivi (2):
Merge tag 'gvt-next-fixes-2020-12-25' of
https://github.com/intel/gvt-linux into drm-intel-next
Merge drm/drm-next into drm-intel-next
Ville Syrjälä (2):
drm/i915: Fix checkpatch warns in cursor code
drm/i915: Try to use fast+narrow link on eDP again and fall back to the
old max strategy on failure
drivers/gpu/drm/i915/Makefile | 10 +-
drivers/gpu/drm/i915/display/intel_bios.c | 10 ++
drivers/gpu/drm/i915/display/intel_cursor.c| 6 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 79 -
drivers/gpu/drm/i915/display/intel_display.c | 78 -
drivers/gpu/drm/i915/display/intel_display.h | 2 +
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c| 83 +++---
drivers/gpu/drm/i915/display/intel_panel.c | 9 +-
drivers/gpu/drm/i915/display/intel_psr.c | 127 ++---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +
drivers/gpu/drm/i915/display/vlv_dsi.c | 16 ++-
drivers/gpu/drm/i915/gvt/execlist.h| 3 -
drivers/gpu/drm/i915/gvt/fb_decoder.h | 6 +-
drivers/gpu/drm/i915/gvt/gtt.h | 11 +-
drivers/gpu/drm/i915/gvt/gvt.h | 4 +
drivers/gpu/drm/i915/gvt/handlers.c| 3 +-
drivers/gpu/drm/i915/gvt/interrupt.h | 5 +-
drivers/gpu/drm/i915/gvt/mmio_context.h| 11 ++
drivers/gpu/drm/i915/gvt/mpt.h | 2 +
drivers/gpu/drm/i915/gvt/scheduler.h | 5 +
drivers/gpu/drm/i915/i915_drv.c| 4 +
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Tue, 12 Jan 2021, "Vivi, Rodrigo" wrote: > On Mon, 2021-01-11 at 13:25 -0800, Lucas De Marchi wrote: >> last time we talked about this was regarding dg1 AFAIR and the >> consensus was to create a topic branch and that topic branch to be >> merged in both branches. That would avoid having 2 commits in >> different branches. > > Yeap, I believe this is the way to go. > >> >> Not sure if it would work out nicely for getting test on CI though. > > create an empty topic branch using dim. > > Pre-merge CI with drm-tip. Only if passing and if everything is realy > ready. Push to the topic branch using dim. > > Then it will be part of drm-tip already for any subsequential pre-merge > CI... > > Then do the pull requests to bot drm-intel-next and drm-intel-gt-next. > > After everything is pulled to both places, then delete the topic > branch. Atm the problem is this: $ git merge-base drm-intel/drm-intel-next drm-intel/drm-intel-gt-next That would be the baseline for the topic branch. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, 2021-01-11 at 13:25 -0800, Lucas De Marchi wrote: > On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote: > > On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: > > > On Mon, 11 Jan 2021, Jani Nikula > > > wrote: > > > > On Fri, 08 Jan 2021, Matt Roper > > > > wrote: > > > > > On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup > > > > > wrote: > > > > > > TGL adds another level of indirection for applying WA based > > > > > > on stepping > > > > > > information rather than PCI REVID. So change TGL_REVID enum > > > > > > into > > > > > > stepping enum and use PCI REVID as index into revid to > > > > > > stepping table to > > > > > > fetch correct display and GT stepping for application of > > > > > > WAs as > > > > > > suggested by Matt Roper. > > > > > > > > > > So to clarify the goal is to rename "revid" -> "stepping" > > > > > because the > > > > > values like "A1," "C0," etc. are't the actual PCI revision > > > > > ID, but > > > > > rather descriptions of the stepping of a given IP block; the > > > > > enum values > > > > > we use to represent those are arbitrary and don't matter as > > > > > long as > > > > > they're monotonically increasing for comparisons. The PCI > > > > > revision ID > > > > > is just the input we use today to deduce what the IP > > > > > steppings are, and > > > > > there's talk that we could determine the IP steppings in a > > > > > different way > > > > > at some point in the future. > > > > > > > > > > Furthermore, since the same scheme will be used at least for > > > > > ADL-S, we > > > > > should drop the "TGL" prefix since there's no need to name > > > > > these general > > > > > enum values in a platform-specific manner. > > > > > > > > > > Reviewed-by: Matt Roper > > > > > > > > > > We should probably make the same kind of change to KBL (and > > > > > use the same > > > > > stepping enum) too since it has the same kind of extra > > > > > indirection as > > > > > TGL/ADL-S, but we can do that as a followup patch. > > > > > > > > FWIW I have a wip series changing the whole thing to abstract > > > > steppings > > > > enums that are shared between platforms, but it's in a bit of > > > > limbo > > > > because the previous revid changes were applied to drm-intel- > > > > gt-next, > > > > and it's fallen pretty far out of sync with drm-intel-next. All > > > > of this > > > > really belongs to drm-intel-next, but can't do that until the > > > > branches > > > > sync up again. > > > > > > Btw this series doesn't apply to drm-intel-next either, for the > > > same > > > reason, and the ADL-S platform definition and PCI IDs must *not* > > > be > > > applied to drm-intel-gt-next. > > > > So to clarify, it looks like we have a bunch of revid changes to > > the > > display code that got merged to the gt-next tree but not to the > > intel-next tree? Should we be going back and also merging / > > cherry-picking those over to intel-next since that's where the > > display > > changes are supposed to go, or is it too late to do that cleanly at > > this > > point? > > it was my mistake to merge them to drm-intel-gt-next. They should > have > been in drm-intel-next. > > > > > Going forward, what should the general strategy be for stuff like > > platform definitions and such? Merge such enablement patches to > > both > > last time we talked about this was regarding dg1 AFAIR and the > consensus > was to create a topic branch and that topic branch to be merged in > both > branches. That would avoid having 2 commits in different branches. Yeap, I believe this is the way to go. > > Not sure if it would work out nicely for getting test on CI though. create an empty topic branch using dim. Pre-merge CI with drm-tip. Only if passing and if everything is realy ready. Push to the topic branch using dim. Then it will be part of drm-tip already for any subsequential pre-merge CI... Then do the pull requests to bot drm-intel-next and drm-intel-gt-next. After everything is pulled to both places, then delete the topic branch. > Since the changes are spread through the codebase, we could very > easily > hit a situation that this topic branch creates conflicts for other > patches getting merged on either drm-intel-next or drm-intel-gt-next. > > +Joonas, +Rodrigo > > Lucas De Marchi > > > intel-next and gt-next at the same time so that the basic > > definitions > > are available to both trees? It seems like the whole split into > > two > > trees really isn't working well and is just leading to more > > mistakes and > > bottlenecks. What benefit are we supposed to be getting from this > > split? > > > > > > Matt > > > > > > > > > > BR, > > > Jani. > > > > > > > > > > > My series also completely hides the arrays into a separate .c > > > > file, > > > > because the externs with direct array access are turning into > > > > nightmare. The ARRAY_SIZE() checks rely on the extern > > > > declaration and > > > > the actual array definition to have the
Re: [Intel-gfx] [PATCH] drm/i915/lmem: make intel_region_lmem_ops static
On Tue, 12 Jan 2021 at 17:23, Jani Nikula wrote: > > There are no users outside of intel_region_lmem.c. > > Signed-off-by: Jani Nikula Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move region_lmem under gt
== Series Details == Series: drm/i915: move region_lmem under gt URL : https://patchwork.freedesktop.org/series/85760/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9594 -> Patchwork_19325 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19325 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19325, 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_19325/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19325: ### IGT changes ### Possible regressions * igt@i915_selftest@live@blt: - fi-snb-2520m: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-snb-2520m/igt@i915_selftest@l...@blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-snb-2520m/igt@i915_selftest@l...@blt.html Known issues Here are the changes found in Patchwork_19325 that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_pread_basic: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-tgl-y/igt@gem_tiled_pread_basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-tgl-y/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@gt_heartbeat: - fi-icl-u2: [PASS][5] -> [DMESG-FAIL][6] ([i915#2291] / [i915#2601] / [i915#541]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-icl-u2/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-icl-u2/igt@i915_selftest@live@gt_heartbeat.html - fi-bsw-kefka: [PASS][7] -> [DMESG-FAIL][8] ([i915#2675] / [i915#541]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@sanitycheck: - fi-kbl-7500u: [PASS][9] -> [DMESG-WARN][10] ([i915#2605]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html * igt@runner@aborted: - fi-kbl-r: NOTRUN -> [FAIL][11] ([i915#1569] / [i915#192] / [i915#193] / [i915#194] / [i915#2295]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-kbl-r/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [DMESG-WARN][12] ([i915#402]) -> [PASS][13] +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569 [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192 [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193 [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295 [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601 [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605 [i915#2675]: https://gitlab.freedesktop.org/drm/intel/issues/2675 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9594 -> Patchwork_19325 CI-20190529: 20190529 CI_DRM_9594: 7ede24331ccbd4f8cce2b2e73b63bd49dc181560 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5956: d9bc7773043d11d37ae5b03bf18979541a9c7ef4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19325: b7c79e86103ed99a70f13bcc6f9e75f4681ce956 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b7c79e86103e drm/i915: move region_lmem under gt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19325/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH] drm/i915/lmem: make intel_region_lmem_ops static
There are no users outside of intel_region_lmem.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_region_lmem.c | 2 +-
drivers/gpu/drm/i915/intel_region_lmem.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
index 40d8f1a95df6..83992312a34b 100644
--- a/drivers/gpu/drm/i915/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/intel_region_lmem.c
@@ -95,7 +95,7 @@ region_lmem_init(struct intel_memory_region *mem)
return ret;
}
-const struct intel_memory_region_ops intel_region_lmem_ops = {
+static const struct intel_memory_region_ops intel_region_lmem_ops = {
.init = region_lmem_init,
.release = region_lmem_release,
.create_object = __i915_gem_lmem_object_create,
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.h
b/drivers/gpu/drm/i915/intel_region_lmem.h
index 213def7c7b8a..8ea43e538dab 100644
--- a/drivers/gpu/drm/i915/intel_region_lmem.h
+++ b/drivers/gpu/drm/i915/intel_region_lmem.h
@@ -8,8 +8,6 @@
struct drm_i915_private;
-extern const struct intel_memory_region_ops intel_region_lmem_ops;
-
struct intel_memory_region *
intel_setup_fake_lmem(struct drm_i915_private *i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Tue, Jan 12, 2021 at 06:24:50PM +0200, Jani Nikula wrote: > On Mon, 11 Jan 2021, Lucas De Marchi wrote: > > On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote: > >>On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: > >>So to clarify, it looks like we have a bunch of revid changes to the > >>display code that got merged to the gt-next tree but not to the > >>intel-next tree? Should we be going back and also merging / > >>cherry-picking those over to intel-next since that's where the display > >>changes are supposed to go, or is it too late to do that cleanly at this > >>point? > > > > it was my mistake to merge them to drm-intel-gt-next. They should have > > been in drm-intel-next. > > That's not the problem though. The branches generally being too far > apart atm is. The single cherry-pick won't solve that. Applying these > patches to one tree just adds a dependency that will not be around in > the topic branch baseline, creating a new problem for merging the topic > branch. I still don't understand what the original goal of splitting the driver into two different trees was. It's clear that this approach is going to cause extra mistakes and bugs if we continue down this path and it's not clear to me what the expected benefit was to justify the additional complexity? When are the two branches supposed to be brought back in sync? Is it just a single backmerge to each branch immediately after new mainline kernel releases or is there some other strategy to handle this? Matt > > >>Going forward, what should the general strategy be for stuff like > >>platform definitions and such? Merge such enablement patches to both > > > > last time we talked about this was regarding dg1 AFAIR and the consensus > > was to create a topic branch and that topic branch to be merged in both > > branches. That would avoid having 2 commits in different branches. > > Agreed. > > > Not sure if it would work out nicely for getting test on CI though. > > Since the changes are spread through the codebase, we could very easily > > hit a situation that this topic branch creates conflicts for other > > patches getting merged on either drm-intel-next or drm-intel-gt-next. > > The cycle in review -> apply to topic branch -> merge topic branch just > needs to be short enough. We can't have the topic branch laying around > for more than maybe a few days, or we'll have problems. > > > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Graphics Center -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/region: make intel_region_map static
On Tue, 12 Jan 2021 at 17:05, Jani Nikula wrote: > > There are no users outside of intel_memory_region.c. > > Signed-off-by: Jani Nikula Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Force a failed engine reset
Chris Wilson writes:
> Inject a fault into the engine reset and check that the outstanding
> requests are completed despite the failed reset.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 133 +++
> 1 file changed, 133 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> index ffc6eabb6404..875633cc0a75 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> @@ -540,6 +540,138 @@ static int igt_reset_nop_engine(void *arg)
> return 0;
> }
>
> +static void force_reset_timeout(struct intel_engine_cs *engine)
> +{
> + engine->reset_timeout.probability = 999;
> + atomic_set(>reset_timeout.times, -1);
> +}
> +
> +static void cancel_reset_timeout(struct intel_engine_cs *engine)
> +{
> + memset(>reset_timeout, 0, sizeof(engine->reset_timeout));
> +}
> +
> +static int igt_reset_fail_engine(void *arg)
> +{
> + struct intel_gt *gt = arg;
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + /* Check that we can engine-reset during non-user portions */
> +
> + if (!intel_has_reset_engine(gt))
> + return 0;
> +
> + for_each_engine(engine, gt, id) {
> + unsigned int count;
> + struct intel_context *ce;
> + IGT_TIMEOUT(end_time);
> + int err;
> +
> + ce = intel_context_create(engine);
> + if (IS_ERR(ce))
> + return PTR_ERR(ce);
> +
> + st_engine_heartbeat_disable(engine);
> + set_bit(I915_RESET_ENGINE + id, >reset.flags);
> + count = 0;
> + do {
> + struct i915_request *last = NULL;
> + int i;
> +
> + if (!wait_for_idle(engine)) {
> + pr_err("%s failed to idle before reset\n",
> +engine->name);
> + err = -EIO;
> + break;
> + }
> +
> + for (i = 0; i < 16; i++) {
> + struct i915_request *rq;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq)) {
> + struct drm_printer p =
> +
> drm_info_printer(gt->i915->drm.dev);
> + intel_engine_dump(engine, ,
> + "%s(%s): failed to
> submit request\n",
> + __func__,
> + engine->name);
> +
> + GEM_TRACE("%s(%s): failed to submit
> request\n",
> + __func__,
> + engine->name);
> + GEM_TRACE_DUMP();
> +
> + intel_gt_set_wedged(gt);
> + if (last)
> + i915_request_put(last);
> +
> + err = PTR_ERR(rq);
> + goto out;
> + }
> +
> + if (last)
> + i915_request_put(last);
> + last = i915_request_get(rq);
> + i915_request_add(rq);
> + }
> +
> + if (count & 1) {
> + err = intel_engine_reset(engine, NULL);
> + if (err) {
> + GEM_TRACE_ERR("intel_engine_reset(%s)
> failed, err:%d\n",
> + engine->name, err);
> + GEM_TRACE_DUMP();
> + break;
> + }
> + } else {
> + force_reset_timeout(engine);
> + err = intel_engine_reset(engine, NULL);
We dont promote to global here if the engine one fails?
If not, what mechanism then guarantees the request completion.
-Mika
> + cancel_reset_timeout(engine);
> + if (err != -ETIMEDOUT) {
> + pr_err("intel_engine_reset(%s) did not
> fail, err:%d\n",
> +engine->name, err);
> + break;
> + }
> + }
> +
> + err = 0;
> + if (i915_request_wait(last, 0, HZ /2) < 0) {
> +
[Intel-gfx] [PATCH] drm/i915/region: make intel_region_map static
There are no users outside of intel_memory_region.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_memory_region.c | 2 +-
drivers/gpu/drm/i915/intel_memory_region.h | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index b326993a1026..1bfcdd89b241 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -10,7 +10,7 @@
#define REGION_MAP(type, inst) \
BIT((type) + INTEL_MEMORY_TYPE_SHIFT) | BIT(inst)
-const u32 intel_region_map[] = {
+static const u32 intel_region_map[] = {
[INTEL_REGION_SMEM] = REGION_MAP(INTEL_MEMORY_SYSTEM, 0),
[INTEL_REGION_LMEM] = REGION_MAP(INTEL_MEMORY_LOCAL, 0),
[INTEL_REGION_STOLEN] = REGION_MAP(INTEL_MEMORY_STOLEN, 0),
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 232490d89a83..6590d55df6cb 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -51,11 +51,6 @@ enum intel_region_id {
for (id = 0; id < ARRAY_SIZE((i915)->mm.regions); id++) \
for_each_if((mr) = (i915)->mm.regions[id])
-/**
- * Memory regions encoded as type | instance
- */
-extern const u32 intel_region_map[];
-
struct intel_memory_region_ops {
unsigned int flags;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: move region_lmem under gt
== Series Details == Series: drm/i915: move region_lmem under gt URL : https://patchwork.freedesktop.org/series/85760/ State : warning == Summary == $ dim checkpatch origin/drm-tip b7c79e86103e drm/i915: move region_lmem under gt -:34: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #34: rename from drivers/gpu/drm/i915/intel_region_lmem.c total: 0 errors, 1 warnings, 0 checks, 28 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Force a failed engine reset
== Series Details == Series: drm/i915/selftests: Force a failed engine reset URL : https://patchwork.freedesktop.org/series/85749/ State : success == Summary == CI Bug Log - changes from CI_DRM_9590_full -> Patchwork_19323_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19323_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gen3_mixed_blits: - shard-tglb: NOTRUN -> [SKIP][3] ([fdo#109289]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb3/igt@gen3_mixed_blits.html * igt@gen9_exec_parse@batch-zero-length: - shard-tglb: NOTRUN -> [SKIP][4] ([fdo#112306]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb3/igt@gen9_exec_pa...@batch-zero-length.html * igt@i915_pm_rpm@modeset-non-lpsp-stress: - shard-tglb: NOTRUN -> [SKIP][5] ([fdo#111644] / [i915#1397] / [i915#2411]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb3/igt@i915_pm_...@modeset-non-lpsp-stress.html * igt@kms_big_fb@yf-tiled-8bpp-rotate-90: - shard-tglb: NOTRUN -> [SKIP][6] ([fdo#111615]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb3/igt@kms_big...@yf-tiled-8bpp-rotate-90.html * igt@kms_ccs@pipe-c-crc-sprite-planes-basic: - shard-skl: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111304]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-skl4/igt@kms_...@pipe-c-crc-sprite-planes-basic.html * igt@kms_chamelium@vga-hpd: - shard-skl: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +9 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-skl9/igt@kms_chamel...@vga-hpd.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-glk7/igt@kms_chamel...@vga-hpd-enable-disable-mode.html * igt@kms_color@pipe-d-ctm-0-5: - shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271]) +91 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-skl5/igt@kms_co...@pipe-d-ctm-0-5.html * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue: - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-kbl1/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html * igt@kms_color_chamelium@pipe-invalid-degamma-lut-sizes: - shard-tglb: NOTRUN -> [SKIP][12] ([fdo#109284] / [fdo#111827]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb5/igt@kms_color_chamel...@pipe-invalid-degamma-lut-sizes.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen: - shard-skl: NOTRUN -> [FAIL][15] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-64x64-onscreen.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic: - shard-skl: NOTRUN -> [FAIL][16] ([i915#2346]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html * igt@kms_flip@flip-vs-absolute-wf_vblank@a-edp1: - shard-tglb: NOTRUN -> [FAIL][17] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb3/igt@kms_flip@flip-vs-absolute-wf_vbl...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#2598]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/shard-tglb7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl:
[Intel-gfx] [PATCH] drm/i915: move region_lmem under gt
Device local-memory should be thought of as part the GT, which means it
should also sit under gt/.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/{ => gt}/intel_region_lmem.c | 0
drivers/gpu/drm/i915/{ => gt}/intel_region_lmem.h | 0
drivers/gpu/drm/i915/i915_drv.h | 2 +-
4 files changed, 2 insertions(+), 2 deletions(-)
rename drivers/gpu/drm/i915/{ => gt}/intel_region_lmem.c (100%)
rename drivers/gpu/drm/i915/{ => gt}/intel_region_lmem.h (100%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 48f82c354611..d6ac946d0407 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -110,6 +110,7 @@ gt-y += \
gt/intel_mocs.o \
gt/intel_ppgtt.o \
gt/intel_rc6.o \
+ gt/intel_region_lmem.o \
gt/intel_renderstate.o \
gt/intel_reset.o \
gt/intel_ring.o \
@@ -170,7 +171,6 @@ i915-y += \
i915_scheduler.o \
i915_trace_points.o \
i915_vma.o \
- intel_region_lmem.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
similarity index 100%
rename from drivers/gpu/drm/i915/intel_region_lmem.c
rename to drivers/gpu/drm/i915/gt/intel_region_lmem.c
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.h
b/drivers/gpu/drm/i915/gt/intel_region_lmem.h
similarity index 100%
rename from drivers/gpu/drm/i915/intel_region_lmem.h
rename to drivers/gpu/drm/i915/gt/intel_region_lmem.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a2b6ac04068..e3d58299b323 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -81,6 +81,7 @@
#include "gt/intel_engine.h"
#include "gt/intel_gt_types.h"
+#include "gt/intel_region_lmem.h"
#include "gt/intel_workarounds.h"
#include "gt/uc/intel_uc.h"
@@ -102,7 +103,6 @@
#include "i915_vma.h"
#include "i915_irq.h"
-#include "intel_region_lmem.h"
/* General customization:
*/
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, 11 Jan 2021, Aditya Swarup wrote: > On 1/11/21 12:57 PM, Matt Roper wrote: >> On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: >>> On Mon, 11 Jan 2021, Jani Nikula wrote: On Fri, 08 Jan 2021, Matt Roper wrote: > On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote: >> TGL adds another level of indirection for applying WA based on stepping >> information rather than PCI REVID. So change TGL_REVID enum into >> stepping enum and use PCI REVID as index into revid to stepping table to >> fetch correct display and GT stepping for application of WAs as >> suggested by Matt Roper. > > So to clarify the goal is to rename "revid" -> "stepping" because the > values like "A1," "C0," etc. are't the actual PCI revision ID, but > rather descriptions of the stepping of a given IP block; the enum values > we use to represent those are arbitrary and don't matter as long as > they're monotonically increasing for comparisons. The PCI revision ID > is just the input we use today to deduce what the IP steppings are, and > there's talk that we could determine the IP steppings in a different way > at some point in the future. > > Furthermore, since the same scheme will be used at least for ADL-S, we > should drop the "TGL" prefix since there's no need to name these general > enum values in a platform-specific manner. > > Reviewed-by: Matt Roper > > We should probably make the same kind of change to KBL (and use the same > stepping enum) too since it has the same kind of extra indirection as > TGL/ADL-S, but we can do that as a followup patch. FWIW I have a wip series changing the whole thing to abstract steppings enums that are shared between platforms, but it's in a bit of limbo because the previous revid changes were applied to drm-intel-gt-next, and it's fallen pretty far out of sync with drm-intel-next. All of this really belongs to drm-intel-next, but can't do that until the branches sync up again. >>> >>> Btw this series doesn't apply to drm-intel-next either, for the same >>> reason, and the ADL-S platform definition and PCI IDs must *not* be >>> applied to drm-intel-gt-next. > > The reason behind this patch not cleanly applying on drm-intel-next is because > drm/i915/tgl: Add bound checks and simplify TGL REVID macros > isn't present on that branch but present on gt-next. > > The patch doesn't apply on gt-next because of a conflict in the following > hunk: > /* Wa_1409825376:tgl (pre-prod)*/ > - if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B1)) > + if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B1)) > > which can be easily fixed during backmerge process as I was able apply the > patch > cleanly on gt-next. > I don't understand the "must *not*" reasoning behind not applying this patch > on gt-next. I think I've explained this in several replies in this thread now. > It was common consesus during initial review that separating > stepping/revid parsing in a separate .c file will be pushed in after > ADLS changes and adding this patch won't add any extra churn, just a > minor rebase for your approach. Misunderstanding I guess. I thought the required changes had already been pushed, and we weren't waiting for further changes on this. I certainly wasn't expecting the generic revid -> stepping rename at this point, as I don't think they are required for ADL-S at all. I thought the consensus was that I'll do the refactoring. Anyway, I can deal with the churn and the rebases, no problem. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, 11 Jan 2021, Lucas De Marchi wrote: > On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote: >>On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: >>So to clarify, it looks like we have a bunch of revid changes to the >>display code that got merged to the gt-next tree but not to the >>intel-next tree? Should we be going back and also merging / >>cherry-picking those over to intel-next since that's where the display >>changes are supposed to go, or is it too late to do that cleanly at this >>point? > > it was my mistake to merge them to drm-intel-gt-next. They should have > been in drm-intel-next. That's not the problem though. The branches generally being too far apart atm is. The single cherry-pick won't solve that. Applying these patches to one tree just adds a dependency that will not be around in the topic branch baseline, creating a new problem for merging the topic branch. >>Going forward, what should the general strategy be for stuff like >>platform definitions and such? Merge such enablement patches to both > > last time we talked about this was regarding dg1 AFAIR and the consensus > was to create a topic branch and that topic branch to be merged in both > branches. That would avoid having 2 commits in different branches. Agreed. > Not sure if it would work out nicely for getting test on CI though. > Since the changes are spread through the codebase, we could very easily > hit a situation that this topic branch creates conflicts for other > patches getting merged on either drm-intel-next or drm-intel-gt-next. The cycle in review -> apply to topic branch -> merge topic branch just needs to be short enough. We can't have the topic branch laying around for more than maybe a few days, or we'll have problems. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, 11 Jan 2021, Lucas De Marchi wrote: > On Mon, Jan 11, 2021 at 10:13:15PM +0200, Jani Nikula wrote: >>On Fri, 08 Jan 2021, Matt Roper wrote: > in the end both sides will need that (even if it was a mistake to merge > it in drm-intel-gt-next). I got an ack from Rodrigo to actually > cherry-pick the single patch we are missing so this can unblock both > merging this patch (after rebasing) and you can continue your series. cherry-picking the one patch is not enough. The -next branches are too far apart to start applying ADL-S patches in either branch. Doing so will lead to way too bad merge conflicts. Which just means the cherry-pick won't help, as you'll need a topic branch with a sensible baseline to merge the ADL-S support to both branches. Now the merge-base is too far away. >>My series also completely hides the arrays into a separate .c file, >>because the externs with direct array access are turning into >>nightmare. The ARRAY_SIZE() checks rely on the extern declaration and >>the actual array definition to have the sizes in sync, but the compiler >>does not check that. Really. > > not following what the ARRAY_SIZE is not checking. It actually is, since > the declaration is explicitly telling the size of the array. If the > definition had more items, you'd get a compilation error. Mmmh, I tested this, but can't reproduce now. Never mind. *shrug*. >>IDK, feels like this merging this series is going to be extra churn. > > I'm not against the refactor you're talking about, but this seems an > improvement to unblock the ADL-S patches that are pending. The patches > could also be split to remove this dependency, but I'm not sure it's > worth it. Please let's first get the branches back in sync, and then create a topic branch for ADL-S, and merge it to both. Everything else will lead to tears. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs : PM_REQ and PM_RES registers (rev2)
== Series Details == Series: drm/i915/debugfs : PM_REQ and PM_RES registers (rev2) URL : https://patchwork.freedesktop.org/series/85437/ State : success == Summary == CI Bug Log - changes from CI_DRM_9594 -> Patchwork_19324 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/index.html Known issues Here are the changes found in Patchwork_19324 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-kbl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#262]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-kbl-guc/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-kbl-guc/igt@debugfs_test@read_all_entries.html - fi-kbl-8809g: [PASS][3] -> [DMESG-WARN][4] ([i915#262]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html * igt@i915_selftest@live@gt_heartbeat: - fi-tgl-y: [PASS][5] -> [DMESG-FAIL][6] ([i915#2601]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-tgl-y/igt@prime_v...@basic-fence-flip.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][9] ([i915#2029]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-bdw-5557u/igt@run...@aborted.html - fi-kbl-guc: NOTRUN -> [FAIL][10] ([i915#1814] / [i915#2295]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-kbl-guc/igt@run...@aborted.html Possible fixes * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html Warnings * igt@runner@aborted: - fi-kbl-8809g: [FAIL][13] ([i915#2295]) -> [FAIL][14] ([i915#1814] / [i915#2295]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9594/fi-kbl-8809g/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/fi-kbl-8809g/igt@run...@aborted.html [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295 [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9594 -> Patchwork_19324 CI-20190529: 20190529 CI_DRM_9594: 7ede24331ccbd4f8cce2b2e73b63bd49dc181560 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5956: d9bc7773043d11d37ae5b03bf18979541a9c7ef4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19324: 6236e1aa792e8d221d2492f665abaef1c1431dd6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6236e1aa792e drm/i915/debugfs : PM_REQ and PM_RES registers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19324/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl: Use TGL stepping info for applying WAs
On Mon, 11 Jan 2021, Aditya Swarup wrote: > On 1/11/21 12:13 PM, Jani Nikula wrote: >> On Fri, 08 Jan 2021, Matt Roper wrote: >> FWIW I have a wip series changing the whole thing to abstract steppings >> enums that are shared between platforms, but it's in a bit of limbo >> because the previous revid changes were applied to drm-intel-gt-next, >> and it's fallen pretty far out of sync with drm-intel-next. All of this >> really belongs to drm-intel-next, but can't do that until the branches >> sync up again. >> >> My series also completely hides the arrays into a separate .c file, >> because the externs with direct array access are turning into >> nightmare. The ARRAY_SIZE() checks rely on the extern declaration and >> the actual array definition to have the sizes in sync, but the compiler >> does not check that. Really. >> >> IDK, feels like this merging this series is going to be extra churn. > > We need ADLS support on drm-tip by WW05 and I don't think this should change > anything > as far as rebase is concerned as it will be just deletion of this entire > section to move > into the separate stepping/revid file in your implementation. Fine, let's take the churn, no big deal. However, I think you'll find drm-intel-next and drm-intel-gt-next are currently too far from each other to even have a sensible topic branch baseline: $ git merge-base drm-intel/drm-intel-next drm-intel/drm-intel-gt-next 31b05212360cbf3af3c2e1b7f42e176e0eebedb5 Even if you do the minimal cherry-pick to drm-intel-next to be able to apply this series, you'll still end up with really bad merge trouble to get the platform support back to drm-intel-gt-next, and I presume that's what you'll need. And that means a topic branch. And that means: 1) New drm-intel-gt-next pull request 2) Have that merged to drm-next 3) Have drm-next backmerged to drm-intel-next to have a sensible baseline. > I think as a stop gap and to achieve the goal of ADLS patches being pushed > in, these patches > look good enough. If extern/array declaration was a concern, why were the > KBL/TGL pathces accepted > in the first place? Really, they should not have been. It's just poor design, and difficult to maintain long term. Data is not an interface. The driver is too big to bypass abstractions for this. See this: $ git grep -w extern -- drivers/gpu/drm/i915 > I will be happy to help with the rebase but the process of pushing > ADLS patches is stuck because of this. It's stuck because our -next branches are too far apart. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time
On Tue, 12 Jan 2021, "Vivi, Rodrigo" wrote: > On Mon, 2021-01-11 at 21:38 +, Huang, Sean Z wrote: >> Hello, >> >> I see, based on Joonas and Rodrigo's feedback. >> >> I made the modification as below, I will still keep the macro in this >> .c instead of i915_reg.h, and this change will be reflected in rev20. >> >> /* KCR register definitions */ >> #define KCR_INIT _MMIO(0x320f0) >> -#define KCR_INIT_MASK_SHIFT (16) Useless parenthesis. >> + >> /* Setting KCR Init bit is required after system boot */ >> -#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << >> KCR_INIT_MASK_SHIFT)) >> +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << 16)) BIT(14) << 16 is actually BIT(14+16), or BIT(30). The above is pointless. Also, you'll end up with problems by using BIT() instead of REG_BIT() defined in i915_reg.h due to BIT() using unsigned long. Also, read the big style comment near the top of i915_reg.h. BR, Jani. > > This is not what I asked actually. > > I asked to get the BIT(14) to be defined separated, shift defined as > well... and the | and actuall shift operations to be performed in the > code and not in the defines > >> >> Best regards, >> Sean >> >> -Original Message- >> From: Joonas Lahtinen >> Sent: Friday, January 8, 2021 3:31 AM >> To: Huang, Sean Z ; >> Intel-gfx@lists.freedesktop.org; Vivi, Rodrigo < >> rodrigo.v...@intel.com> >> Subject: Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg >> init during the boot time >> >> Quoting Vivi, Rodrigo (2021-01-07 17:31:36) >> > On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote: >> > > Set the KCR init during the boot time, which is required by >> > > hardware, to allow us doing further protection operation such as >> > > sending commands to GPU or TEE. >> > > >> > > Signed-off-by: Huang, Sean Z >> > > --- >> > > drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 >> > > 1 file changed, 8 insertions(+) >> > > >> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c >> > > b/drivers/gpu/drm/i915/pxp/intel_pxp.c >> > > index 9bc3c7e30654..f566a4fda044 100644 >> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c >> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c >> > > @@ -6,6 +6,12 @@ >> > > #include "intel_pxp.h" >> > > #include "intel_pxp_context.h" >> > > >> > > +/* KCR register definitions */ >> > >> > please define this in i915_reg.h >> >> Generally the trend on the GT side is to contain in a .c file if >> there are no shared users like these. So they should be at this spot, >> yet the rest of the review comments apply. >> >> The spurious comments should be dropped and like Rodrigo pointed out, >> we should be using the appropriate macros for a masked writes, not >> baking in the #define. >> >> Regards, Joonas > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/debugfs : PM_REQ and PM_RES registers
> -Original Message-
> From: S, Saichandana
> Sent: Tuesday, January 12, 2021 7:04 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Gupta, Anshuman
> ; S, Saichandana
> Subject: [PATCH v3] drm/i915/debugfs : PM_REQ and PM_RES registers
>
> PM_REQ register provides the value of the last PM request[Gupta, Anshuman] ,
> response from PCU to
*PM_DBG_{REQ,RSP}*
> Display Engine. PM_RES register provides the value of the last PM response
> from Display Engine to PCU.
> This debugfs will be used by DC9 IGT test to know about "DC9 Ready"
I would rephrase it as "This debugs DC9 Ready but will be used by dc9 igt test .
It will also print the useful debug information from Display Engine to PCU
mailbox register"
> status.
> B.Spec : 49501, 49502
>
> V2:
> Added a functional print to debugfs. [Jani Nikula]
>
> V3:
> Used separate variables to store the register values and also used
> REG_GENMASK and REG_BIT for mask preparation. [Anshuman Gupta]
>
> Removed reading of register contents. Replaced local variable with yesno().
> Placed register macros separately, distinguishing from other macros. [Jani
> Nikula]
>
> Signed-off-by: Saichandana S
> ---
> .../drm/i915/display/intel_display_debugfs.c | 23
> +++
> drivers/gpu/drm/i915/i915_reg.h | 10
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index cd7e5519ee7d..e5997debb8e5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -559,6 +559,28 @@ static int i915_dmc_info(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int i915_pm_req_res_info(struct seq_file *m, void *unused) {
> + struct drm_i915_private *dev_priv = node_to_i915(m->private);
Please use i915 as variable as Jani has suggested earlier.
Thanks,
Anshuman.
> + struct intel_csr *csr = _priv->csr;
> + u32 DC9_status;
> +
> + if (!HAS_CSR(dev_priv))
> + return -ENODEV;
> + if (!csr->dmc_payload)
> + return 0;
> + DC9_status = intel_de_read(dev_priv, PM_RSP_DBG_1) &
> +PM_RESP_DC9_READY;
> +
> + seq_printf(m, "Time to Next Fill : 0x%08x\n",
> +intel_de_read(dev_priv, PM_RSP_DBG_0) &
> PM_RESP_TTNF_MASK);
> + seq_printf(m, "Time to Next VBI : 0x%08x\n",
> +(intel_de_read(dev_priv, PM_RSP_DBG_0) &
> PM_RESP_TTNVBI_MASK) >> 16);
> + seq_printf(m, "Selective Exit Latency : 0x%08x\n",
> +intel_de_read(dev_priv, PM_RSP_DBG_1) &
> PM_RESP_SEL_EXIT_LATENCY_MASK);
> + seq_printf(m, "DC9 Ready : %s\n", yesno(DC9_status));
> + return 0;
> +}
> +
> static void intel_seq_print_mode(struct seq_file *m, int tabs,
>const struct drm_display_mode *mode) {
> @@ -2100,6 +2122,7 @@ static const struct drm_info_list
> intel_display_debugfs_list[] = {
> {"i915_edp_psr_status", i915_edp_psr_status, 0},
> {"i915_power_domain_info", i915_power_domain_info, 0},
> {"i915_dmc_info", i915_dmc_info, 0},
> + {"i915_pm_req_res_info", i915_pm_req_res_info, 0},
> {"i915_display_info", i915_display_info, 0},
> {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
> {"i915_dp_mst_info", i915_dp_mst_info, 0}, diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0023c023f472..8c91d598dc29 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -12423,4 +12423,14 @@ enum skl_power_gate {
> #define TGL_ROOT_DEVICE_SKU_ULX 0x2
> #define TGL_ROOT_DEVICE_SKU_ULT 0x4
>
> +/*These registers are of functional registers for PM debug request and
> response registers*/
> +#define PM_REQ_DBG_0 _MMIO(0x45284)
> +#define PM_REQ_DBG_1 _MMIO(0x45288)
> +#define PM_RSP_DBG_0 _MMIO(0x4528C)
> +#define PM_RESP_TTNF_MASK REG_GENMASK(15,
> 0)
> +#define PM_RESP_TTNVBI_MASKREG_GENMASK(31,
> 16)
> +#define PM_RSP_DBG_1 _MMIO(0x45290)
> +#define PM_RESP_SEL_EXIT_LATENCY_MASK
> REG_GENMASK(2, 0)
> +#define PM_RESP_DC9_READY REG_BIT(15)
> +
> #endif /* _I915_REG_H_ */
> --
> 2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 098/162] drm/i915/gtt: map the PD up front
On Tue, Jan 12, 2021 at 10:47:57AM +, Matthew Auld wrote: > On Fri, 27 Nov 2020 at 13:32, Chris Wilson wrote: > > > > Quoting Matthew Auld (2020-11-27 12:06:14) > > > We need to general our accessor for the page directories and tables from > > > using the simple kmap_atomic to support local memory, and this setup > > > must be done on acquisition of the backing storage prior to entering > > > fence execution contexts. Here we replace the kmap with the object > > > maping code that for simple single page shmemfs object will return a > > > plain kmap, that is then kept for the lifetime of the page directory. > > > > > > Signed-off-by: Matthew Auld > > > Signed-off-by: Chris Wilson > > > > We are going to really struggle with this on 32b :( > > Just go back to mapping everything on demand like we did previously, > and unmap as soon as we are done with the current directory across > alloc/insert/clear? tbh if you run i915.ko on 32b kernels, on a modern platform, you deserve all the pain you get. There's quite a bit of work going on to essentially make kmap functions worse on 32b (we're not yet at the stage where people propose to nuke them, but getting there slowly), so designing code today with them in mind as primary justification is backwards. What we can't do is keep kmap around forever, it'd need to be something like vmap that has a long-term mapping intention behind it. And at that point it's probably equally amounts of work to just go back to ad-hoc kmap. Also the rules have changed somewhat with kmap_local anyway, a kmap is a lot less painful in the code than it was with kmap_atomic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/debugfs : PM_REQ and PM_RES registers
PM_REQ register provides the value of the last PM request from PCU to
Display Engine. PM_RES register provides the value of the last PM
response from Display Engine to PCU.
This debugfs will be used by DC9 IGT test to know about "DC9 Ready"
status.
B.Spec : 49501, 49502
V2:
Added a functional print to debugfs. [Jani Nikula]
V3:
Used separate variables to store the register values and
also used REG_GENMASK and REG_BIT for mask preparation. [Anshuman Gupta]
Removed reading of register contents. Replaced local variable
with yesno(). Placed register macros separately, distinguishing from
other macros. [Jani Nikula]
Signed-off-by: Saichandana S
---
.../drm/i915/display/intel_display_debugfs.c | 23 +++
drivers/gpu/drm/i915/i915_reg.h | 10
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index cd7e5519ee7d..e5997debb8e5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -559,6 +559,28 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
return 0;
}
+static int i915_pm_req_res_info(struct seq_file *m, void *unused)
+{
+ struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ struct intel_csr *csr = _priv->csr;
+ u32 DC9_status;
+
+ if (!HAS_CSR(dev_priv))
+ return -ENODEV;
+ if (!csr->dmc_payload)
+ return 0;
+ DC9_status = intel_de_read(dev_priv, PM_RSP_DBG_1) & PM_RESP_DC9_READY;
+
+ seq_printf(m, "Time to Next Fill : 0x%08x\n",
+ intel_de_read(dev_priv, PM_RSP_DBG_0) & PM_RESP_TTNF_MASK);
+ seq_printf(m, "Time to Next VBI : 0x%08x\n",
+ (intel_de_read(dev_priv, PM_RSP_DBG_0) &
PM_RESP_TTNVBI_MASK) >> 16);
+ seq_printf(m, "Selective Exit Latency : 0x%08x\n",
+ intel_de_read(dev_priv, PM_RSP_DBG_1) &
PM_RESP_SEL_EXIT_LATENCY_MASK);
+ seq_printf(m, "DC9 Ready : %s\n", yesno(DC9_status));
+ return 0;
+}
+
static void intel_seq_print_mode(struct seq_file *m, int tabs,
const struct drm_display_mode *mode)
{
@@ -2100,6 +2122,7 @@ static const struct drm_info_list
intel_display_debugfs_list[] = {
{"i915_edp_psr_status", i915_edp_psr_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_dmc_info", i915_dmc_info, 0},
+ {"i915_pm_req_res_info", i915_pm_req_res_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0023c023f472..8c91d598dc29 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -12423,4 +12423,14 @@ enum skl_power_gate {
#define TGL_ROOT_DEVICE_SKU_ULX0x2
#define TGL_ROOT_DEVICE_SKU_ULT0x4
+/*These registers are of functional registers for PM debug request and
response registers*/
+#define PM_REQ_DBG_0 _MMIO(0x45284)
+#define PM_REQ_DBG_1 _MMIO(0x45288)
+#define PM_RSP_DBG_0 _MMIO(0x4528C)
+#define PM_RESP_TTNF_MASKREG_GENMASK(15, 0)
+#define PM_RESP_TTNVBI_MASK REG_GENMASK(31, 16)
+#define PM_RSP_DBG_1 _MMIO(0x45290)
+#define PM_RESP_SEL_EXIT_LATENCY_MASKREG_GENMASK(2, 0)
+#define PM_RESP_DC9_READYREG_BIT(15)
+
#endif /* _I915_REG_H_ */
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave and Daniel, here's this week's PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2021-01-12: * dma-buf: Fix a memory leak in CMAV heap * drm: Fix format check for legacy pageflips * ttm: Pass correct address to dma_mapping_error(); Use mutex in pool shrinker The following changes since commit a73858ef4d5e1d425e171f0f6a52864176a6a979: drm/ttm: unexport ttm_pool_init/fini (2021-01-07 14:25:43 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-12 for you to fetch changes up to bb52cb0dec8d2fecdb22843a805131478a180728: drm/ttm: make the pool shrinker lock a mutex (2021-01-12 14:02:08 +0100) Short summary of fixes pull: * dma-buf: Fix a memory leak in CMAV heap * drm: Fix format check for legacy pageflips * ttm: Pass correct address to dma_mapping_error(); Use mutex in pool shrinker Bas Nieuwenhuizen (1): drm: Check actual format for legacy pageflip. Christian König (1): drm/ttm: make the pool shrinker lock a mutex Jeremy Cline (1): drm/ttm: Fix address passed to dma_mapping_error() in ttm_pool_map() John Stultz (1): dma-buf: cma_heap: Fix memory leak in CMA heap drivers/dma-buf/heaps/cma_heap.c | 3 +++ drivers/gpu/drm/drm_plane.c | 9 - drivers/gpu/drm/ttm/ttm_pool.c | 22 +++--- 3 files changed, 22 insertions(+), 12 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Force a failed engine reset
== Series Details == Series: drm/i915/selftests: Force a failed engine reset URL : https://patchwork.freedesktop.org/series/85749/ State : success == Summary == CI Bug Log - changes from CI_DRM_9590 -> Patchwork_19323 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/index.html Known issues Here are the changes found in Patchwork_19323 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +15 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@i915_getparams_basic@basic-subslice-total: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html * igt@i915_selftest@live@active: - fi-bsw-n3050: [PASS][4] -> [DMESG-FAIL][5] ([i915#2675] / [i915#541]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-bsw-n3050/igt@i915_selftest@l...@active.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-bsw-n3050/igt@i915_selftest@l...@active.html * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][6] -> [INCOMPLETE][7] ([i915#1580] / [i915#2276]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-icl-y/igt@i915_selftest@l...@execlists.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - fi-bsw-n3050: [PASS][8] -> [DMESG-FAIL][9] ([i915#2675]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html * igt@runner@aborted: - fi-icl-y: NOTRUN -> [FAIL][10] ([i915#1580] / [i915#2724]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-icl-y/igt@run...@aborted.html Possible fixes * igt@vgem_basic@create: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-tgl-y/igt@vgem_ba...@create.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/fi-tgl-y/igt@vgem_ba...@create.html [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#2675]: https://gitlab.freedesktop.org/drm/intel/issues/2675 [i915#2724]: https://gitlab.freedesktop.org/drm/intel/issues/2724 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (44 -> 38) -- Missing(6): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9590 -> Patchwork_19323 CI-20190529: 20190529 CI_DRM_9590: 5b3f9c79750cbe06f663b9935cef83cbd6b6ac46 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5955: 4ad3fdae02ad6e6147a96e3c05438be043426266 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19323: 4fd279f422eab4681193fffad411d22144a5f698 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4fd279f422ea drm/i915/selftests: Force a failed engine reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19323/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Force a failed engine reset
== Series Details ==
Series: drm/i915/selftests: Force a failed engine reset
URL : https://patchwork.freedesktop.org/series/85749/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4fd279f422ea drm/i915/selftests: Force a failed engine reset
-:44: WARNING:LINE_SPACING: Missing a blank line after declarations
#44: FILE: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:568:
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
-:116: CHECK:SPACING: spaces preferred around that '/' (ctx:WxV)
#116: FILE: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:640:
+ if (i915_request_wait(last, 0, HZ /2) < 0) {
^
total: 0 errors, 1 warnings, 1 checks, 145 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915/gt: Check for arbitration after writing start seqno
== Series Details == Series: series starting with [CI,1/2] drm/i915/gt: Check for arbitration after writing start seqno URL : https://patchwork.freedesktop.org/series/85746/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9590 -> Patchwork_19322 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19322 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19322, 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_19322/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19322: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_heartbeat: - fi-bdw-5557u: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19322/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html Known issues Here are the changes found in Patchwork_19322 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2868]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19322/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19322/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@vgem_basic@create: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9590/fi-tgl-y/igt@vgem_ba...@create.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19322/fi-tgl-y/igt@vgem_ba...@create.html [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 37) -- Missing(7): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-cml-drallion fi-bdw-samus Build changes - * Linux: CI_DRM_9590 -> Patchwork_19322 CI-20190529: 20190529 CI_DRM_9590: 5b3f9c79750cbe06f663b9935cef83cbd6b6ac46 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5955: 4ad3fdae02ad6e6147a96e3c05438be043426266 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19322: 7b59b45506cb0f5ec19fc13511b9d2911f856f0e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7b59b45506cb drm/i915/gt: Perform an arbitration check before busywaiting fedfc3cb19ad drm/i915/gt: Check for arbitration after writing start seqno == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19322/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Force a failed engine reset
Inject a fault into the engine reset and check that the outstanding
requests are completed despite the failed reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 133 +++
1 file changed, 133 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index ffc6eabb6404..875633cc0a75 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -540,6 +540,138 @@ static int igt_reset_nop_engine(void *arg)
return 0;
}
+static void force_reset_timeout(struct intel_engine_cs *engine)
+{
+ engine->reset_timeout.probability = 999;
+ atomic_set(>reset_timeout.times, -1);
+}
+
+static void cancel_reset_timeout(struct intel_engine_cs *engine)
+{
+ memset(>reset_timeout, 0, sizeof(engine->reset_timeout));
+}
+
+static int igt_reset_fail_engine(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /* Check that we can engine-reset during non-user portions */
+
+ if (!intel_has_reset_engine(gt))
+ return 0;
+
+ for_each_engine(engine, gt, id) {
+ unsigned int count;
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
+ int err;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ st_engine_heartbeat_disable(engine);
+ set_bit(I915_RESET_ENGINE + id, >reset.flags);
+ count = 0;
+ do {
+ struct i915_request *last = NULL;
+ int i;
+
+ if (!wait_for_idle(engine)) {
+ pr_err("%s failed to idle before reset\n",
+ engine->name);
+ err = -EIO;
+ break;
+ }
+
+ for (i = 0; i < 16; i++) {
+ struct i915_request *rq;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq)) {
+ struct drm_printer p =
+
drm_info_printer(gt->i915->drm.dev);
+ intel_engine_dump(engine, ,
+ "%s(%s): failed to
submit request\n",
+ __func__,
+ engine->name);
+
+ GEM_TRACE("%s(%s): failed to submit
request\n",
+ __func__,
+ engine->name);
+ GEM_TRACE_DUMP();
+
+ intel_gt_set_wedged(gt);
+ if (last)
+ i915_request_put(last);
+
+ err = PTR_ERR(rq);
+ goto out;
+ }
+
+ if (last)
+ i915_request_put(last);
+ last = i915_request_get(rq);
+ i915_request_add(rq);
+ }
+
+ if (count & 1) {
+ err = intel_engine_reset(engine, NULL);
+ if (err) {
+ GEM_TRACE_ERR("intel_engine_reset(%s)
failed, err:%d\n",
+ engine->name, err);
+ GEM_TRACE_DUMP();
+ break;
+ }
+ } else {
+ force_reset_timeout(engine);
+ err = intel_engine_reset(engine, NULL);
+ cancel_reset_timeout(engine);
+ if (err != -ETIMEDOUT) {
+ pr_err("intel_engine_reset(%s) did not
fail, err:%d\n",
+ engine->name, err);
+ break;
+ }
+ }
+
+ err = 0;
+ if (i915_request_wait(last, 0, HZ /2) < 0) {
+ struct drm_printer p =
+ drm_info_printer(gt->i915->drm.dev);
+
+ intel_engine_dump(engine, ,
+ "%s(%s): failed
Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time
On Mon, 2021-01-11 at 21:38 +, Huang, Sean Z wrote: > Hello, > > I see, based on Joonas and Rodrigo's feedback. > > I made the modification as below, I will still keep the macro in this > .c instead of i915_reg.h, and this change will be reflected in rev20. > > /* KCR register definitions */ > #define KCR_INIT _MMIO(0x320f0) > -#define KCR_INIT_MASK_SHIFT (16) > + > /* Setting KCR Init bit is required after system boot */ > -#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << > KCR_INIT_MASK_SHIFT)) > +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) << 16)) This is not what I asked actually. I asked to get the BIT(14) to be defined separated, shift defined as well... and the | and actuall shift operations to be performed in the code and not in the defines > > Best regards, > Sean > > -Original Message- > From: Joonas Lahtinen > Sent: Friday, January 8, 2021 3:31 AM > To: Huang, Sean Z ; > Intel-gfx@lists.freedesktop.org; Vivi, Rodrigo < > rodrigo.v...@intel.com> > Subject: Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg > init during the boot time > > Quoting Vivi, Rodrigo (2021-01-07 17:31:36) > > On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote: > > > Set the KCR init during the boot time, which is required by > > > hardware, to allow us doing further protection operation such as > > > sending commands to GPU or TEE. > > > > > > Signed-off-by: Huang, Sean Z > > > --- > > > drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c > > > b/drivers/gpu/drm/i915/pxp/intel_pxp.c > > > index 9bc3c7e30654..f566a4fda044 100644 > > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c > > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c > > > @@ -6,6 +6,12 @@ > > > #include "intel_pxp.h" > > > #include "intel_pxp_context.h" > > > > > > +/* KCR register definitions */ > > > > please define this in i915_reg.h > > Generally the trend on the GT side is to contain in a .c file if > there are no shared users like these. So they should be at this spot, > yet the rest of the review comments apply. > > The spurious comments should be dropped and like Rodrigo pointed out, > we should be using the appropriate macros for a masked writes, not > baking in the #define. > > Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 098/162] drm/i915/gtt: map the PD up front
On Fri, 27 Nov 2020 at 13:32, Chris Wilson wrote: > > Quoting Matthew Auld (2020-11-27 12:06:14) > > We need to general our accessor for the page directories and tables from > > using the simple kmap_atomic to support local memory, and this setup > > must be done on acquisition of the backing storage prior to entering > > fence execution contexts. Here we replace the kmap with the object > > maping code that for simple single page shmemfs object will return a > > plain kmap, that is then kept for the lifetime of the page directory. > > > > Signed-off-by: Matthew Auld > > Signed-off-by: Chris Wilson > > We are going to really struggle with this on 32b :( Just go back to mapping everything on demand like we did previously, and unmap as soon as we are done with the current directory across alloc/insert/clear? > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/gt: Perform an arbitration check before busywaiting
During igt_reset_nop_engine, it was observed that an unexpected failed
engine reset lead to us busywaiting on the stop-ring semaphore (set
during the reset preparations) on the first request afterwards. There was
no explicit MI_ARB_CHECK in this sequence as the presumption was that
the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
It did not in this circumstance, so force it.
This patch is based on the assumption that the MI_SEMAPHORE_WAIT failure
to arbitrate is a rare Tigerlake bug, similar to the lite-restore vs
semaphore issues previously seen in the CS. The explicit MI_ARB_CHECK
should always ensure that there is at least one arbitration point in the
request before the MI_SEMAPHORE_WAIT to trigger the IDLE->ACTIVE event.
Upon processing that event, we will clear the stop-ring flag and release
the semaphore from its busywait.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1ed9f572c8a4..8066b93e6dc4 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -578,6 +578,7 @@ u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs)
static u32 *gen12_emit_preempt_busywait(struct i915_request *rq, u32 *cs)
{
+ *cs++ = MI_ARB_CHECK; /* trigger IDLE->ACTIVE first */
*cs++ = MI_SEMAPHORE_WAIT_TOKEN |
MI_SEMAPHORE_GLOBAL_GTT |
MI_SEMAPHORE_POLL |
@@ -586,7 +587,6 @@ static u32 *gen12_emit_preempt_busywait(struct i915_request
*rq, u32 *cs)
*cs++ = preempt_address(rq->engine);
*cs++ = 0;
*cs++ = 0;
- *cs++ = MI_NOOP;
return cs;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/gt: Check for arbitration after writing start seqno
On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous processing of the CS event, the request will then be treated as having started when we make the decisions as to how to process that CS event. v2: More commentary about the users of i915_request_started() as a reminder about why we are marking the initial breadcrumb. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c index 2e36e0a9d8a6..1ed9f572c8a4 100644 --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c @@ -361,19 +361,30 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq) if (IS_ERR(cs)) return PTR_ERR(cs); + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; + *cs++ = hwsp_offset(rq); + *cs++ = 0; + *cs++ = rq->fence.seqno - 1; + /* * Check if we have been preempted before we even get started. * * After this point i915_request_started() reports true, even if * we get preempted and so are no longer running. +* +* i915_request_started() is used during preemption processing +* to decide if the request is currently inside the user payload +* or spinning on a kernel semaphore (or earlier). For no-preemption +* requests, we do allow preemption on the semaphore before the user +* payload, but do not allow preemption once the request is started. +* +* i915_request_started() is similarly used during GPU hangs to +* determine if the user's payload was guilty, and if so, the +* request is banned. Before the request is started, it is assumed +* to be unharmed and an innocent victim of another's hang. */ - *cs++ = MI_ARB_CHECK; *cs++ = MI_NOOP; - - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; - *cs++ = hwsp_offset(rq); - *cs++ = 0; - *cs++ = rq->fence.seqno - 1; + *cs++ = MI_ARB_CHECK; intel_ring_advance(rq, cs); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow huge_gem_object to kick the shrinker
On Tue, 12 Jan 2021 at 02:00, Chris Wilson wrote: > > A new fi-cml-dallium CI machine has 8G and apparently plenty free, yet > fails some selftests with ENOMEM. The failures all seem to be from > huge_gem_object which does not try very hard to allocate memory, > skipping reclaim entirely. Let's try a bit harder and direct reclaim > before failing. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Remove stolen node before releasing the region
On Tue, 12 Jan 2021 at 01:50, Chris Wilson wrote: > > If this stolen object holds the last reference to the region, we need to > remove our drm_mm_node before freeing the region's drm_mm. > > <4> [431.679591] Memory manager not clean during takedown. > <4> [431.679633] WARNING: CPU: 0 PID: 110 at drivers/gpu/drm/drm_mm.c:999 > drm_mm_takedown+0x51/0x100 > <4> [431.679655] Modules linked in: i915 vgem btusb snd_hda_codec_hdmi btrtl > btbcm btintel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio > bluetooth coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel > ecdh_generic ecc r8169 realtek lpc_ich snd_intel_dspcfg snd_hda_codec > snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers [last > unloaded: i915] > <4> [431.679883] CPU: 0 PID: 110 Comm: kworker/u4:3 Tainted: G U > 5.11.0-rc3-CI-CI_DRM_9583+ #1 > <4> [431.679895] Hardware name: /NUC5CPYB, BIOS > PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 > <4> [431.679905] Workqueue: i915 __i915_gem_free_work [i915] > <4> [431.680831] RIP: 0010:drm_mm_takedown+0x51/0x100 > <4> [431.680850] Code: 44 24 08 65 48 33 04 25 28 00 00 00 0f 85 b6 00 00 00 > 48 83 c4 10 5b 5d 41 5c c3 48 89 fb 48 c7 c7 c8 b7 38 82 e8 00 d6 37 00 <0f> > 0b 48 8b 3d 96 d5 d1 00 ba 00 10 00 00 be c0 0c 00 00 e8 d7 64 > <4> [431.680862] RSP: 0018:c9ad7dc0 EFLAGS: 00010282 > <4> [431.680879] RAX: RBX: 8881109aa140 RCX: > 0001 > <4> [431.680888] RDX: 8001 RSI: 8235a70f RDI: > > <4> [431.680897] RBP: 8881109aa178 R08: 0001 R09: > 0001 > <4> [431.680906] R10: 25eaec48 R11: f5b271a7 R12: > 88810a38ddc0 > <4> [431.680916] R13: R14: 82861b70 R15: > 88810b715538 > <4> [431.680925] FS: () GS:88817b80() > knlGS: > <4> [431.680935] CS: 0010 DS: ES: CR0: 80050033 > <4> [431.680945] CR2: 56377cfd7c48 CR3: 0001045de000 CR4: > 001006f0 > <4> [431.680954] Call Trace: > <4> [431.680977] __intel_memory_region_destroy+0x24/0x50 [i915] > <4> [431.681340] i915_gem_object_release_stolen+0x26/0x40 [i915] > <4> [431.681637] __i915_gem_free_objects.isra.21+0x1ef/0x3b0 [i915] > <4> [431.681935] process_one_work+0x270/0x5c0 > <4> [431.682022] worker_thread+0x37/0x380 > <4> [431.682047] ? process_one_work+0x5c0/0x5c0 > <4> [431.682062] kthread+0x146/0x170 > <4> [431.682077] ? kthread_park+0x80/0x80 > <4> [431.682098] ret_from_fork+0x22/0x30 > <4> [431.682153] irq event stamp: 1872905 > <4> [431.682162] hardirqs last enabled at (1872911): [] > console_unlock+0x49a/0x580 > <4> [431.682176] hardirqs last disabled at (1872916): [] > console_unlock+0x406/0x580 > <4> [431.682187] softirqs last enabled at (1872850): [] > __do_softirq+0x342/0x48e > <4> [431.682201] softirqs last disabled at (1872845): [] > asm_call_irq_on_stack+0x12/0x20 > <4> [431.682214] ---[ end trace 5d3bcd818e2e3816 ]--- > <3> [431.686188] [drm:drm_mm_takedown] *ERROR* node [0002d000 + 4000]: > inserted at > drm_mm_insert_node_in_range+0x34a/0x5b0 > i915_gem_stolen_insert_node_in_range+0x7b/0xa0 [i915] > _i915_gem_object_create_stolen+0x83/0xd0 [i915] > i915_gem_object_create_region+0x61/0x140 [i915] > intel_engine_create_ring+0x176/0x230 [i915] > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2927 > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
On 11/01/2021 21:54, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 17:12:57) On 11/01/2021 16:27, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 16:19:40) On 11/01/2021 10:57, Chris Wilson wrote: During igt_reset_nop_engine, it was observed that an unexpected failed engine reset lead to us busywaiting on the stop-ring semaphore (set during the reset preparations) on the first request afterwards. There was no explicit MI_ARB_CHECK in this sequence as the presumption was that the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point. It did not in this circumstance, so force it. In other words MI_SEMAPHORE_POLL is not a preemption point? Can't remember if I knew that or not.. MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a miss. 1) Why not the same handling in !gen12 version? Because I think it's a bug in tgl [a0 at least]. I think I've seen the same symptoms on tgl before, but not earlier. This is the first time the sequence clicked as to why it was busy spinning. Random engine reset failures are rare enough -- I was meant to also write a test case to inject failure. Random engine reset failure you think is a TGL issue? The MI_SEMAPHORE_WAIT | POLL miss not generating an arbitration point. We have quite a few selftests and IGT that use this feature. So I was wondering if this was similar to one of those tgl issues with semaphores and CS events. The random engine reset failure here is also decidedly odd. The engine was idle! 2) Failed reset leads to busy-hang in following request _tail_? But there is an arb check at the start of following request as well. Or in cases where we context switch into the middle of a previously executing request? It was the first request submitted after the failed reset. We expect to clear the ring-stop flag on the CS IDLE->ACTIVE event. But why would that busy hang? Hasn't the failed request unpaused the ring? The engine was idle at the time of the failed reset. We left the ring-stop set, and submitted the next batch of requests. We hit the MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but without hitting an arbitration point (first request, no init-breadcrumb in this case), the semaphore was stuck. So a kernel context request? Ish. The selftest is using empty requests, and not emitting the initial breadcrumb. (So acting like a kernel context.) Why hasn't IDLE->ACTIVE cleared ring stop? There hasn't been an idle->active event, not a single CS event after writing to ELSP and timing out while still spinning on the semaphore. Presumably this CSB must come after the first request has been submitted so apparently I am still not getting how it hangs. It was never sent. The context is still in pending[0] (not active[0]) and there's no sign in the trace of any interrupts/tasklet handing other than the semaphore-wait interrupt. Just because igt_reset_nop_engine does things "quickly"? It prevents the CSB from arriving? More that the since we do very little we hit the semaphore before the CS has recovered from the shock of being asked to do something. So ARB_CHECK pickups up on the fact ELSP has been rewritten before the IDLE->ACTIVE even received and/or engine reset prevented it from arriving? The ARB_CHECK should trigger the CS to generate the IDLE->ACTIVE event. (Of course assuming that the bug is in the semaphore not triggering the event due to strange circumstances and not a bug in the event generator itself.) I'm suspicious of the semaphore due to the earlier CS bugs with lite-restores + semaphores, and am expecting that since the MI_ARB_CHECK is explicit, it actually works. Okay got it, thanks. I suggest it would be good to slightly improve the commit message so it is clear what are the suspected TGL quirks. But in general: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: Check actual format for legacy pageflip.
On Mon, Jan 11, 2021 at 04:28:31PM -0500, Alex Deucher wrote:
> On Mon, Jan 11, 2021 at 11:39 AM Bas Nieuwenhuizen
> wrote:
> >
> > On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
> > >
> > > On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> > > wrote:
> > > >
> > > > With modifiers one can actually have different format_info structs
> > > > for the same format, which now matters for AMDGPU since we convert
> > > > implicit modifiers to explicit modifiers with multiple planes.
> > > >
> > > > I checked other drivers and it doesn't look like they end up triggering
> > > > this case so I think this is safe to relax.
> > > >
> > > > Signed-off-by: Bas Nieuwenhuizen
> > > > Reviewed-by: Daniel Vetter
> > > > Reviewed-by: Zhan Liu
> > > > Acked-by: Christian König
> > > > Acked-by: Alex Deucher
> > > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
> > > > converted metadata.")
> > >
> > > Do you have commit rights to drm-misc or do you need someone to commit
> > > this for you?
> >
> > I don't have commit rights so if the patch could be committed for me
> > that would be appreciated!
>
> Pushed to drm-misc-fixes. Thanks!
>
> If you want access to drm-misc, I don't see any reason you shouldn't have it.
There's some old-school bash tooling involved since we're (not yet, I can
hope) doing gitlab MR:
https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
Otherwise makes sense imo.
-Daniel
>
> Alex
>
>
> > >
> > > Thanks!
> > >
> > > Alex
> > >
> > > > ---
> > > > drivers/gpu/drm/drm_plane.c | 9 -
> > > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > > index e6231947f987..a0cb746bcb0a 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -1163,7 +1163,14 @@ int drm_mode_page_flip_ioctl(struct drm_device
> > > > *dev,
> > > > if (ret)
> > > > goto out;
> > > >
> > > > - if (old_fb->format != fb->format) {
> > > > + /*
> > > > +* Only check the FOURCC format code, excluding modifiers. This
> > > > is
> > > > +* enough for all legacy drivers. Atomic drivers have their own
> > > > +* checks in their ->atomic_check implementation, which will
> > > > +* return -EINVAL if any hw or driver constraint is violated due
> > > > +* to modifier changes.
> > > > +*/
> > > > + if (old_fb->format->format != fb->format->format) {
> > > > DRM_DEBUG_KMS("Page flip is not allowed to change frame
> > > > buffer format.\n");
> > > > ret = -EINVAL;
> > > > goto out;
> > > > --
> > > > 2.29.2
> > > >
> > > > ___
> > > > amd-gfx mailing list
> > > > amd-...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
On 11/01/2021 16:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 16:03:48) On 11/01/2021 10:57, Chris Wilson wrote: On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous processing of the CS event, the request will then be treated as having started when we make the decisions as to how to process that CS event. What is the wider context with this change? Just thinking about the impact of MI_ARB_ONOFF. It's the next patch that sparked the curiosity at that is trying to address a missed arbitration point on the semaphore-wait miss. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c index 2e36e0a9d8a6..9a182652a35e 100644 --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq) if (IS_ERR(cs)) return PTR_ERR(cs); + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; + *cs++ = hwsp_offset(rq); + *cs++ = 0; + *cs++ = rq->fence.seqno - 1; + Strictly this movement even makes the existing comment (below) more correct. /* * Check if we have been preempted before we even get started. * * After this point i915_request_started() reports true, even if * we get preempted and so are no longer running. */ - *cs++ = MI_ARB_CHECK; *cs++ = MI_NOOP; - - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; - *cs++ = hwsp_offset(rq); - *cs++ = 0; - *cs++ = rq->fence.seqno - 1; + *cs++ = MI_ARB_CHECK; Special reason to have NOOP before MI_ARB_CHECK or would more common NOOP padding at the end be suitable? The so small it's barely a reason was to put as much distance (those whole 6 cycles) between the store and the arbitration point. Overall on the patch, there could be slight difference on how i915_request_started reports true and would now allow to be preempted after that point, even if the user payload itself would not be preemptable. Obviously that applies on Gen8, maybe on later Gens with like non-preemptible media batches or so. I can't think that it would (or should) cause a problem though, just thinking out loud. So don't know really, sounds safe to experiment. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Allow huge_gem_object to kick the shrinker
== Series Details == Series: drm/i915/selftests: Allow huge_gem_object to kick the shrinker URL : https://patchwork.freedesktop.org/series/85729/ State : success == Summary == CI Bug Log - changes from CI_DRM_9586_full -> Patchwork_19321_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_19321_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19321_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19321_full: ### IGT changes ### Warnings * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-iclb: [SKIP][1] ([i915#588]) -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-iclb2/igt@i915_pm...@dc3co-vpb-simulation.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-iclb5/igt@i915_pm...@dc3co-vpb-simulation.html Known issues Here are the changes found in Patchwork_19321_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-fds-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-glk3/igt@gem_exec_whis...@basic-fds-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-glk6/igt@gem_exec_whis...@basic-fds-priority-all.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-skl6/igt@i915_module_l...@reload-with-fault-injection.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-skl9/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#151]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-skl6/igt@i915_pm_...@system-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-skl8/igt@i915_pm_...@system-suspend.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#2521]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-skl8/igt@kms_async_fl...@alternate-sync-async-flip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-skl5/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue: - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-kbl6/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html * igt@kms_cursor_crc@pipe-b-cursor-64x21-offscreen: - shard-skl: [PASS][12] -> [FAIL][13] ([i915#54]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#2122]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-skl9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-kbl6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-skl9/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-gtt.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109642] / [fdo#111068]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9586/shard-iclb2/igt@kms_psr2_su@page_flip.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19321/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +1 similar issue [20]:
Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Thu, Jan 7, 2021 at 2:52 PM Lyude Paul wrote:
>
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backlights, in particular VESA and Intel's HDR backlight
> implementations, can end up being more complicated. With Intel's
> proprietary interface, HDR backlight controls always run through the
> DPCD. When the backlight is in SDR backlight mode however, the driver
> may need to bypass the TCON and control the backlight directly through
> PWM.
>
> So, in order to support this we'll need to split our backlight callbacks
> into two groups: a set of high-level backlight control callbacks in
> intel_panel, and an additional set of pwm-specific backlight control
> callbacks. This also implies a functional changes for how these
> callbacks are used:
>
> * We now keep track of two separate backlight level ranges, one for the
> high-level backlight, and one for the pwm backlight range
> * We also keep track of backlight enablement and PWM backlight
> enablement separately
> * Since the currently set backlight level might not be the same as the
> currently programmed PWM backlight level, we stop setting
> panel->backlight.level with the currently programmed PWM backlight
> level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> on the higher level backlight control functions to retrieve the
> current PWM backlight level (in this case, intel_pwm_get_backlight()).
> Note that there are still a few PWM backlight setup callbacks that
> do actually need to retrieve the current PWM backlight level, although
> we no longer save this value in panel->backlight.level like before.
>
> Additionally, we drop the call to lpt_get_backlight() in
> lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> we get from it and only write it back if we're in CPU mode, and switching
> to PCH mode. The reason for this is because in the original codepath for
> this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> responsible for fetching the initial backlight level. On lpt systems, the
> only time we could ever be in PCH backlight mode is during the initial
> driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> will always be the callback used for retrieving the current backlight
> level. After this patch we still need to fetch and write-back the PCH
> backlight value if we're switching from CPU mode to PCH, but because
> intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> using the get() hook, which always ends up being lpt_get_backlight(). Thus
> - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> made redundant.
>
> v5:
> * Fix indenting warnings from checkpatch
> v4:
> * Fix commit message
> * Remove outdated comment in intel_panel.c
> * Rename pwm_(min|max) to pwm_level_(min|max)
> * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
> indirection
> * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
> intel_panel_init_backlight_funcs() quite yet
> v3:
> * Reuse intel_panel_bl_funcs() for pwm_funcs
> * Explain why we drop lpt_get_backlight()
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Whole series is:
Tested-by: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_display_types.h| 4 +
> drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
> 2 files changed, 187 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1067bd073c95..ee5c2d50b81a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -252,6 +252,9 @@ struct intel_panel {
> bool alternate_pwm_increment; /* lpt+ */
>
> /* PWM chip */
> + u32 pwm_level_min;
> + u32 pwm_level_max;
> + bool pwm_enabled;
> bool util_pin_active_low; /* bxt+ */
> u8 controller; /* bxt+ only */
> struct pwm_device *pwm;
> @@ -263,6 +266,7 @@ struct intel_panel {
> struct backlight_device *device;
>
> const struct intel_panel_bl_funcs *funcs;
> + const struct intel_panel_bl_funcs *pwm_funcs;
> void (*power)(struct intel_connector *, bool enable);
> } backlight;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 67f81ae995c4..8c99bf404a32 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -511,25 +511,34 @@ static u32
