[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: stop registering if drm_dev_register() fails
== Series Details == Series: series starting with [CI,1/4] drm/i915: stop registering if drm_dev_register() fails URL : https://patchwork.freedesktop.org/series/87062/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9773_full -> Patchwork_19677_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19677_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19677_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_19677_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@capture@vcs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-skl6/igt@gem_exec_capture@capt...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-skl4/igt@gem_exec_capture@capt...@vcs0.html Known issues Here are the changes found in Patchwork_19677_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_capture@capture@rcs0: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#3062]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-kbl4/igt@gem_exec_capture@capt...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-kbl2/igt@gem_exec_capture@capt...@rcs0.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-skl5/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2851]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-iclb8/igt@gem_exec_fair@basic-p...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-iclb6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html - shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2849]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-iclb3/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_schedule@u-fairslice@bcs0: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#2803]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-tglb6/igt@gem_exec_schedule@u-fairsl...@bcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-tglb3/igt@gem_exec_schedule@u-fairsl...@bcs0.html * igt@gem_mmap_gtt@hang: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1436]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/shard-tglb2/igt@gem_mmap_...@hang.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-tglb6/igt@gem_mmap_...@hang.html * igt@gem_pwrite@basic-exhaustion: - shard-kbl: NOTRUN -> [WARN][23] ([i915#2658]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/shard-kbl4/igt@gem_pwr...@basic-exhaustion.html * igt@gem_workarounds@suspend-resume:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: stop registering if drm_dev_register() fails
== Series Details == Series: series starting with [CI,1/4] drm/i915: stop registering if drm_dev_register() fails URL : https://patchwork.freedesktop.org/series/87062/ State : success == Summary == CI Bug Log - changes from CI_DRM_9773 -> Patchwork_19677 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/index.html Known issues Here are the changes found in Patchwork_19677 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-compute0: - fi-kbl-r: NOTRUN -> [SKIP][1] ([fdo#109271]) +20 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-kbl-r/igt@amdgpu/amd_cs_...@sync-compute0.html * igt@debugfs_test@read_all_entries: - 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_9773/fi-tgl-y/igt@debugfs_test@read_all_entries.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-apl-guc: NOTRUN -> [SKIP][4] ([fdo#109271]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-apl-guc/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-r: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-kbl-r/igt@gem_huc_c...@huc-copy.html * igt@i915_hangman@error-state-basic: - fi-apl-guc: NOTRUN -> [DMESG-WARN][6] ([i915#1610]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-apl-guc/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][7] -> [INCOMPLETE][8] ([i915#2940]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-r: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-kbl-r/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-r: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-kbl-r/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][11] ([i915#1436]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-bsw-nick/igt@run...@aborted.html - fi-apl-guc: NOTRUN -> [FAIL][12] ([i915#2426]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-apl-guc/igt@run...@aborted.html Possible fixes * igt@fbdev@read: - fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9773/fi-tgl-y/igt@fb...@read.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19677/fi-tgl-y/igt@fb...@read.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (44 -> 39) -- Additional (1): fi-apl-guc 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_9773 -> Patchwork_19677 CI-20190529: 20190529 CI_DRM_9773: 8db63ad78d8b09aeae480bef5b942690e26ffa39 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19677: 7889a8a476ac66c0a7691cf46f883c2ca7450a3a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7889a8a476ac drm/i915: move intel_init_audio_hooks inside display f54bc2e9b27a drm/i915/display: move register functions to display/ fbd41d92722c drm/i915: group display-related register calls cd17dbd63ac0 drm/i915: stop registering if drm_dev_register() fails == Logs == For more details see:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: stop registering if drm_dev_register() fails
== Series Details == Series: series starting with [CI,1/4] drm/i915: stop registering if drm_dev_register() fails URL : https://patchwork.freedesktop.org/series/87062/ 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/gt/intel_reset.c:1323: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:1437:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1491:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +./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' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915: stop registering if drm_dev_register() fails
If drm_dev_register() fails there is no reason to continue registering
the driver and initializing.
Signed-off-by: Lucas De Marchi
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b708517d3972..1f65c15775a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -674,17 +674,19 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_vgpu_register(dev_priv);
/* Reveal our presence to userspace */
- if (drm_dev_register(dev, 0) == 0) {
- i915_debugfs_register(dev_priv);
- if (HAS_DISPLAY(dev_priv))
- intel_display_debugfs_register(dev_priv);
- i915_setup_sysfs(dev_priv);
-
- /* Depends on sysfs having been initialized */
- i915_perf_register(dev_priv);
- } else
+ if (drm_dev_register(dev, 0)) {
drm_err(_priv->drm,
"Failed to register driver for userspace access!\n");
+ return;
+ }
+
+ i915_debugfs_register(dev_priv);
+ if (HAS_DISPLAY(dev_priv))
+ intel_display_debugfs_register(dev_priv);
+ i915_setup_sysfs(dev_priv);
+
+ /* Depends on sysfs having been initialized */
+ i915_perf_register(dev_priv);
if (HAS_DISPLAY(dev_priv)) {
/* Must be done after probing outputs */
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915: group display-related register calls
intel_gt_driver_register() may be called earlier than
intel_opregion_register() and acpi_video_register(), so move it up.
intel_display_debugfs_register() may be called later, together with the
other display-related initializations. There is a slight change in
behavior that sysfs files will show up before the display-related
debugfs files, but that shouldn't be a problem - userspace shouldn't be
relying in debugfs.
This allows us to group all the display-related calls under a single
check for "HAS_DISPLAY()" that can be later moved to a better place.
Signed-off-by: Lucas De Marchi
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 64 +
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1f65c15775a0..e3d83c75d968 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -681,38 +681,39 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
}
i915_debugfs_register(dev_priv);
- if (HAS_DISPLAY(dev_priv))
- intel_display_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
+ intel_gt_driver_register(_priv->gt);
+
if (HAS_DISPLAY(dev_priv)) {
+ intel_display_debugfs_register(dev_priv);
+
/* Must be done after probing outputs */
intel_opregion_register(dev_priv);
acpi_video_register();
- }
- intel_gt_driver_register(_priv->gt);
-
- intel_audio_init(dev_priv);
+ intel_audio_init(dev_priv);
- /*
-* Some ports require correctly set-up hpd registers for detection to
-* work properly (leading to ghost connected connector status), e.g. VGA
-* on gm45. Hence we can only set up the initial fbdev config after hpd
-* irqs are fully enabled. We do it last so that the async config
-* cannot run before the connectors are registered.
-*/
- intel_fbdev_initial_config_async(dev);
+ /*
+* Some ports require correctly set-up hpd registers for
+* detection to work properly (leading to ghost connected
+* connector status), e.g. VGA on gm45. Hence we can only set
+* up the initial fbdev config after hpd irqs are fully
+* enabled. We do it last so that the async config cannot run
+* before the connectors are registered.
+*/
+ intel_fbdev_initial_config_async(dev);
- /*
-* We need to coordinate the hotplugs with the asynchronous fbdev
-* configuration, for which we use the fbdev->async_cookie.
-*/
- if (HAS_DISPLAY(dev_priv))
+ /*
+* We need to coordinate the hotplugs with the asynchronous
+* fbdev configuration, for which we use the
+* fbdev->async_cookie.
+*/
drm_kms_helper_poll_init(dev);
+ }
intel_power_domains_enable(dev_priv);
intel_runtime_pm_enable(_priv->runtime_pm);
@@ -736,20 +737,23 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_runtime_pm_disable(_priv->runtime_pm);
intel_power_domains_disable(dev_priv);
- intel_fbdev_unregister(dev_priv);
- intel_audio_deinit(dev_priv);
+ if (HAS_DISPLAY(dev_priv)) {
+ intel_fbdev_unregister(dev_priv);
+ intel_audio_deinit(dev_priv);
+
+ /*
+* After flushing the fbdev (incl. a late async config which
+* will have delayed queuing of a hotplug event), then flush
+* the hotplug events.
+*/
+ drm_kms_helper_poll_fini(_priv->drm);
+ drm_atomic_helper_shutdown(_priv->drm);
- /*
-* After flushing the fbdev (incl. a late async config which will
-* have delayed queuing of a hotplug event), then flush the hotplug
-* events.
-*/
- drm_kms_helper_poll_fini(_priv->drm);
- drm_atomic_helper_shutdown(_priv->drm);
+ acpi_video_unregister();
+ intel_opregion_unregister(dev_priv);
+ }
intel_gt_driver_unregister(_priv->gt);
- acpi_video_unregister();
- intel_opregion_unregister(dev_priv);
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915: move intel_init_audio_hooks inside display
intel_init_audio_hooks() sets up hooks in the display struct and only
makes sense when we have display. Move it inside
intel_init_display_hooks() so it isn't called when we don't have
display.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bb814126d4a3..0dc5cb36667a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12478,6 +12478,7 @@ static const struct drm_mode_config_funcs
intel_mode_funcs = {
void intel_init_display_hooks(struct drm_i915_private *dev_priv)
{
intel_init_cdclk_hooks(dev_priv);
+ intel_init_audio_hooks(dev_priv);
intel_dpll_init_clock_hook(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8c5d46ba847b..3edd5e47ad68 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -46,7 +46,6 @@
#include
#include "display/intel_acpi.h"
-#include "display/intel_audio.h"
#include "display/intel_bw.h"
#include "display/intel_cdclk.h"
#include "display/intel_csr.h"
@@ -353,7 +352,6 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_irq_init(dev_priv);
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
- intel_init_audio_hooks(dev_priv);
intel_detect_preproduction_hw(dev_priv);
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915/display: move register functions to display/
Now that all display-related functions are grouped in
i915_driver_register(), move them to display/ so we reduce the amount of
display calls from the rest of the driver.
Signed-off-by: Lucas De Marchi
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 53
drivers/gpu/drm/i915/display/intel_display.h | 3 ++
drivers/gpu/drm/i915/i915_drv.c | 45 +
3 files changed, 58 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 23ec68498800..bb814126d4a3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -24,6 +24,7 @@
* Eric Anholt
*/
+#include
#include
#include
#include
@@ -43,6 +44,7 @@
#include
#include
+#include "display/intel_audio.h"
#include "display/intel_crt.h"
#include "display/intel_ddi.h"
#include "display/intel_display_debugfs.h"
@@ -13944,6 +13946,57 @@ void intel_modeset_driver_remove_nogem(struct
drm_i915_private *i915)
intel_bios_driver_remove(i915);
}
+void intel_display_driver_register(struct drm_i915_private *i915)
+{
+ if (!HAS_DISPLAY(i915))
+ return;
+
+ intel_display_debugfs_register(i915);
+
+ /* Must be done after probing outputs */
+ intel_opregion_register(i915);
+ acpi_video_register();
+
+ intel_audio_init(i915);
+
+ /*
+* Some ports require correctly set-up hpd registers for
+* detection to work properly (leading to ghost connected
+* connector status), e.g. VGA on gm45. Hence we can only set
+* up the initial fbdev config after hpd irqs are fully
+* enabled. We do it last so that the async config cannot run
+* before the connectors are registered.
+*/
+ intel_fbdev_initial_config_async(>drm);
+
+ /*
+* We need to coordinate the hotplugs with the asynchronous
+* fbdev configuration, for which we use the
+* fbdev->async_cookie.
+*/
+ drm_kms_helper_poll_init(>drm);
+}
+
+void intel_display_driver_unregister(struct drm_i915_private *i915)
+{
+ if (!HAS_DISPLAY(i915))
+ return;
+
+ intel_fbdev_unregister(i915);
+ intel_audio_deinit(i915);
+
+ /*
+* After flushing the fbdev (incl. a late async config which
+* will have delayed queuing of a hotplug event), then flush
+* the hotplug events.
+*/
+ drm_kms_helper_poll_fini(>drm);
+ drm_atomic_helper_shutdown(>drm);
+
+ acpi_video_unregister();
+ intel_opregion_unregister(i915);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
struct intel_display_error_state {
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e3757ecabbf7..375ec2bccebd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -654,6 +654,9 @@ u32 intel_plane_adjust_aligned_offset(int *x, int *y,
unsigned int intel_tile_width_bytes(const struct drm_framebuffer *fb, int
color_plane);
unsigned int intel_tile_height(const struct drm_framebuffer *fb, int
color_plane);
+void intel_display_driver_register(struct drm_i915_private *i915);
+void intel_display_driver_unregister(struct drm_i915_private *i915);
+
/* modesetting */
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init_noirq(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e3d83c75d968..8c5d46ba847b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
@@ -51,7 +50,6 @@
#include "display/intel_bw.h"
#include "display/intel_cdclk.h"
#include "display/intel_csr.h"
-#include "display/intel_display_debugfs.h"
#include "display/intel_display_types.h"
#include "display/intel_dp.h"
#include "display/intel_fbdev.h"
@@ -688,32 +686,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_gt_driver_register(_priv->gt);
- if (HAS_DISPLAY(dev_priv)) {
- intel_display_debugfs_register(dev_priv);
-
- /* Must be done after probing outputs */
- intel_opregion_register(dev_priv);
- acpi_video_register();
-
- intel_audio_init(dev_priv);
-
- /*
-* Some ports require correctly set-up hpd registers for
-* detection to work properly (leading to ghost connected
-* connector status), e.g. VGA on gm45. Hence we can only set
-* up the initial fbdev config after hpd irqs are fully
-* enabled. We do it last so that the async config cannot run
-* before the connectors are
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2)
On Sat, Feb 13, 2021 at 02:05:20AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific > (rev2) > URL : https://patchwork.freedesktop.org/series/87054/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9772_full -> Patchwork_19676_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19676_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19676_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_19676_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_ctx_persistence@many-contexts: > - shard-iclb: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb7/igt@gem_ctx_persiste...@many-contexts.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-iclb3/igt@gem_ctx_persiste...@many-contexts.html Looks like the machine simply crashed while running this test; it's not related to these patches. Applies to din; thanks Lucas for the reviews. Matt > > > Known issues > > > Here are the changes found in Patchwork_19676_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@in-flight-suspend: > - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#1037] / [i915#180]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl1/igt@gem_...@in-flight-suspend.html > > * igt@gem_exec_fair@basic-deadline: > - shard-skl: NOTRUN -> [FAIL][4] ([i915#2846]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-skl9/igt@gem_exec_f...@basic-deadline.html > > * igt@gem_exec_fair@basic-none-rrul@rcs0: > - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html > > * igt@gem_exec_fair@basic-none@vecs0: > - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar > issue >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-kbl2/igt@gem_exec_fair@basic-n...@vecs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html > - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html > > * igt@gem_exec_fair@basic-pace@vcs0: > - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar > issue >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html > > * igt@gem_exec_fair@basic-pace@vecs0: > - shard-kbl: [PASS][13] -> [SKIP][14] ([fdo#109271]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html > - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar > issue >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html > > * igt@gem_exec_schedule@u-fairslice@rcs0: > - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@rcs0.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@rcs0.html > > * igt@gem_exec_whisper@basic-contexts-forked: > - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#118] / > [i915#95]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html >[20]: >
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2) URL : https://patchwork.freedesktop.org/series/87054/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9772_full -> Patchwork_19676_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19676_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19676_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_19676_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@many-contexts: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb7/igt@gem_ctx_persiste...@many-contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-iclb3/igt@gem_ctx_persiste...@many-contexts.html Known issues Here are the changes found in Patchwork_19676_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#1037] / [i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl1/igt@gem_...@in-flight-suspend.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][4] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-skl9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-kbl2/igt@gem_exec_fair@basic-n...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-tglb3/igt@gem_exec_fair@basic-p...@vecs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-tglb1/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#118] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-glk2/igt@gem_exec_whis...@basic-contexts-forked.html * igt@gem_pwrite@basic-exhaustion: - shard-kbl: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-kbl7/igt@gem_pwr...@basic-exhaustion.html - shard-apl: NOTRUN -> [WARN][22] ([i915#2658]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/shard-apl2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: -
Re: [Intel-gfx] [RFC PATCH 1/2] drm/dp: Make number of AUX retries configurable by display drivers.
(adding danvet to here, as I'd imagine they might be interested in seeing some of this) Thank you for the descriptive write up. I think we can solve some of the problems you described here, however the patches that you submitted definitely won't work as-is. In patch 2, by reverting Intel back to using only 7 retries you technically break whatever monitor originally prompted us to bump the retry count up to 32 in the first place. And we have to try our hardest to avoid breaking people's displays when they were already working. Also, I'll definitely point out though that a few of the issues you've pointed out actually exist as workarounds for bad DisplayPort devices (which is a big reason we have these helpers), but I think we might be able to fix some of the issues you've mentioned by coming up with better workarounds. More details below On Thu, 2021-02-11 at 06:56 +, Almahallawy, Khaled wrote: > On Wed, 2021-02-10 at 13:03 -0500, Lyude Paul wrote: > > On Wed, 2021-02-10 at 00:33 -0800, Khaled Almahallawy wrote: > > > The number of AUX retries specified in the DP specs is 7. > > > Currently, to make > > > Dell 4k monitors happier, the number of retries are 32. > > > i915 also retries 5 times (intel_dp_aux_xfer) which means in the > > > case of AUX > > > timeout we actually retries 32 * 5 = 160 times. > > > > Is there any good reason for i915 to actually be doing retries > > itself? It seems > > like an easier solution here might just to be to fix i915 so it > > doesn't retry, > > and just rely on DRM to do the retries as appropriate. > > > > That being said though, I'm open to this if there is a legitimate > > reason for > > i915 to be handling retries on its own > > i915 or others may benefit from controlling AUX retries to optimize and > minimize timing spent on the aux transactions. > > drm_dpcd_access handles multiple aux retries cases the same way (retry > 32 times at worst case). The 4 cases are: > 1- *AUX receive or IO error*. I believe it is up to specific > implementation/HW once it detects a receive error to retry based on > their internal understanding using the timeout appropriate to the HW > capabilities. This makes sense so far > > 2- *AUX Timeout* As the driver follows the specs for the recommended > timeout timer as defined in section (2.11.2 AUX Transaction > Response/Reply Timeouts), the driver has more intelligence to know how > many retries it needs. This is more useful in case of DP-ALT if some > issues happen in Type-C stack that cause AUX timeout (e.g. USB3 dock > detected as high speed (USB2) causing SBU/AUX lines to be disabled). > Also the disconnect of MST hub/docks is dependent how fast a userspace > disconnect all MST connectors. Not all user spaces do it as fast like > Chrome (ubuntu is an example): > https://chromium-review.googlesource.com/c/chromium/src/+/2512550/ So - I'm not exactly following how this portion of the specification is relevant to the issue that you're bringing up here. If I understand section 2.11.2 correctly, a "response" here is defined as a transmission from the DPRX which informs us on the current state of the transaction that we've started. This would be any one of the aux response statuses you've mentioned in this email: AUX_NACK, AUX_ACK, or AUX_DEFER. It doesn't actually have anything to do with the number of retries we have to do, because (ignoring the fact we retry on AUX_NACKS in DRM for a moment here) that reply could be an AUX_DEFER which would indicate that we have to resend the transaction and try again. I think this is the correct understanding of section 2.11.2, because I definitely don't think real world DP devices are able to actually complete a full AUX transaction within a timespan of 300-400µs reliably for the most part. The second thing to mention here is that regardless of the first point, I don't think your point about MST displays needing to be removed by userspace is correct. It is true that userspace can actually hold onto references to removed MST connectors after they've been removed, but the main purpose of this being possible is in order to accommodate legacy clients that wouldn't be able to handle a connector disappearing under them cleanly. Once the MST topology which a connector corresponds to is removed, the MST connector is removed ASAP from the kernel's cache of the respective DisplayPort's MST topology along with all of the connectors below it. At the same time, the respective DRM connectors are also unregistered from userspace. DRM explicitly doesn't allow any kind of client to enable new displays on connectors that are unregistered, and will reject any modesets involving them with the exception of modesets which only disable displays on those unregistered connectors (this last part is mainly just to be nice to legacy clients). So it doesn't really matter how quickly userspace disables the display configuration on those connectors, from the kernel's perspective they're already gone and a new
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9bc: Handle TGP PCH during suspend/resume (rev3)
== Series Details == Series: drm/i915/gen9bc: Handle TGP PCH during suspend/resume (rev3) URL : https://patchwork.freedesktop.org/series/86346/ State : success == Summary == CI Bug Log - changes from CI_DRM_9772_full -> Patchwork_19675_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19675_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([i915#1037] / [i915#2481]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb2/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-iclb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-skl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-iclb8/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-iclb: [PASS][11] -> [DMESG-WARN][12] ([i915#2803]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_pwrite@basic-exhaustion: - shard-kbl: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-kbl6/igt@gem_pwr...@basic-exhaustion.html - shard-apl: NOTRUN -> [WARN][14] ([i915#2658]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-apl8/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@input-checking: - shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#3002]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-kbl1/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1699]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-skl3/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gen3_mixed_blits: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271]) +79 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-kbl2/igt@gen3_mixed_blits.html * igt@i915_module_load@reload-with-fault-injection: - shard-snb: [PASS][18] -> [INCOMPLETE][19] ([i915#2880]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_pm_dc@dc6-dpms: - shard-skl: NOTRUN -> [FAIL][20] ([i915#454]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-skl3/igt@i915_pm...@dc6-dpms.html * igt@kms_ccs@pipe-c-crc-primary-basic: - shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111304]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-skl3/igt@kms_...@pipe-c-crc-primary-basic.html * igt@kms_chamelium@hdmi-hpd-storm: - shard-kbl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +6 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/shard-kbl4/igt@kms_chamel...@hdmi-hpd-storm.html * igt@kms_color_chamelium@pipe-c-ctm-max: - shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] /
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2) URL : https://patchwork.freedesktop.org/series/87054/ State : success == Summary == CI Bug Log - changes from CI_DRM_9772 -> Patchwork_19676 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/index.html Known issues Here are the changes found in Patchwork_19676 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([i915#1372]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@prime_self_import@basic-with_one_bo_two_files: - 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_9772/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_19676/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][5] ([i915#402]) -> [PASS][6] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-tgl-y/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [DMESG-WARN][7] ([i915#2411] / [i915#402]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@client: - fi-glk-dsi: [DMESG-FAIL][9] ([i915#3047]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-glk-dsi/igt@i915_selftest@l...@client.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/fi-glk-dsi/igt@i915_selftest@l...@client.html [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (45 -> 40) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9772 -> Patchwork_19676 CI-20190529: 20190529 CI_DRM_9772: e1ed2a25853b41a3f1561a4388de3edfef206170 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19676: 5757fda5d07be2b8bcfdf307c598b239dc4cd477 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5757fda5d07b drm/i915: Try to detect sudden loss of MMIO access 9190d2e6106d drm/i915: FPGA_DBG is display-specific == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19676/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 series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915: FPGA_DBG is display-specific (rev2) URL : https://patchwork.freedesktop.org/series/87054/ 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/gt/intel_reset.c:1323: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:1437:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1491:15: warning: memset with byte count of 16777216 ___ 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/gen9bc: Handle TGP PCH during suspend/resume (rev3)
== Series Details == Series: drm/i915/gen9bc: Handle TGP PCH during suspend/resume (rev3) URL : https://patchwork.freedesktop.org/series/86346/ State : success == Summary == CI Bug Log - changes from CI_DRM_9772 -> Patchwork_19675 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/index.html Known issues Here are the changes found in Patchwork_19675 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-kbl-soraka/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/fi-kbl-soraka/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#1372]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [DMESG-WARN][7] ([i915#2411] / [i915#402]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@client: - fi-glk-dsi: [DMESG-FAIL][9] ([i915#3047]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-glk-dsi/igt@i915_selftest@l...@client.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/fi-glk-dsi/igt@i915_selftest@l...@client.html * igt@prime_self_import@basic-with_one_bo: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9772/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (45 -> 39) -- 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_9772 -> Patchwork_19675 CI-20190529: 20190529 CI_DRM_9772: e1ed2a25853b41a3f1561a4388de3edfef206170 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19675: 6117b3e1da840d32ba6e08af8c07e830a5778602 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6117b3e1da84 drm/i915/gen9bc: Handle TGP PCH during suspend/resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19675/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: FPGA_DBG is display-specific
Although the bspec's description doesn't make it very clear, the
hardware architects have confirmed that the FPGA_DBG register that we
use to check for unclaimed MMIO accesses is display-specific and will
only properly flag unclaimed MMIO transactions for registers in the
display range. If a platform doesn't have display, FPGA_DBG itself will
not be available and should not be checked. Let's move the feature flag
into intel_device_info.display to more accurately reflect this.
Given that we now know FPGA_DBG is display-specific, it could be argued
that we should only check it on out intel_de_*() functions. However
let's not make that change right now; keeping the checks in all of the
existing locations still helps us catch cases where regular
intel_uncore_*() functions use bad MMIO offset math / base addresses and
accidentally wind up landing within an unused area within the display
MMIO range. It will also help catch cases where userspace-initiated
MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the
display range.
v2: Add missing hunk with the update to the HAS_FPGA_DBG_UNCLAIMED
macro. (CI)
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 4 ++--
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f55b5e6d8c9..f8413b3b9da8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1694,7 +1694,7 @@ tgl_stepping_get(struct drm_i915_private *dev_priv)
#define HAS_DP_MST(dev_priv) (INTEL_INFO(dev_priv)->display.has_dp_mst)
#define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi)
-#define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg)
+#define HAS_FPGA_DBG_UNCLAIMED(dev_priv)
(INTEL_INFO(dev_priv)->display.has_fpga_dbg)
#define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr)
#define HAS_PSR_HW_TRACKING(dev_priv) \
(INTEL_INFO(dev_priv)->display.has_psr_hw_tracking)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index eff7155db2fd..a9f24f2bda33 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -538,7 +538,7 @@ static const struct intel_device_info vlv_info = {
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
.display.has_ddi = 1, \
- .has_fpga_dbg = 1, \
+ .display.has_fpga_dbg = 1, \
.display.has_psr = 1, \
.display.has_psr_hw_tracking = 1, \
.display.has_dp_mst = 1, \
@@ -689,7 +689,7 @@ static const struct intel_device_info skl_gt4_info = {
BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
.has_64bit_reloc = 1, \
.display.has_ddi = 1, \
- .has_fpga_dbg = 1, \
+ .display.has_fpga_dbg = 1, \
.display.has_fbc = 1, \
.display.has_hdcp = 1, \
.display.has_psr = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index e6ca1023ffcf..d44f64b57b7a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -118,7 +118,6 @@ enum intel_ppgtt_type {
func(has_64bit_reloc); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
- func(has_fpga_dbg); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_l3_dpf); \
@@ -145,6 +144,7 @@ enum intel_ppgtt_type {
func(has_dsb); \
func(has_dsc); \
func(has_fbc); \
+ func(has_fpga_dbg); \
func(has_gmch); \
func(has_hdcp); \
func(has_hotplug); \
--
2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Wed, 2021-02-10 at 23:15 -0500, Rodrigo Vivi wrote:
> On Mon, Feb 08, 2021 at 06:39:00PM -0500, Lyude Paul wrote:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for this and move it into a set of shared DRM helpers.
> >
> > Note that these helpers are intended to handle DPCD related backlight
> > control bits such as setting the brightness level over AUX, probing the
> > backlight's TCON, enabling/disabling the backlight over AUX if supported,
> > etc. Any PWM-related portions of backlight control are explicitly left up
> > to the driver, as these will vary from platform to platform.
> >
> > The only exception to this is the calculation of the PWM frequency
> > pre-divider value. This is because the only platform-specific information
> > required for this is the PWM frequency of the panel, which the driver is
> > expected to provide if available. The actual algorithm for calculating this
> > value is standard and is defined in the eDP specification from VESA.
> >
> > Note that these helpers do not yet implement the full range of features
> > the VESA backlight interface provides, and only provide the following
> > functionality (all of which was already present in i915's DPCD backlight
> > support):
> >
> > * Basic control of brightness levels
> > * Basic probing of backlight capabilities
> > * Helpers for enabling and disabling the backlight
> >
> > v3:
> > * Split out changes to i915's backlight code to separate patches to make it
> > easier to review
> > v4:
> > * Style/spelling changes from Thomas Zimmermann
> >
> > Signed-off-by: Lyude Paul
> > Cc: Jani Nikula
> > Cc: Dave Airlie
> > Cc: greg.depo...@gmail.com
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 332 ++
> > .../drm/i915/display/intel_display_types.h | 5 +-
> > .../drm/i915/display/intel_dp_aux_backlight.c | 285 ++-
> > include/drm/drm_dp_helper.h | 48 +++
> > 4 files changed, 412 insertions(+), 258 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index eedbb48815b7..1a3d4679d720 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct
> > drm_dp_aux *aux, u8 color_spc)
> > return 0;
> > }
> > EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> > +
> > +/**
> > + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> > via AUX
> > + * @aux: The DP AUX channel to use
> > + * @bl: Backlight capability info from drm_edp_backlight_init()
> > + * @level: The brightness level to set
> > + *
> > + * Sets the brightness level of an eDP panel's backlight. Note that the
> > panel's backlight must
> > + * already have been enabled by the driver by calling
> > drm_edp_backlight_enable().
> > + *
> > + * Returns: %0 on success, negative error code on failure
> > + */
> > +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + u16 level)
> > +{
> > + int ret;
> > + u8 buf[2] = { 0 };
> > +
> > + if (bl->lsb_reg_used) {
> > + buf[0] = (level & 0xff00) >> 8;
> > + buf[1] = (level & 0x00ff);
> > + } else {
> > + buf[0] = level;
> > + }
> > +
> > + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> > sizeof(buf));
> > + if (ret != sizeof(buf)) {
> > + DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
> > aux->name, ret);
> > + return ret < 0 ? ret : -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> > +
> > +static int
> > +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + bool enable)
> > +{
> > + int ret;
> > + u8 buf;
> > +
> > + /* The panel uses something other then DPCD for enabling its
> > backlight */
> > + if (!bl->aux_enable)
> > + return 0;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
> > + if (ret != 1) {
> > + DRM_ERROR("%s: Failed to read eDP display control register:
> > %d\n", aux->name, ret);
> > + return ret < 0 ? ret : -EIO;
> > + }
> > + if (enable)
> > + buf |= DP_EDP_BACKLIGHT_ENABLE;
> > + else
> > + buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> > +
> > + ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
> > + if (ret != 1) {
> > + DRM_ERROR("%s: Failed to write eDP display control register:
> > %d\n", aux->name, ret);
> > + return ret < 0 ? ret : -EIO;
> > + }
> > +
> > +
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Try to detect sudden loss of MMIO access
On Fri, Feb 12, 2021 at 01:19:25PM -0800, Matt Roper wrote: In rare circumstances bugs in PCI programming, broken BIOS, or failing hardware can cause the CPU to lose access to the MMIO BAR on dgfx platforms. This is a pretty catastrophic failure since all register reads come back with values of 0x. Let's check for this special case while doing our usual checks for unclaimed registers; the FPGA_DBG register we use for those checks on modern platforms has some unused bits that will always read back as 0 when things are behaving properly; we can use them as canaries to detect when MMIO itself has suddenly broken and try to print a more informative error message in the logs. v2: Let the detection function still return 'true' if we've lost our MMIO access. We'll still get an extra false positive message about an unclaimed register access, but we'll still honor the 'mmio_debug' limit and not spam the log. (Lucas) Cc: Lucas De Marchi Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/i915/intel_uncore.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 5098f95d71b0..661b50191f2b 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -465,6 +465,22 @@ fpga_check_for_unclaimed_mmio(struct intel_uncore *uncore) if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM))) return false; + /* +* Bugs in PCI programming (or failing hardware) can occasionally cause +* us to lose access to the MMIO BAR. When this happens, register +* reads will come back with 0x for every register and things +* go bad very quickly. Let's try to detect that special case and at +* least try to print a more informative message about what has +* happened. +* +* During normal operation the FPGA_DBG register has several unused +* bits that will always read back as 0's so we can use them as canaries +* to recognize when MMIO accesses are just busted. +*/ + if (unlikely(dbg == ~0)) + drm_err(>i915->drm, + "Lost access to MMIO BAR; all registers now read back as 0x!\n"); + __raw_uncore_write32(uncore, FPGA_DBG, FPGA_DBG_RM_NOCLAIM); return true; -- 2.25.4 ___ 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: FPGA_DBG is display-specific
On Fri, Feb 12, 2021 at 01:19:24PM -0800, Matt Roper wrote:
Although the bspec's description doesn't make it very clear, the
hardware architects have confirmed that the FPGA_DBG register that we
use to check for unclaimed MMIO accesses is display-specific and will
only properly flag unclaimed MMIO transactions for registers in the
display range. If a platform doesn't have display, FPGA_DBG itself will
not be available and should not be checked. Let's move the feature flag
into intel_device_info.display to more accurately reflect this.
Given that we now know FPGA_DBG is display-specific, it could be argued
that we should only check it on out intel_de_*() functions. However
let's not make that change right now; keeping the checks in all of the
existing locations still helps us catch cases where regular
intel_uncore_*() functions use bad MMIO offset math / base addresses and
accidentally wind up landing within an unused area within the display
MMIO range. It will also help catch cases where userspace-initiated
MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the
display range.
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pci.c | 4 ++--
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index eff7155db2fd..a9f24f2bda33 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -538,7 +538,7 @@ static const struct intel_device_info vlv_info = {
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
.display.has_ddi = 1, \
- .has_fpga_dbg = 1, \
+ .display.has_fpga_dbg = 1, \
.display.has_psr = 1, \
.display.has_psr_hw_tracking = 1, \
.display.has_dp_mst = 1, \
@@ -689,7 +689,7 @@ static const struct intel_device_info skl_gt4_info = {
BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
.has_64bit_reloc = 1, \
.display.has_ddi = 1, \
- .has_fpga_dbg = 1, \
+ .display.has_fpga_dbg = 1, \
.display.has_fbc = 1, \
.display.has_hdcp = 1, \
.display.has_psr = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index e6ca1023ffcf..d44f64b57b7a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -118,7 +118,6 @@ enum intel_ppgtt_type {
func(has_64bit_reloc); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
- func(has_fpga_dbg); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_l3_dpf); \
@@ -145,6 +144,7 @@ enum intel_ppgtt_type {
func(has_dsb); \
func(has_dsc); \
func(has_fbc); \
+ func(has_fpga_dbg); \
func(has_gmch); \
func(has_hdcp); \
func(has_hotplug); \
--
2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915: FPGA_DBG is display-specific
== Series Details == Series: series starting with [1/2] drm/i915: FPGA_DBG is display-specific URL : https://patchwork.freedesktop.org/series/87054/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_uncore.o In file included from drivers/gpu/drm/i915/intel_uncore.c:27: drivers/gpu/drm/i915/intel_uncore.c: In function ‘intel_uncore_init_mmio’: drivers/gpu/drm/i915/i915_drv.h:1697:65: error: ‘const struct intel_device_info’ has no member named ‘has_fpga_dbg’; did you mean ‘has_gt_uc’? #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg) ^~~~ drivers/gpu/drm/i915/intel_uncore.c:1937:6: note: in expansion of macro ‘HAS_FPGA_DBG_UNCLAIMED’ if (HAS_FPGA_DBG_UNCLAIMED(i915)) ^~ drivers/gpu/drm/i915/selftests/intel_uncore.c: In function ‘live_forcewake_domains’: drivers/gpu/drm/i915/i915_drv.h:1697:65: error: ‘const struct intel_device_info’ has no member named ‘has_fpga_dbg’; did you mean ‘has_gt_uc’? #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg) ^~~~ drivers/gpu/drm/i915/selftests/intel_uncore.c:265:7: note: in expansion of macro ‘HAS_FPGA_DBG_UNCLAIMED’ if (!HAS_FPGA_DBG_UNCLAIMED(gt->i915) && ^~ scripts/Makefile.build:279: recipe for target 'drivers/gpu/drm/i915/intel_uncore.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_uncore.o] Error 1 scripts/Makefile.build:496: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:496: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:496: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1800: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Try to detect sudden loss of MMIO access
In rare circumstances bugs in PCI programming, broken BIOS, or failing hardware can cause the CPU to lose access to the MMIO BAR on dgfx platforms. This is a pretty catastrophic failure since all register reads come back with values of 0x. Let's check for this special case while doing our usual checks for unclaimed registers; the FPGA_DBG register we use for those checks on modern platforms has some unused bits that will always read back as 0 when things are behaving properly; we can use them as canaries to detect when MMIO itself has suddenly broken and try to print a more informative error message in the logs. v2: Let the detection function still return 'true' if we've lost our MMIO access. We'll still get an extra false positive message about an unclaimed register access, but we'll still honor the 'mmio_debug' limit and not spam the log. (Lucas) Cc: Lucas De Marchi Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_uncore.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 5098f95d71b0..661b50191f2b 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -465,6 +465,22 @@ fpga_check_for_unclaimed_mmio(struct intel_uncore *uncore) if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM))) return false; + /* +* Bugs in PCI programming (or failing hardware) can occasionally cause +* us to lose access to the MMIO BAR. When this happens, register +* reads will come back with 0x for every register and things +* go bad very quickly. Let's try to detect that special case and at +* least try to print a more informative message about what has +* happened. +* +* During normal operation the FPGA_DBG register has several unused +* bits that will always read back as 0's so we can use them as canaries +* to recognize when MMIO accesses are just busted. +*/ + if (unlikely(dbg == ~0)) + drm_err(>i915->drm, + "Lost access to MMIO BAR; all registers now read back as 0x!\n"); + __raw_uncore_write32(uncore, FPGA_DBG, FPGA_DBG_RM_NOCLAIM); return true; -- 2.25.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: FPGA_DBG is display-specific
Although the bspec's description doesn't make it very clear, the
hardware architects have confirmed that the FPGA_DBG register that we
use to check for unclaimed MMIO accesses is display-specific and will
only properly flag unclaimed MMIO transactions for registers in the
display range. If a platform doesn't have display, FPGA_DBG itself will
not be available and should not be checked. Let's move the feature flag
into intel_device_info.display to more accurately reflect this.
Given that we now know FPGA_DBG is display-specific, it could be argued
that we should only check it on out intel_de_*() functions. However
let's not make that change right now; keeping the checks in all of the
existing locations still helps us catch cases where regular
intel_uncore_*() functions use bad MMIO offset math / base addresses and
accidentally wind up landing within an unused area within the display
MMIO range. It will also help catch cases where userspace-initiated
MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the
display range.
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c | 4 ++--
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index eff7155db2fd..a9f24f2bda33 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -538,7 +538,7 @@ static const struct intel_device_info vlv_info = {
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) | \
BIT(TRANSCODER_C) | BIT(TRANSCODER_EDP), \
.display.has_ddi = 1, \
- .has_fpga_dbg = 1, \
+ .display.has_fpga_dbg = 1, \
.display.has_psr = 1, \
.display.has_psr_hw_tracking = 1, \
.display.has_dp_mst = 1, \
@@ -689,7 +689,7 @@ static const struct intel_device_info skl_gt4_info = {
BIT(TRANSCODER_DSI_A) | BIT(TRANSCODER_DSI_C), \
.has_64bit_reloc = 1, \
.display.has_ddi = 1, \
- .has_fpga_dbg = 1, \
+ .display.has_fpga_dbg = 1, \
.display.has_fbc = 1, \
.display.has_hdcp = 1, \
.display.has_psr = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index e6ca1023ffcf..d44f64b57b7a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -118,7 +118,6 @@ enum intel_ppgtt_type {
func(has_64bit_reloc); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
- func(has_fpga_dbg); \
func(has_global_mocs); \
func(has_gt_uc); \
func(has_l3_dpf); \
@@ -145,6 +144,7 @@ enum intel_ppgtt_type {
func(has_dsb); \
func(has_dsc); \
func(has_fbc); \
+ func(has_fpga_dbg); \
func(has_gmch); \
func(has_hdcp); \
func(has_hotplug); \
--
2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
On Fri, Feb 12, 2021 at 07:42:17PM +, Souza, Jose wrote:
> On Fri, 2021-02-12 at 21:20 +0200, Ville Syrjälä wrote:
> > On Fri, Feb 12, 2021 at 10:21:59AM -0800, José Roberto de Souza wrote:
> > > The cfgcr0/1_clk_off mapping is wrong for adl-s what could cause
> > > the wrong clock being disabled and leaving a not needed clock
> > > running consuming more power than needed.
> > >
> > > Bspec: 50287
> > > Bspec: 53812
> > > Bspec: 53723
> > > Fixes: d6d2bc996e45 ("drm/i915/adl_s: Configure Port clock registers for
> > > ADL-S")
> > > Cc: Aditya Swarup
> > > Cc: Lucas De Marchi
> > > Cc: Matt Roper
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> > > drivers/gpu/drm/i915/i915_reg.h | 12
> > > 2 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 2d6906f6995f..7631e080349d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -1585,7 +1585,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp,
> > > static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
> > >enum phy phy)
> > > {
> > > - if (IS_ROCKETLAKE(dev_priv)) {
> > > + if (IS_ALDERLAKE_S(dev_priv)) {
> > > + return ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy);
> > > + } else if (IS_ROCKETLAKE(dev_priv)) {
> > > return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> > > } else if (intel_phy_is_combo(dev_priv, phy)) {
> > > return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 224ad897af34..7c69b50ccc5c 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -10416,6 +10416,18 @@ enum skl_power_gate {
> > >
> > > ADLS_DPCLKA_DDIJ_SEL_MASK, \
> > >
> > > ADLS_DPCLKA_DDIK_SEL_MASK)
> > >
> > >
> > > +#define _ADLS_DPCLKA_DDIA_CLK_OFFREG_BIT(10)
> > > +#define _ADLS_DPCLKA_DDIB_CLK_OFFREG_BIT(11)
> > > +#define _ADLS_DPCLKA_DDII_CLK_OFFREG_BIT(24)
> > > +#define _ADLS_DPCLKA_DDIJ_CLK_OFFREG_BIT(4)
> > > +#define _ADLS_DPCLKA_DDIK_CLK_OFFREG_BIT(5)
> >
> > So shose are apparently split between the two registers. Why aren't
> > we defining these so that it would be obvious which register they
> > live in? This stuff is confusing enough with the hw folks churning
> > the bits around randomly on every platform, so I don't think we
> > should add to the confusion by obfuscating the bit defines. I do
> > like that you named the bits, which isn't case for the other
> > platforms. Would be nice to fix it all up actually.
> >
> > Hmm. However, this new defintion seem to match
> > ICL_DPCLKA_CFGCR0_DDI_CLK_OFF() 100%. So how can this be fixing
> > something? Also ICL for sure can't have that many combo PHYs can
> > it? We should nuke the extra stuff from the ICL defintion if it's
> > no longer used.
>
> Good catch & my bad.
> Was fixing it for other platform and tought that it might be broken
> for ADL-S too but as all ports are combo ports
> ICL_DPCLKA_CFGCR0_DDI_CLK_OFF will do the right job.
>
> Dropping this patch.
I wouldn't mind having this patch, or rather a patch to clean up/clarify
all the DPCLKA_CFGCR bits on every platform. As it stands cross checking
against the spec is a bit tedious.
But at least right now I don't have to rebase my DDI clock routing
series [1] :) That one still has a few trivial patches looking for review
btw *wink* *nudge*.
[1] https://patchwork.freedesktop.org/series/86544/
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches
On Fri, Feb 12, 2021 at 07:44:22PM +, Souza, Jose wrote:
> On Fri, 2021-02-12 at 20:35 +0200, Ville Syrjälä wrote:
> > On Fri, Feb 12, 2021 at 10:22:01AM -0800, José Roberto de Souza wrote:
> > > Found a system were firmware/BIOS left the plane_res_b and plane_res_l
> > > set with non-zero values for disable planes.
> >
> > It pretty much happens always since the reset value is not zero.
> > IIRC we made the state chcker pedantic enough to complain about
> > that, so we need to clean it up.
>
> Are you planning to fix it soon?
Fix what exactly? I guess you're seeing an actual problem of some sort?
> If not I can do it but will need a couple more of hints of what you
> thinking to do.
>
> We will need this fixed soon otherwise this system will block CI
> testing in this platform.
>
> >
> > > As the planes are disabled i915 will not even try to sanitize it so
> > > here returning earlier if both skl_wm_levels being compared are
> > > disabled, if that is true no need to check the other fields as HW
> > > will ignore it.
> > >
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 8cc67f9c4e58..c630dc10c34b 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -5633,6 +5633,8 @@ void skl_write_cursor_wm(struct intel_plane *plane,
> > > bool skl_wm_level_equals(const struct skl_wm_level *l1,
> > >const struct skl_wm_level *l2)
> > > {
> > > + if (l1->plane_en == false && l2->plane_en == false)
> > > + return true;
> > > return l1->plane_en == l2->plane_en &&
> > > l1->ignore_lines == l2->ignore_lines &&
> > > l1->plane_res_l == l2->plane_res_l &&
> > > --
> > > 2.30.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
>
--
Ville Syrjälä
Intel
___
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/gen9bc: Handle TGP PCH during suspend/resume (rev2)
== Series Details == Series: drm/i915/gen9bc: Handle TGP PCH during suspend/resume (rev2) URL : https://patchwork.freedesktop.org/series/86346/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9771_full -> Patchwork_19673_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19673_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19673_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_19673_full: ### IGT changes ### Possible regressions * igt@kms_sequence@queue-busy: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-skl4/igt@kms_seque...@queue-busy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-skl10/igt@kms_seque...@queue-busy.html Known issues Here are the changes found in Patchwork_19673_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-glk9/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-apl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-iclb7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-iclb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_params@secure-non-master: - shard-tglb: NOTRUN -> [SKIP][13] ([fdo#112283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-tglb6/igt@gem_exec_par...@secure-non-master.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-apl6/igt@gem_soft...@noreloc-s3.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-apl2/igt@gem_soft...@noreloc-s3.html * igt@gem_workarounds@suspend-resume-fd: - shard-apl: NOTRUN -> [DMESG-WARN][16] ([i915#180]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-apl7/igt@gem_workarou...@suspend-resume-fd.html * igt@gen9_exec_parse@secure-batches: - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#112306]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-tglb6/igt@gen9_exec_pa...@secure-batches.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271]) +65 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-apl1/igt@i915_pm_...@modeset-lpsp-stress.html * igt@kms_async_flips@test-time-stamp: - shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2597]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-tglb5/igt@kms_async_fl...@test-time-stamp.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-tglb7/igt@kms_async_fl...@test-time-stamp.html * igt@kms_big_fb@yf-tiled-8bpp-rotate-0: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111615]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/shard-tglb6/igt@kms_big...@yf-tiled-8bpp-rotate-0.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180: - shard-skl: NOTRUN -> [SKIP][22]
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
== Series Details == Series: series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping URL : https://patchwork.freedesktop.org/series/87048/ State : success == Summary == CI Bug Log - changes from CI_DRM_9771_full -> Patchwork_19672_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19672_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-glk: [PASS][1] -> [TIMEOUT][2] ([i915#2918]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-glk4/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-glk9/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-iclb7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-iclb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@secure-non-master: - shard-tglb: NOTRUN -> [SKIP][11] ([fdo#112283]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-tglb3/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-iclb: [PASS][12] -> [DMESG-WARN][13] ([i915#2803]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-iclb6/igt@gem_exec_schedule@u-fairsl...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-iclb4/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-kbl4/igt@gem_exec_susp...@basic-s3.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-kbl7/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_whisper@basic-queues-forked: - shard-glk: [PASS][16] -> [DMESG-WARN][17] ([i915#118] / [i915#95]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-glk7/igt@gem_exec_whis...@basic-queues-forked.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-glk3/igt@gem_exec_whis...@basic-queues-forked.html * igt@gen9_exec_parse@secure-batches: - shard-tglb: NOTRUN -> [SKIP][18] ([fdo#112306]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-tglb3/igt@gen9_exec_pa...@secure-batches.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#2521]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-kbl3/igt@kms_async_fl...@alternate-sync-async-flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-kbl2/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_big_fb@yf-tiled-8bpp-rotate-0: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111615]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-tglb3/igt@kms_big...@yf-tiled-8bpp-rotate-0.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180: - shard-skl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111304]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-skl8/igt@kms_...@pipe-c-crc-primary-rotation-180.html * igt@kms_chamelium@hdmi-hpd-storm: - shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271] / [fdo#111827]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/shard-kbl2/igt@kms_chamel...@hdmi-hpd-storm.html *
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches
On Fri, 2021-02-12 at 20:35 +0200, Ville Syrjälä wrote:
> On Fri, Feb 12, 2021 at 10:22:01AM -0800, José Roberto de Souza wrote:
> > Found a system were firmware/BIOS left the plane_res_b and plane_res_l
> > set with non-zero values for disable planes.
>
> It pretty much happens always since the reset value is not zero.
> IIRC we made the state chcker pedantic enough to complain about
> that, so we need to clean it up.
Are you planning to fix it soon?
If not I can do it but will need a couple more of hints of what you
thinking to do.
We will need this fixed soon otherwise this system will block CI
testing in this platform.
>
> > As the planes are disabled i915 will not even try to sanitize it so
> > here returning earlier if both skl_wm_levels being compared are
> > disabled, if that is true no need to check the other fields as HW
> > will ignore it.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 8cc67f9c4e58..c630dc10c34b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5633,6 +5633,8 @@ void skl_write_cursor_wm(struct intel_plane *plane,
> > bool skl_wm_level_equals(const struct skl_wm_level *l1,
> > const struct skl_wm_level *l2)
> > {
> > + if (l1->plane_en == false && l2->plane_en == false)
> > + return true;
> > return l1->plane_en == l2->plane_en &&
> > l1->ignore_lines == l2->ignore_lines &&
> > l1->plane_res_l == l2->plane_res_l &&
> > --
> > 2.30.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] [PATCH 1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
On Fri, 2021-02-12 at 21:20 +0200, Ville Syrjälä wrote:
> On Fri, Feb 12, 2021 at 10:21:59AM -0800, José Roberto de Souza wrote:
> > The cfgcr0/1_clk_off mapping is wrong for adl-s what could cause
> > the wrong clock being disabled and leaving a not needed clock
> > running consuming more power than needed.
> >
> > Bspec: 50287
> > Bspec: 53812
> > Bspec: 53723
> > Fixes: d6d2bc996e45 ("drm/i915/adl_s: Configure Port clock registers for
> > ADL-S")
> > Cc: Aditya Swarup
> > Cc: Lucas De Marchi
> > Cc: Matt Roper
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 12
> > 2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 2d6906f6995f..7631e080349d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1585,7 +1585,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp,
> > static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
> > enum phy phy)
> > {
> > - if (IS_ROCKETLAKE(dev_priv)) {
> > + if (IS_ALDERLAKE_S(dev_priv)) {
> > + return ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy);
> > + } else if (IS_ROCKETLAKE(dev_priv)) {
> > return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> > } else if (intel_phy_is_combo(dev_priv, phy)) {
> > return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 224ad897af34..7c69b50ccc5c 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -10416,6 +10416,18 @@ enum skl_power_gate {
> >
> > ADLS_DPCLKA_DDIJ_SEL_MASK, \
> >
> > ADLS_DPCLKA_DDIK_SEL_MASK)
> >
> >
> > +#define _ADLS_DPCLKA_DDIA_CLK_OFF REG_BIT(10)
> > +#define _ADLS_DPCLKA_DDIB_CLK_OFF REG_BIT(11)
> > +#define _ADLS_DPCLKA_DDII_CLK_OFF REG_BIT(24)
> > +#define _ADLS_DPCLKA_DDIJ_CLK_OFF REG_BIT(4)
> > +#define _ADLS_DPCLKA_DDIK_CLK_OFF REG_BIT(5)
>
> So shose are apparently split between the two registers. Why aren't
> we defining these so that it would be obvious which register they
> live in? This stuff is confusing enough with the hw folks churning
> the bits around randomly on every platform, so I don't think we
> should add to the confusion by obfuscating the bit defines. I do
> like that you named the bits, which isn't case for the other
> platforms. Would be nice to fix it all up actually.
>
> Hmm. However, this new defintion seem to match
> ICL_DPCLKA_CFGCR0_DDI_CLK_OFF() 100%. So how can this be fixing
> something? Also ICL for sure can't have that many combo PHYs can
> it? We should nuke the extra stuff from the ICL defintion if it's
> no longer used.
Good catch & my bad.
Was fixing it for other platform and tought that it might be broken
for ADL-S too but as all ports are combo ports
ICL_DPCLKA_CFGCR0_DDI_CLK_OFF will do the right job.
Dropping this patch.
>
> > +#define ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy) _PICK((phy), \
> > +
> > _ADLS_DPCLKA_DDIA_CLK_OFF, \
> > +
> > _ADLS_DPCLKA_DDIB_CLK_OFF, \
> > +
> > _ADLS_DPCLKA_DDII_CLK_OFF, \
> > +
> > _ADLS_DPCLKA_DDIJ_CLK_OFF, \
> > +
> > _ADLS_DPCLKA_DDIK_CLK_OFF)
> > +
> > /* CNL PLL */
> > #define DPLL0_ENABLE 0x46010
> > #define DPLL1_ENABLE 0x46014
> > --
> > 2.30.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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9bc: Handle TGP PCH during suspend/resume (rev2)
== Series Details == Series: drm/i915/gen9bc: Handle TGP PCH during suspend/resume (rev2) URL : https://patchwork.freedesktop.org/series/86346/ State : success == Summary == CI Bug Log - changes from CI_DRM_9771 -> Patchwork_19673 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/index.html Known issues Here are the changes found in Patchwork_19673 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@userptr: - fi-byt-j1900: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html * igt@gem_render_tiled_blits@basic: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html Possible fixes * igt@gem_linear_blits@basic: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-tgl-y/igt@gem_linear_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/fi-tgl-y/igt@gem_linear_bl...@basic.html * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [INCOMPLETE][7] ([i915#142] / [i915#2405]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-byt-j1900/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/fi-byt-j1900/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (45 -> 39) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-ehl-2 fi-bdw-samus Build changes - * Linux: CI_DRM_9771 -> Patchwork_19673 CI-20190529: 20190529 CI_DRM_9771: 1b095889c6780e40f6161bfb824b5e944fd69547 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19673: 1ffa579a6e3408e1a4033b88eb5ab0a4186f82a5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1ffa579a6e34 drm/i915/gen9bc: Handle TGP PCH during suspend/resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19673/index.html ___ 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/audio: set HDA link parameters in driver
== Series Details == Series: drm/i915/audio: set HDA link parameters in driver URL : https://patchwork.freedesktop.org/series/87040/ State : success == Summary == CI Bug Log - changes from CI_DRM_9771_full -> Patchwork_19671_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19671_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-flow@rcs0: - shard-apl: [PASS][1] -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-apl6/igt@gem_exec_fair@basic-f...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-apl2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-tglb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-iclb7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-iclb7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_params@secure-non-master: - shard-tglb: NOTRUN -> [SKIP][11] ([fdo#112283]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-tglb8/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-iclb: [PASS][12] -> [DMESG-WARN][13] ([i915#2803]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-iclb6/igt@gem_exec_schedule@u-fairsl...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-iclb1/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_vm_create@destroy-race: - shard-tglb: [PASS][14] -> [TIMEOUT][15] ([i915#2795]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-tglb2/igt@gem_vm_cre...@destroy-race.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-tglb2/igt@gem_vm_cre...@destroy-race.html * igt@gen3_mixed_blits: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271]) +58 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-kbl6/igt@gen3_mixed_blits.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1436] / [i915#716]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-skl8/igt@gen9_exec_pa...@allowed-single.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-skl2/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@secure-batches: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#112306]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-tglb8/igt@gen9_exec_pa...@secure-batches.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271]) +33 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-apl4/igt@i915_pm_...@modeset-lpsp-stress.html * igt@i915_suspend@forcewake: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/shard-apl2/igt@i915_susp...@forcewake.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-apl3/igt@i915_susp...@forcewake.html * igt@kms_big_fb@yf-tiled-8bpp-rotate-0: - shard-tglb: NOTRUN -> [SKIP][23] ([fdo#111615]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/shard-tglb8/igt@kms_big...@yf-tiled-8bpp-rotate-0.html * igt@kms_ccs@pipe-c-crc-primary-rotation-180: - shard-skl: NOTRUN -> [SKIP][24] ([fdo#109271] / [fdo#111304]) [24]:
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
On Fri, Feb 12, 2021 at 10:21:59AM -0800, José Roberto de Souza wrote:
> The cfgcr0/1_clk_off mapping is wrong for adl-s what could cause
> the wrong clock being disabled and leaving a not needed clock
> running consuming more power than needed.
>
> Bspec: 50287
> Bspec: 53812
> Bspec: 53723
> Fixes: d6d2bc996e45 ("drm/i915/adl_s: Configure Port clock registers for
> ADL-S")
> Cc: Aditya Swarup
> Cc: Lucas De Marchi
> Cc: Matt Roper
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> drivers/gpu/drm/i915/i915_reg.h | 12
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2d6906f6995f..7631e080349d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1585,7 +1585,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp,
> static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
>enum phy phy)
> {
> - if (IS_ROCKETLAKE(dev_priv)) {
> + if (IS_ALDERLAKE_S(dev_priv)) {
> + return ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy);
> + } else if (IS_ROCKETLAKE(dev_priv)) {
> return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> } else if (intel_phy_is_combo(dev_priv, phy)) {
> return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 224ad897af34..7c69b50ccc5c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10416,6 +10416,18 @@ enum skl_power_gate {
>
> ADLS_DPCLKA_DDIJ_SEL_MASK, \
>
> ADLS_DPCLKA_DDIK_SEL_MASK)
>
> +#define _ADLS_DPCLKA_DDIA_CLK_OFFREG_BIT(10)
> +#define _ADLS_DPCLKA_DDIB_CLK_OFFREG_BIT(11)
> +#define _ADLS_DPCLKA_DDII_CLK_OFFREG_BIT(24)
> +#define _ADLS_DPCLKA_DDIJ_CLK_OFFREG_BIT(4)
> +#define _ADLS_DPCLKA_DDIK_CLK_OFFREG_BIT(5)
So shose are apparently split between the two registers. Why aren't
we defining these so that it would be obvious which register they
live in? This stuff is confusing enough with the hw folks churning
the bits around randomly on every platform, so I don't think we
should add to the confusion by obfuscating the bit defines. I do
like that you named the bits, which isn't case for the other
platforms. Would be nice to fix it all up actually.
Hmm. However, this new defintion seem to match
ICL_DPCLKA_CFGCR0_DDI_CLK_OFF() 100%. So how can this be fixing
something? Also ICL for sure can't have that many combo PHYs can
it? We should nuke the extra stuff from the ICL defintion if it's
no longer used.
> +#define ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy) _PICK((phy), \
> +
> _ADLS_DPCLKA_DDIA_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDIB_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDII_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDIJ_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDIK_CLK_OFF)
> +
> /* CNL PLL */
> #define DPLL0_ENABLE 0x46010
> #define DPLL1_ENABLE 0x46014
> --
> 2.30.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
On 2/12/21 10:21 AM, José Roberto de Souza wrote:
> The cfgcr0/1_clk_off mapping is wrong for adl-s what could cause
> the wrong clock being disabled and leaving a not needed clock
> running consuming more power than needed.
>
> Bspec: 50287
> Bspec: 53812
> Bspec: 53723
> Fixes: d6d2bc996e45 ("drm/i915/adl_s: Configure Port clock registers for
> ADL-S")
> Cc: Aditya Swarup
> Cc: Lucas De Marchi
> Cc: Matt Roper
> Signed-off-by: José Roberto de Souza
Changes look correct to me based on the table from Bspec: 53723 and is
required. Mistake on my part on
missing those changes.
Reviewed-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> drivers/gpu/drm/i915/i915_reg.h | 12
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2d6906f6995f..7631e080349d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1585,7 +1585,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp,
> static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
>enum phy phy)
> {
> - if (IS_ROCKETLAKE(dev_priv)) {
> + if (IS_ALDERLAKE_S(dev_priv)) {
> + return ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy);
> + } else if (IS_ROCKETLAKE(dev_priv)) {
> return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> } else if (intel_phy_is_combo(dev_priv, phy)) {
> return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 224ad897af34..7c69b50ccc5c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10416,6 +10416,18 @@ enum skl_power_gate {
>
> ADLS_DPCLKA_DDIJ_SEL_MASK, \
>
> ADLS_DPCLKA_DDIK_SEL_MASK)
>
> +#define _ADLS_DPCLKA_DDIA_CLK_OFFREG_BIT(10)
> +#define _ADLS_DPCLKA_DDIB_CLK_OFFREG_BIT(11)
> +#define _ADLS_DPCLKA_DDII_CLK_OFFREG_BIT(24)
> +#define _ADLS_DPCLKA_DDIJ_CLK_OFFREG_BIT(4)
> +#define _ADLS_DPCLKA_DDIK_CLK_OFFREG_BIT(5)
> +#define ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy) _PICK((phy), \
> +
> _ADLS_DPCLKA_DDIA_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDIB_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDII_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDIJ_CLK_OFF, \
> +
> _ADLS_DPCLKA_DDIK_CLK_OFF)
> +
> /* CNL PLL */
> #define DPLL0_ENABLE 0x46010
> #define DPLL1_ENABLE 0x46014
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
== Series Details == Series: series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping URL : https://patchwork.freedesktop.org/series/87048/ State : success == Summary == CI Bug Log - changes from CI_DRM_9771 -> Patchwork_19672 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/index.html Known issues Here are the changes found in Patchwork_19672 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/fi-tgl-y/igt@amdgpu/amd_ba...@cs-compute.html * igt@amdgpu/amd_basic@userptr: - fi-byt-j1900: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html * igt@prime_vgem@basic-read: - 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_9771/fi-tgl-y/igt@prime_v...@basic-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/fi-tgl-y/igt@prime_v...@basic-read.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [INCOMPLETE][5] ([i915#142] / [i915#2405]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-byt-j1900/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (45 -> 40) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9771 -> Patchwork_19672 CI-20190529: 20190529 CI_DRM_9771: 1b095889c6780e40f6161bfb824b5e944fd69547 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19672: a6c0f3b65b649c2ce7910c3384ce168faa3bfd16 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a6c0f3b65b64 drm/i915: Fix plane watermark mismatches 6766f32463c4 drm/i915: Remove dead code from skl_pipe_wm_get_hw_state() cc5ee23b6a3e drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19672/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gen9bc: Handle TGP PCH during suspend/resume
From: Tejas Upadhyay
For Legacy S3 suspend/resume GEN9 BC needs to enable and
setup TGP PCH.
v2:
* Move Wa_14010685332 into it's own function - vsyrjala
* Add TODO comment about figuring out if we can move this workaround - imre
Cc: Matt Roper
Signed-off-by: Tejas Upadhyay
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/i915_irq.c | 53 ++---
1 file changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 98145a7f28a4..7d912aa950ee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3040,6 +3040,19 @@ static void valleyview_irq_reset(struct drm_i915_private
*dev_priv)
spin_unlock_irq(_priv->irq_lock);
}
+static void cnp_irq_post_reset(struct drm_i915_private *dev_priv)
+{
+ struct intel_uncore *uncore = _priv->uncore;
+
+ /*
+* Wa_14010685332:cnp/cmp,tgp,adp
+* TODO: Figure out if this workaround can be applied in the s0ix
suspend/resume handlers as
+* on earlier platforms and whether the workaround is also needed for
runtime suspend/resume
+*/
+ intel_uncore_rmw(uncore, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
SBCLK_RUN_REFCLK_DIS);
+ intel_uncore_rmw(uncore, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS, 0);
+}
+
static void gen8_irq_reset(struct drm_i915_private *dev_priv)
{
struct intel_uncore *uncore = _priv->uncore;
@@ -3061,8 +3074,14 @@ static void gen8_irq_reset(struct drm_i915_private
*dev_priv)
GEN3_IRQ_RESET(uncore, GEN8_DE_MISC_);
GEN3_IRQ_RESET(uncore, GEN8_PCU_);
- if (HAS_PCH_SPLIT(dev_priv))
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
+ GEN3_IRQ_RESET(uncore, SDE);
+ else if (HAS_PCH_SPLIT(dev_priv))
ibx_irq_reset(dev_priv);
+
+ if (INTEL_PCH_TYPE(dev_priv) == PCH_CNP ||
+ (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP && INTEL_PCH_TYPE(dev_priv) <
PCH_DG1))
+ cnp_irq_post_reset(dev_priv);
}
static void gen11_display_irq_reset(struct drm_i915_private *dev_priv)
@@ -3104,15 +3123,9 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
GEN3_IRQ_RESET(uncore, SDE);
- /* Wa_14010685332:cnp/cmp,tgp,adp */
if (INTEL_PCH_TYPE(dev_priv) == PCH_CNP ||
- (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP &&
-INTEL_PCH_TYPE(dev_priv) < PCH_DG1)) {
- intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
-SBCLK_RUN_REFCLK_DIS, SBCLK_RUN_REFCLK_DIS);
- intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
-SBCLK_RUN_REFCLK_DIS, 0);
- }
+ (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP && INTEL_PCH_TYPE(dev_priv) <
PCH_DG1))
+ cnp_irq_post_reset(dev_priv);
}
static void gen11_irq_reset(struct drm_i915_private *dev_priv)
@@ -3474,6 +3487,9 @@ static void spt_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
spt_hpd_detection_setup(dev_priv);
+
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
+ icp_hpd_irq_setup(dev_priv);
}
static u32 ilk_hotplug_enables(struct drm_i915_private *i915,
@@ -3764,9 +3780,19 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
}
}
+static void icp_irq_postinstall(struct drm_i915_private *dev_priv)
+{
+ struct intel_uncore *uncore = _priv->uncore;
+ u32 mask = SDE_GMBUS_ICP;
+
+ GEN3_IRQ_INIT(uncore, SDE, ~mask, 0x);
+}
+
static void gen8_irq_postinstall(struct drm_i915_private *dev_priv)
{
- if (HAS_PCH_SPLIT(dev_priv))
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
+ icp_irq_postinstall(dev_priv);
+ else if (HAS_PCH_SPLIT(dev_priv))
ibx_irq_postinstall(dev_priv);
gen8_gt_irq_postinstall(_priv->gt);
@@ -3775,13 +3801,6 @@ static void gen8_irq_postinstall(struct drm_i915_private
*dev_priv)
gen8_master_intr_enable(dev_priv->uncore.regs);
}
-static void icp_irq_postinstall(struct drm_i915_private *dev_priv)
-{
- struct intel_uncore *uncore = _priv->uncore;
- u32 mask = SDE_GMBUS_ICP;
-
- GEN3_IRQ_INIT(uncore, SDE, ~mask, 0x);
-}
static void gen11_irq_postinstall(struct drm_i915_private *dev_priv)
{
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches
On Fri, Feb 12, 2021 at 10:22:01AM -0800, José Roberto de Souza wrote:
> Found a system were firmware/BIOS left the plane_res_b and plane_res_l
> set with non-zero values for disable planes.
It pretty much happens always since the reset value is not zero.
IIRC we made the state chcker pedantic enough to complain about
that, so we need to clean it up.
> As the planes are disabled i915 will not even try to sanitize it so
> here returning earlier if both skl_wm_levels being compared are
> disabled, if that is true no need to check the other fields as HW
> will ignore it.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8cc67f9c4e58..c630dc10c34b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5633,6 +5633,8 @@ void skl_write_cursor_wm(struct intel_plane *plane,
> bool skl_wm_level_equals(const struct skl_wm_level *l1,
>const struct skl_wm_level *l2)
> {
> + if (l1->plane_en == false && l2->plane_en == false)
> + return true;
> return l1->plane_en == l2->plane_en &&
> l1->ignore_lines == l2->ignore_lines &&
> l1->plane_res_l == l2->plane_res_l &&
> --
> 2.30.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove dead code from skl_pipe_wm_get_hw_state()
On Fri, Feb 12, 2021 at 10:22:00AM -0800, José Roberto de Souza wrote: > There is nothing else to be executed after this if block. > > Signed-off-by: José Roberto de Souza Looks like leftovers I forgot to clean up. Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 8c42fa51c0f6..8cc67f9c4e58 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -6182,9 +6182,6 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc, > > skl_wm_level_from_reg_val(val, >trans_wm); > } > - > - if (!crtc->active) > - return; > } > > void skl_wm_get_hw_state(struct drm_i915_private *dev_priv) > -- > 2.30.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
== Series Details == Series: series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping URL : https://patchwork.freedesktop.org/series/87048/ 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/gt/intel_reset.c:1323: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:1437:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1491:15: warning: memset with byte count of 16777216 +./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' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
== Series Details == Series: series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping URL : https://patchwork.freedesktop.org/series/87048/ State : warning == Summary == $ dim checkpatch origin/drm-tip cc5ee23b6a3e drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping 6766f32463c4 drm/i915: Remove dead code from skl_pipe_wm_get_hw_state() a6c0f3b65b64 drm/i915: Fix plane watermark mismatches -:26: CHECK:BOOL_COMPARISON: Using comparison to false is error prone #26: FILE: drivers/gpu/drm/i915/intel_pm.c:5636: + if (l1->plane_en == false && l2->plane_en == false) total: 0 errors, 0 warnings, 1 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Remove dead code from skl_pipe_wm_get_hw_state()
There is nothing else to be executed after this if block. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_pm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 8c42fa51c0f6..8cc67f9c4e58 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6182,9 +6182,6 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc, skl_wm_level_from_reg_val(val, >trans_wm); } - - if (!crtc->active) - return; } void skl_wm_get_hw_state(struct drm_i915_private *dev_priv) -- 2.30.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping
The cfgcr0/1_clk_off mapping is wrong for adl-s what could cause
the wrong clock being disabled and leaving a not needed clock
running consuming more power than needed.
Bspec: 50287
Bspec: 53812
Bspec: 53723
Fixes: d6d2bc996e45 ("drm/i915/adl_s: Configure Port clock registers for ADL-S")
Cc: Aditya Swarup
Cc: Lucas De Marchi
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
drivers/gpu/drm/i915/i915_reg.h | 12
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2d6906f6995f..7631e080349d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1585,7 +1585,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp,
static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
enum phy phy)
{
- if (IS_ROCKETLAKE(dev_priv)) {
+ if (IS_ALDERLAKE_S(dev_priv)) {
+ return ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy);
+ } else if (IS_ROCKETLAKE(dev_priv)) {
return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
} else if (intel_phy_is_combo(dev_priv, phy)) {
return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 224ad897af34..7c69b50ccc5c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10416,6 +10416,18 @@ enum skl_power_gate {
ADLS_DPCLKA_DDIJ_SEL_MASK, \
ADLS_DPCLKA_DDIK_SEL_MASK)
+#define _ADLS_DPCLKA_DDIA_CLK_OFF REG_BIT(10)
+#define _ADLS_DPCLKA_DDIB_CLK_OFF REG_BIT(11)
+#define _ADLS_DPCLKA_DDII_CLK_OFF REG_BIT(24)
+#define _ADLS_DPCLKA_DDIJ_CLK_OFF REG_BIT(4)
+#define _ADLS_DPCLKA_DDIK_CLK_OFF REG_BIT(5)
+#define ADLS_DPCLKA_CFGCR_DDI_CLK_OFF(phy) _PICK((phy), \
+
_ADLS_DPCLKA_DDIA_CLK_OFF, \
+
_ADLS_DPCLKA_DDIB_CLK_OFF, \
+
_ADLS_DPCLKA_DDII_CLK_OFF, \
+
_ADLS_DPCLKA_DDIJ_CLK_OFF, \
+
_ADLS_DPCLKA_DDIK_CLK_OFF)
+
/* CNL PLL */
#define DPLL0_ENABLE 0x46010
#define DPLL1_ENABLE 0x46014
--
2.30.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches
Found a system were firmware/BIOS left the plane_res_b and plane_res_l
set with non-zero values for disable planes.
As the planes are disabled i915 will not even try to sanitize it so
here returning earlier if both skl_wm_levels being compared are
disabled, if that is true no need to check the other fields as HW
will ignore it.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8cc67f9c4e58..c630dc10c34b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5633,6 +5633,8 @@ void skl_write_cursor_wm(struct intel_plane *plane,
bool skl_wm_level_equals(const struct skl_wm_level *l1,
const struct skl_wm_level *l2)
{
+ if (l1->plane_en == false && l2->plane_en == false)
+ return true;
return l1->plane_en == l2->plane_en &&
l1->ignore_lines == l2->ignore_lines &&
l1->plane_res_l == l2->plane_res_l &&
--
2.30.1
___
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/audio: set HDA link parameters in driver
== Series Details == Series: drm/i915/audio: set HDA link parameters in driver URL : https://patchwork.freedesktop.org/series/87040/ State : success == Summary == CI Bug Log - changes from CI_DRM_9771 -> Patchwork_19671 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/index.html Known issues Here are the changes found in Patchwork_19671 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-byt-j1900: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html * igt@prime_self_import@basic-with_one_bo: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [INCOMPLETE][4] ([i915#142] / [i915#2405]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-byt-j1900/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@prime_self_import@basic-with_one_bo_two_files: - 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_9771/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (45 -> 40) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9771 -> Patchwork_19671 CI-20190529: 20190529 CI_DRM_9771: 1b095889c6780e40f6161bfb824b5e944fd69547 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6003: 627cc5353535d61fa33c5f7ff7e64f154c84f10a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19671: 5bbdfd09dd7825215e43fb824c5117577e5dbf56 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5bbdfd09dd78 drm/i915/audio: set HDA link parameters in driver == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19671/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "HAX sound: Disable probing snd_hda with DG1"
== Series Details ==
Series: Revert "HAX sound: Disable probing snd_hda with DG1"
URL : https://patchwork.freedesktop.org/series/87039/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9771 -> Patchwork_19670
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_19670 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19670, 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_19670/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19670:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-dg1-1}: NOTRUN -> [SKIP][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-dg1-1/igt@i915_pm_...@basic-pci-d3-state.html
Known issues
Here are the changes found in Patchwork_19670 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- {fi-dg1-1}: [FAIL][4] ([i915#2788]) -> [PASS][5]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-dg1-1/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-dg1-1/boot.html
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-byt-j1900: NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html
* igt@core_auth@basic-auth:
- fi-kbl-soraka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-kbl-soraka/igt@core_a...@basic-auth.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-kbl-soraka/igt@core_a...@basic-auth.html
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-tgl-y/igt@debugfs_test@read_all_entries.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][11] -> [FAIL][12] ([i915#1372])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][13] ([i915#1602] / [i915#2029] /
[i915#2369])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-bdw-5557u/igt@run...@aborted.html
- fi-bsw-n3050: NOTRUN -> [FAIL][14] ([i915#1436])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [INCOMPLETE][15] ([i915#142] / [i915#2405]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +2
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9771/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19670/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "HAX sound: Disable probing snd_hda with DG1"
== Series Details ==
Series: Revert "HAX sound: Disable probing snd_hda with DG1"
URL : https://patchwork.freedesktop.org/series/87039/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ef24b6852d1c Revert "HAX sound: Disable probing snd_hda with DG1"
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 69b08bdfa818 ("ALSA: hda - add
Intel DG1 PCI and HDMI ids")'
#9:
69b08bdfa818 ("ALSA: hda - add Intel DG1 PCI and HDMI ids").
total: 1 errors, 0 warnings, 0 checks, 43 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "HAX sound: Disable probing snd_hda with DG1"
Hi,
On Fri, 12 Feb 2021, Chris Wilson wrote:
> Quoting Kai Vehmanen (2021-02-12 14:53:02)
> > This reverts commit 3632610d38316bca9b0cd9d649ce3cefab58520a.
> >
> > DG1 has been supported in upstream since v5.10 with commit
> > 69b08bdfa818 ("ALSA: hda - add Intel DG1 PCI and HDMI ids").
>
> Exactly, otherwise this patch wouldn't have been required to stop CI
> from timing out upon snd probing the hdmi components. You need the other
> half to be supported as well before CI is ready.
aa, got it, so this is there as i915 doesn't have DG1 in i915_pci.c
id list. Right.
PS And indeed, the 60sec timeout in these cases is pretty annoying.
Br, Kai
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vbt: update DP max link rate table
On Thu, Feb 11, 2021 at 05:22:05AM +, Lee, Shawn C wrote:
>
> On Wed, Feb 10, 2021 at 04:51 p.m, Ville Syrjälä wrote:
> >On Mon, Feb 08, 2021 at 01:31:57PM +, Lee, Shawn C wrote:
> >> On Fri, Feb 05, 2021, at 8:26 p.m, Ville Syrjälä wrote:
> >> >On Mon, Feb 01, 2021 at 11:02:28PM +0800, Lee Shawn C wrote:
> >> >> According to Bspec #20124, max link rate table for DP was updated
> >> >> at BDB version 230. Max link rate can support upto UHBR.
> >> >>
> >> >> After migrate to BDB v230, the definition for LBR, HBR2 and HBR3
> >> >> were changed. For backward compatibility. If BDB version was from
> >> >> 216 to 229. Driver have to follow original rule to configure DP max
> >> >> link rate value from VBT.
> >> >>
> >> >> Cc: Ville Syrjala
> >> >> Cc: Imre Deak
> >> >> Cc: Jani Nikula
> >> >> Cc: Cooper Chiou
> >> >> Cc: William Tseng
> >> >> Signed-off-by: Lee Shawn C
> >> >> ---
> >> >> drivers/gpu/drm/i915/display/intel_bios.c | 24 ++-
> >> >> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 14 +++
> >> >> 2 files changed, 32 insertions(+), 6 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> >> >> b/drivers/gpu/drm/i915/display/intel_bios.c
> >> >> index 04337ac6f8c4..be1f732e6550 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> >> @@ -1876,7 +1876,15 @@ static void parse_ddi_port(struct
> >> >> drm_i915_private *dev_priv,
> >> >> /* DP max link rate for CNL+ */
> >> >> if (bdb_version >= 216) {
> >> >> switch (child->dp_max_link_rate) {
> >> >> - default:
> >> >> + case VBT_DP_MAX_LINK_RATE_UHBR20:
> >> >> + info->dp_max_link_rate = 200;
> >> >> + break;
> >> >> + case VBT_DP_MAX_LINK_RATE_UHBR13P5:
> >> >> + info->dp_max_link_rate = 135;
> >> >> + break;
> >> >> + case VBT_DP_MAX_LINK_RATE_UHBR10:
> >> >> + info->dp_max_link_rate = 100;
> >> >> + break;
> >> >> case VBT_DP_MAX_LINK_RATE_HBR3:
> >> >> info->dp_max_link_rate = 81;
> >> >> break;
> >> >> @@ -1889,7 +1897,21 @@ static void parse_ddi_port(struct
> >> >> drm_i915_private *dev_priv,
> >> >> case VBT_DP_MAX_LINK_RATE_LBR:
> >> >> info->dp_max_link_rate = 162000;
> >> >> break;
> >> >> + case VBT_DP_MAX_LINK_RATE_DEFAULT:
> >> >> + default:
> >> >> + info->dp_max_link_rate = 0;
> >> >> + break;
> >> >> + }
> >> >> +
> >> >> + if (bdb_version < 230) {
> >> >> + if (child->dp_max_link_rate ==
> >> >> VBT_DP_MAX_LINK_RATE_DEFAULT)
> >> >> + info->dp_max_link_rate = 81;
> >> >> + else if (child->dp_max_link_rate ==
> >> >> VBT_DP_MAX_LINK_RATE_LBR)
> >> >> + info->dp_max_link_rate = 54;
> >> >> + else if (child->dp_max_link_rate ==
> >> >> VBT_DP_MAX_LINK_RATE_HBR2)
> >> >> + info->dp_max_link_rate = 162000;
> >> >> }
> >> >
> >> >I would split this into two separate functions, one does the new mapping,
> >> >the other the old mapping.
> >> >
> >>
> >> I will split this into two separate functions in patch v2.
> >
> >Actually looking through the VBT history this seems to have been
> >retroactively changed for already rev 216+ to follow the new
> >definitions. And naturally no actual explanation given. So it's
> >the same old VBT==snafu as always.
> >
> >I guess the real question is whether any machines migth have shipped
> >that depened on the old defitions? Unless someone manages to
> >find that out I think we might just have to change this to follow
> >only the new style and hope we don't regress a lot of machines.
> >
>
> Agree that we should just have the change follow new definition.
> But as you mentioned, we are not sure any machines have shipped
> with the old definition. :(
>
> In my opinion, we should follow the new style. If we got bug report,
> then we can consider to add some codes for backward compatible.
I went trawling in some really dark waters and found out that
Windows seems to do what you did originally, ie. use the
old definition for 216+, and the new definition for 230+.
So we should just do the same.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/3] drm/i915/gt: Export device and per-process runtimes via procfs
Quoting Emil Velikov (2021-02-12 15:45:04)
> On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote:
> >
> > Quoting Emil Velikov (2021-02-12 14:57:56)
> > > Hi Chris,
> > >
> > > On Thu, 4 Feb 2021 at 12:11, Chris Wilson
> > > wrote:
> > > >
> > > > Register with /proc/gpu to provide the client runtimes for generic
> > > > top-like overview, e.g. gnome-system-monitor can use this information to
> > > > show the per-process multi-GPU usage.
> > > >
> > > Exposing this information to userspace sounds great IMHO and like the
> > > proposed "channels" for the device engines.
> > > If it were me, I would have the channel names a) exposed to userspace
> > > and b) be a "fixed set".
> >
> > - Total
> > - Graphics
> > - Compute
> > - Unified
> > - Video
> > - Copy
> > - Display
> > - Other
> >
> > Enough versatility for the foreseeable future?
> > But plan for extension.
> >
> With a bit of documentation about "unified" (is it a metric also
> counted towards any of the rest) it would be perfect.
With unified I was trying to find a place to things that are neither
wholly graphics nor compute, as some may prefer not to categorise
themselves as one or the other. Also whether or not some cores are more
compute than others (so should there be an AI/RT/ALU?)
> For future extension one might consider splitting video into
> encoder/decoder/post-processing.
Ok, I wasn't sure how commonly those functions were split on different
HW.
> > The other aspect then is the capacity of each channel. We can keep it
> > simple as the union/average (whichever the driver has to hand) runtime in
> > nanoseconds over all IP blocks within a channel.
>
> Not sure what you mean with capacity. Are you referring to having
> multiple instances of the same engine (say 3 separate copy engines)?
> Personally I'm inclined to keep these separate entries, since some
> hardware can have multiple ones.
>
> For example - before the latest changes nouveau had 8 copy engines,
> 3+3 video 'generic' video (enc,dec)oder engines, amongst others.
Yes, most HW have multiple engines within a family. Trying to keep it
simple, I thought presenting just one runtime metric for the whole
channel. Especially for the single-line per device format I had picked :)
If we switch to a more extensible format,
-'$device0' :
-$channel0 : {
Total : $total # avg/union over all engines
Engines : [ $0, $1, ... ]
}
...
-'$device1' :
...
Using the same fixed channel names, and dev_name(), pesky concerns such
as keeping it as a simple scanf can be forgotten.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/3] drm/i915/gt: Export device and per-process runtimes via procfs
On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote: > > Quoting Emil Velikov (2021-02-12 14:57:56) > > Hi Chris, > > > > On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote: > > > > > > Register with /proc/gpu to provide the client runtimes for generic > > > top-like overview, e.g. gnome-system-monitor can use this information to > > > show the per-process multi-GPU usage. > > > > > Exposing this information to userspace sounds great IMHO and like the > > proposed "channels" for the device engines. > > If it were me, I would have the channel names a) exposed to userspace > > and b) be a "fixed set". > > - Total > - Graphics > - Compute > - Unified > - Video > - Copy > - Display > - Other > > Enough versatility for the foreseeable future? > But plan for extension. > With a bit of documentation about "unified" (is it a metric also counted towards any of the rest) it would be perfect. For future extension one might consider splitting video into encoder/decoder/post-processing. > The other aspect then is the capacity of each channel. We can keep it > simple as the union/average (whichever the driver has to hand) runtime in > nanoseconds over all IP blocks within a channel. Not sure what you mean with capacity. Are you referring to having multiple instances of the same engine (say 3 separate copy engines)? Personally I'm inclined to keep these separate entries, since some hardware can have multiple ones. For example - before the latest changes nouveau had 8 copy engines, 3+3 video 'generic' video (enc,dec)oder engines, amongst others. Thanks Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "HAX sound: Disable probing snd_hda with DG1"
Quoting Chris Wilson (2021-02-12 15:22:13)
> Quoting Kai Vehmanen (2021-02-12 14:53:02)
> > This reverts commit 3632610d38316bca9b0cd9d649ce3cefab58520a.
> >
> > DG1 has been supported in upstream since v5.10 with commit
> > 69b08bdfa818 ("ALSA: hda - add Intel DG1 PCI and HDMI ids").
>
> Exactly, otherwise this patch wouldn't have been required to stop CI
> from timing out upon snd probing the hdmi components. You need the other
> half to be supported as well before CI is ready.
Just in case it isn't clear, this patch is only in the CI topic branch
to hide known issues with CI that we simply aren't ready for.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "HAX sound: Disable probing snd_hda with DG1"
Quoting Kai Vehmanen (2021-02-12 14:53:02)
> This reverts commit 3632610d38316bca9b0cd9d649ce3cefab58520a.
>
> DG1 has been supported in upstream since v5.10 with commit
> 69b08bdfa818 ("ALSA: hda - add Intel DG1 PCI and HDMI ids").
Exactly, otherwise this patch wouldn't have been required to stop CI
from timing out upon snd probing the hdmi components. You need the other
half to be supported as well before CI is ready.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/3] drm/i915/gt: Export device and per-process runtimes via procfs
Quoting Emil Velikov (2021-02-12 14:57:56) > Hi Chris, > > On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote: > > > > Register with /proc/gpu to provide the client runtimes for generic > > top-like overview, e.g. gnome-system-monitor can use this information to > > show the per-process multi-GPU usage. > > > Exposing this information to userspace sounds great IMHO and like the > proposed "channels" for the device engines. > If it were me, I would have the channel names a) exposed to userspace > and b) be a "fixed set". - Total - Graphics - Compute - Unified - Video - Copy - Display - Other Enough versatility for the foreseeable future? But plan for extension. The other aspect then is the capacity of each channel. We can keep it simple as the union/average (whichever the driver has to hand) runtime in nanoseconds over all IP blocks within a channel. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/14] Introduce Intel PXP
On 12/02/2021 17:10, Daniele Ceraolo Spurio wrote: On 2/12/2021 5:23 AM, Lionel Landwerlin wrote: I just gave a try to this new iteration and it's apparently failing to enable PXP on a machine with this pciID : 0x9a68. What error are you seeing? Daniele Failure to create a protected GEM object, checking the HW register (GEN12_KCR_SIP), the session seems to not be enabled. -Lionel -Lionel On 06/02/2021 04:09, Daniele Ceraolo Spurio wrote: PXP (Protected Xe Path) is an i915 component, available on GEN12+, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. I'm taking over this series from Sean. I've significantly reworked the code since his last revisioni [1], including a different patch split, so I've reset the series revision count. I believe I've addressed most of the pending comments, but please point out aything I've missed. Still RFC for 2 reasons: - mutex usage needs a bit more reworking - very lightly tested [1] https://patchwork.freedesktop.org/series/84620/ Cc: Huang Sean Z Cc: Gaurav Kumar Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Anshuman Gupta (1): drm/i915/pxp: Add plane decryption support Bommu Krishnaiah (2): drm/i915/uapi: introduce drm_i915_gem_create_ext drm/i915/pxp: User interface for Protected buffer Daniele Ceraolo Spurio (5): drm/i915/pxp: Define PXP component interface drm/i915/pxp: define PXP device flag and kconfig drm/i915/pxp: allocate a vcs context for pxp usage drm/i915/pxp: set KCR reg init during the boot time drm/i915/pxp: enable PXP for integrated Gen12 Huang, Sean Z (5): drm/i915/pxp: Implement funcs to create the TEE channel drm/i915/pxp: Create the arbitrary session after boot drm/i915/pxp: Implement arb session teardown drm/i915/pxp: Implement PXP irq handler drm/i915/pxp: Enable PXP power management Vitaly Lubart (1): mei: pxp: export pavp client to me client bus drivers/gpu/drm/i915/Kconfig | 11 + drivers/gpu/drm/i915/Makefile | 9 + drivers/gpu/drm/i915/display/intel_sprite.c | 21 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 34 +++ drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_create.c | 68 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 5 + drivers/gpu/drm/i915/gt/intel_gt.c | 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/i915_drv.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 10 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 107 drivers/gpu/drm/i915/pxp/intel_pxp.h | 54 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 227 + drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 ++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 147 +++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 33 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 94 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 36 +++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 123 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 17 ++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 200 +++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 17 ++ drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 29 +++ drivers/misc/mei/Kconfig | 2 + drivers/misc/mei/Makefile | 1 + drivers/misc/mei/pxp/Kconfig | 13 + drivers/misc/mei/pxp/Makefile | 7 + drivers/misc/mei/pxp/mei_pxp.c | 230 ++ drivers/misc/mei/pxp/mei_pxp.h | 18 ++ include/drm/i915_component.h | 1 + include/drm/i915_pxp_tee_interface.h | 45 include/uapi/drm/i915_drm.h | 70 ++ 40 files changed, 1685 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.c create mode 100644
[Intel-gfx] [PATCH] drm/i915/audio: set HDA link parameters in driver
Update logic to program AUD_FREQ_CNTRL register based on new guidance.
Earlier this register was configured by BIOS and driver discovered the
value at init. This is no longer recommended and instead driver should
set the values based on the hardware revision.
Add the recommended values for all supported hardware. This change applies
for all GEN12+ hardware. For TGL, some special case handling is needed
to not break existing systems.
Extend the debug print to also include values of the register as written
by BIOS. This can help debug rare cases where BIOS has configured the link
settings to incorrect values.
Bspec: 49279
Signed-off-by: Kai Vehmanen
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_audio.c | 30 ++
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index f7de55707746..2c486284396d 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1266,6 +1266,15 @@ static const struct component_ops
i915_audio_component_bind_ops = {
.unbind = i915_audio_component_unbind,
};
+#define AUD_FREQ_TMODE_SHIFT 14
+#define AUD_FREQ_4T0
+#define AUD_FREQ_8T(2 << AUD_FREQ_TMODE_SHIFT)
+#define AUD_FREQ_PULLCLKS(x) (((x) & 0x3) << 11)
+#define AUD_FREQ_BCLK_96M BIT(4)
+
+#define AUD_FREQ_GEN12 (AUD_FREQ_8T | AUD_FREQ_PULLCLKS(0) |
AUD_FREQ_BCLK_96M)
+#define AUD_FREQ_TGL_BROKEN (AUD_FREQ_8T | AUD_FREQ_PULLCLKS(2) |
AUD_FREQ_BCLK_96M)
+
/**
* i915_audio_component_init - initialize and register the audio component
* @dev_priv: i915 device instance
@@ -1284,6 +1293,7 @@ static const struct component_ops
i915_audio_component_bind_ops = {
*/
static void i915_audio_component_init(struct drm_i915_private *dev_priv)
{
+ u32 aud_freq, aud_freq_init;
int ret;
ret = component_add_typed(dev_priv->drm.dev,
@@ -1297,11 +1307,21 @@ static void i915_audio_component_init(struct
drm_i915_private *dev_priv)
}
if (INTEL_GEN(dev_priv) >= 9) {
- dev_priv->audio_freq_cntrl = intel_de_read(dev_priv,
- AUD_FREQ_CNTRL);
- drm_dbg_kms(_priv->drm,
- "init value of AUD_FREQ_CNTRL of 0x%x\n",
- dev_priv->audio_freq_cntrl);
+ aud_freq_init = intel_de_read(dev_priv, AUD_FREQ_CNTRL);
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ aud_freq = AUD_FREQ_GEN12;
+ else
+ aud_freq = aud_freq_init;
+
+ /* use BIOS provided value for TGL unless it is a known bad
value */
+ if (IS_TIGERLAKE(dev_priv) && aud_freq_init !=
AUD_FREQ_TGL_BROKEN)
+ aud_freq = aud_freq_init;
+
+ drm_dbg_kms(_priv->drm, "use AUD_FREQ_CNTRL of 0x%x (init
value 0x%x)\n",
+ aud_freq, aud_freq_init);
+
+ dev_priv->audio_freq_cntrl = aud_freq;
}
dev_priv->audio_component_registered = true;
base-commit: 9d8fddf8579a2a20d0e8a8b631547069a62b953e
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/14] Introduce Intel PXP
On 2/12/2021 5:23 AM, Lionel Landwerlin wrote: I just gave a try to this new iteration and it's apparently failing to enable PXP on a machine with this pciID : 0x9a68. What error are you seeing? Daniele -Lionel On 06/02/2021 04:09, Daniele Ceraolo Spurio wrote: PXP (Protected Xe Path) is an i915 component, available on GEN12+, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. I'm taking over this series from Sean. I've significantly reworked the code since his last revisioni [1], including a different patch split, so I've reset the series revision count. I believe I've addressed most of the pending comments, but please point out aything I've missed. Still RFC for 2 reasons: - mutex usage needs a bit more reworking - very lightly tested [1] https://patchwork.freedesktop.org/series/84620/ Cc: Huang Sean Z Cc: Gaurav Kumar Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Anshuman Gupta (1): drm/i915/pxp: Add plane decryption support Bommu Krishnaiah (2): drm/i915/uapi: introduce drm_i915_gem_create_ext drm/i915/pxp: User interface for Protected buffer Daniele Ceraolo Spurio (5): drm/i915/pxp: Define PXP component interface drm/i915/pxp: define PXP device flag and kconfig drm/i915/pxp: allocate a vcs context for pxp usage drm/i915/pxp: set KCR reg init during the boot time drm/i915/pxp: enable PXP for integrated Gen12 Huang, Sean Z (5): drm/i915/pxp: Implement funcs to create the TEE channel drm/i915/pxp: Create the arbitrary session after boot drm/i915/pxp: Implement arb session teardown drm/i915/pxp: Implement PXP irq handler drm/i915/pxp: Enable PXP power management Vitaly Lubart (1): mei: pxp: export pavp client to me client bus drivers/gpu/drm/i915/Kconfig | 11 + drivers/gpu/drm/i915/Makefile | 9 + drivers/gpu/drm/i915/display/intel_sprite.c | 21 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 34 +++ drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_create.c | 68 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 5 + drivers/gpu/drm/i915/gt/intel_gt.c | 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/i915_drv.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 10 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 107 drivers/gpu/drm/i915/pxp/intel_pxp.h | 54 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 227 + drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 ++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 147 +++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 33 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 94 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 36 +++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 123 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 17 ++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 200 +++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 17 ++ drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 29 +++ drivers/misc/mei/Kconfig | 2 + drivers/misc/mei/Makefile | 1 + drivers/misc/mei/pxp/Kconfig | 13 + drivers/misc/mei/pxp/Makefile | 7 + drivers/misc/mei/pxp/mei_pxp.c | 230 ++ drivers/misc/mei/pxp/mei_pxp.h | 18 ++ include/drm/i915_component.h | 1 + include/drm/i915_pxp_tee_interface.h | 45 include/uapi/drm/i915_drm.h | 70 ++ 40 files changed, 1685 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h create mode 100644
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Ratelimit heartbeat completion probing (rev11)
== Series Details == Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev11) URL : https://patchwork.freedesktop.org/series/86665/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9769_full -> Patchwork_19669_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19669_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19669_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_19669_full: ### IGT changes ### Possible regressions * igt@sysfs_heartbeat_interval@nopreempt@vcs0: - shard-skl: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-skl4/igt@sysfs_heartbeat_interval@nopree...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-skl5/igt@sysfs_heartbeat_interval@nopree...@vcs0.html - shard-glk: [PASS][3] -> [FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-glk2/igt@sysfs_heartbeat_interval@nopree...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-glk6/igt@sysfs_heartbeat_interval@nopree...@vcs0.html - shard-apl: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-apl2/igt@sysfs_heartbeat_interval@nopree...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-apl7/igt@sysfs_heartbeat_interval@nopree...@vcs0.html * igt@sysfs_heartbeat_interval@nopreempt@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-iclb2/igt@sysfs_heartbeat_interval@nopree...@vcs1.html * igt@sysfs_heartbeat_interval@nopreempt@vecs0: - shard-iclb: [PASS][8] -> [FAIL][9] +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-iclb3/igt@sysfs_heartbeat_interval@nopree...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-iclb2/igt@sysfs_heartbeat_interval@nopree...@vecs0.html - shard-kbl: [PASS][10] -> [FAIL][11] +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-kbl3/igt@sysfs_heartbeat_interval@nopree...@vecs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-kbl1/igt@sysfs_heartbeat_interval@nopree...@vecs0.html Known issues Here are the changes found in Patchwork_19669_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-hang: - shard-hsw: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-hsw1/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_eio@in-flight-contexts-10ms: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#1037] / [i915#2870]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-hsw5/igt@gem_...@in-flight-contexts-10ms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-hsw4/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][15] -> [TIMEOUT][16] ([i915#1037] / [i915#3063]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-tglb7/igt@gem_...@unwedge-stress.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-tglb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][23] ([i915#2842]) +1
Re: [Intel-gfx] [RFC 3/3] drm/i915/gt: Export device and per-process runtimes via procfs
Hi Chris, On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote: > > Register with /proc/gpu to provide the client runtimes for generic > top-like overview, e.g. gnome-system-monitor can use this information to > show the per-process multi-GPU usage. > Exposing this information to userspace sounds great IMHO and like the proposed "channels" for the device engines. If it were me, I would have the channel names a) exposed to userspace and b) be a "fixed set". Whereby with a "fixed set" I mean, we should have these akin to the KMS UAPI properties, where we have core helpers exposing prop X/Y and there should be no driver specific ones. This would allow for consistent and deterministic userspace handling, even if some hardware/drivers do not have all engines - say no copy engine. > --- /dev/null > +++ b/drivers/gpu/drm/i915/gt/intel_gt_proc.c > @@ -0,0 +1,66 @@ > +// SPDX-License-Identifier: MIT Thanks for making these available under MIT. > +/* > + * Copyright © 2020 Intel Corporation Might want to make this 2021 in the next revision. HTH Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "HAX sound: Disable probing snd_hda with DG1"
This reverts commit 3632610d38316bca9b0cd9d649ce3cefab58520a.
DG1 has been supported in upstream since v5.10 with commit
69b08bdfa818 ("ALSA: hda - add Intel DG1 PCI and HDMI ids").
Cc: Chris Wilson
Signed-off-by: Kai Vehmanen
---
sound/hda/hdac_i915.c | 23 ---
sound/pci/hda/hda_intel.c | 2 ++
2 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index fbca4bf53a47..454474ac5716 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -128,26 +128,6 @@ static bool i915_gfx_present(void)
return pci_dev_present(ids);
}
-static bool dg1_gfx_present(void)
-{
- static const struct pci_device_id ids[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4905),
- .class = PCI_BASE_CLASS_DISPLAY << 16,
- .class_mask = 0xff << 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4906),
- .class = PCI_BASE_CLASS_DISPLAY << 16,
- .class_mask = 0xff << 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4907),
- .class = PCI_BASE_CLASS_DISPLAY << 16,
- .class_mask = 0xff << 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4908),
- .class = PCI_BASE_CLASS_DISPLAY << 16,
- .class_mask = 0xff << 16 },
- {}
- };
- return pci_dev_present(ids);
-}
-
/**
* snd_hdac_i915_init - Initialize i915 audio component
* @bus: HDA core bus
@@ -168,9 +148,6 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
if (!i915_gfx_present())
return -ENODEV;
- if (dg1_gfx_present())
- return -ENODEV;
-
err = snd_hdac_acomp_init(bus, NULL,
i915_component_master_match,
sizeof(struct i915_audio_component) -
sizeof(*acomp));
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index bdd5b01b0222..5a50d3a46445 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2293,6 +2293,8 @@ static int azx_probe_continue(struct azx *chip)
* codecs can be on the same link.
*/
if (CONTROLLER_IN_GPU(pci)) {
+ dev_err(chip->card->dev,
+ "HSW/BDW HD-audio HDMI/DP requires
binding with gfx driver\n");
goto out_free;
} else {
/* don't bother any longer */
base-commit: be9bde5a8b7b5cff58bd01c8ca094d571295c40b
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_userptr_blts: Move readonly test into common block
Since we only run test_readonly for a single sync-flag, place it in the
common block.
Signed-off-by: Chris Wilson
---
tests/i915/gem_userptr_blits.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 1bc2d3600..a4f137f93 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -2474,6 +2474,9 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("set-cache-level")
test_set_caching(fd);
+ igt_subtest("readonly")
+ test_readonly(fd);
+
igt_subtest("userfault")
test_userfault(fd);
@@ -2515,9 +2518,6 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("dmabuf-unsync")
test_dmabuf();
- igt_subtest("readonly-unsync")
- test_readonly(fd);
-
igt_describe("Examine mmap-offset mapping to read-only
userptr");
igt_subtest_with_dynamic("readonly-mmap-unsync")
for_each_mmap_offset_type(fd, t)
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_userptr_blts: Move readonly test into common block
Since we only run test_readonly for a single sync-flag, place it in the
common block.
Signed-off-by: Chris Wilson
---
tests/i915/gem_userptr_blits.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 1bc2d3600..a4f137f93 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -2474,6 +2474,9 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("set-cache-level")
test_set_caching(fd);
+ igt_subtest("readonly")
+ test_readonly(fd);
+
igt_subtest("userfault")
test_userfault(fd);
@@ -2515,9 +2518,6 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("dmabuf-unsync")
test_dmabuf();
- igt_subtest("readonly-unsync")
- test_readonly(fd);
-
igt_describe("Examine mmap-offset mapping to read-only
userptr");
igt_subtest_with_dynamic("readonly-mmap-unsync")
for_each_mmap_offset_type(fd, t)
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On Fri, 12 Feb 2021 at 14:01, Michel Dänzer wrote: > > On 2021-02-12 1:57 p.m., Emil Velikov wrote: > > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote: > >> > >> Userspace has discovered the functionality offered by SYS_kcmp and has > >> started to depend upon it. In particular, Mesa uses SYS_kcmp for > >> os_same_file_description() in order to identify when two fd (e.g. device > >> or dmabuf) > > > > As you rightfully point out, SYS_kcmp is a bit of a two edged sword. > > While you mention the CONFIG issue, there is also a portability aspect > > (mesa runs on more than just linux) and as well as sandbox filtering > > of the extra syscall. > > > > Last time I looked, the latter was still an issue and mesa was using > > SYS_kcmp to compare device node fds. > > A far shorter and more portable solution is possible, so let me > > prepare a Mesa patch. > > Make sure to read my comments on > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :) > Much appreciated. I might have been "slightly" off - pardon for the noise o/ -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On Fri, 12 Feb 2021 at 13:14, Simon Ser wrote: > > On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov > wrote: > > > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote: > > > > > > Userspace has discovered the functionality offered by SYS_kcmp and has > > > started to depend upon it. In particular, Mesa uses SYS_kcmp for > > > os_same_file_description() in order to identify when two fd (e.g. device > > > or dmabuf) > > > > As you rightfully point out, SYS_kcmp is a bit of a two edged sword. > > While you mention the CONFIG issue, there is also a portability aspect > > (mesa runs on more than just linux) and as well as sandbox filtering > > of the extra syscall. > > > > Last time I looked, the latter was still an issue and mesa was using > > SYS_kcmp to compare device node fds. > > A far shorter and more portable solution is possible, so let me > > prepare a Mesa patch. > > Comparing two DMA-BUFs can be done with their inode number, I think. > > Comparing two device FDs is more subtle, because of GEM handle > ref'counting. You sometimes really want to check whether two FDs are > backed by the same file *description*. See [1] for details. > Thanks for the correction and the reference. Seems like I've short circuited file description table vs file descriptor. Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On 2021-02-12 1:57 p.m., Emil Velikov wrote: On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote: Userspace has discovered the functionality offered by SYS_kcmp and has started to depend upon it. In particular, Mesa uses SYS_kcmp for os_same_file_description() in order to identify when two fd (e.g. device or dmabuf) As you rightfully point out, SYS_kcmp is a bit of a two edged sword. While you mention the CONFIG issue, there is also a portability aspect (mesa runs on more than just linux) and as well as sandbox filtering of the extra syscall. Last time I looked, the latter was still an issue and mesa was using SYS_kcmp to compare device node fds. A far shorter and more portable solution is possible, so let me prepare a Mesa patch. Make sure to read my comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Ratelimit heartbeat completion probing (rev11)
== Series Details ==
Series: drm/i915/gt: Ratelimit heartbeat completion probing (rev11)
URL : https://patchwork.freedesktop.org/series/86665/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9769 -> Patchwork_19669
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19669:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-ehl-2}: NOTRUN -> [DMESG-WARN][1] +33 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-ehl-2/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_engines:
- {fi-ehl-2}: NOTRUN -> [DMESG-FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
* igt@kms_force_connector_basic@force-load-detect:
- {fi-ehl-2}: NOTRUN -> [SKIP][4] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-ehl-2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@runner@aborted:
- {fi-ehl-2}: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-ehl-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_19669 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- {fi-ehl-2}: [FAIL][6] ([i915#2992]) -> [PASS][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-ehl-2/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-ehl-2/boot.html
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-cfl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +25 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-cfl-guc/igt@amdgpu/amd_ba...@cs-compute.html
* igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka: NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html
* igt@amdgpu/amd_basic@userptr:
- fi-byt-j1900: NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html
* igt@i915_selftest@live@hangcheck:
- fi-tgl-u2: [PASS][11] -> [INCOMPLETE][12] ([i915#750])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-cfl-guc/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cfl-guc: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-cfl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][15] -> [DMESG-WARN][16] ([i915#402])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
* igt@runner@aborted:
- fi-tgl-u2: NOTRUN -> [FAIL][17] ([i915#2966])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-tgl-u2/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-tgl-y/igt@fb...@read.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-tgl-y/igt@fb...@read.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [INCOMPLETE][20] ([i915#142] / [i915#2405]) ->
[PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19669/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Introduce guard pages to i915_vma
Quoting Matthew Auld (2021-02-12 13:43:46)
> On Fri, 12 Feb 2021 at 10:22, Chris Wilson wrote:
> >
> > Introduce the concept of padding the i915_vma with guard pages before
> > and aft. The major consequence is that all ordinary uses of i915_vma
> > must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
> > directly, as the drm_mm_node will include the guard pages that surround
> > our object.
> >
> > So in this patch, we look for all uses of i915_vma->node.start that
> > instead need to include the guard offset and switch them to
> > i915_vma_offset(), and in a few cases to i915_ggtt_offset(). Notable
> > exceptions are the selftests, which expect exact behaviour.
> >
> > The biggest connundrum is how exactly to mix request a fixed address
> > with guard pages, particular through the existing uABI. The user does
> > not know about guard pages, so such must be transparent to the user, and
> > so the execobj.offset must be that of the object itself excluding the
> > guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages.
> >
> > In the next patch, we start using guard pages for scanout objects. While
> > these are limited to GGTT vma, on a few platforms these vma (or at least
> > an alias of the vma) is shared with userspace, so we may leak the
> > existence of such guards if we are not careful to ensure that the
> > execobj.offset is transparent and excludes the guards. (On such platforms,
> > without full-ppgtt, userspace has to use relocations so the presence of
> > more untouchable regions within its GTT such be of no further issue.)
> >
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
> > drivers/gpu/drm/i915/i915_vma.c | 10 +++---
> > drivers/gpu/drm/i915/i915_vma.h | 8
> > drivers/gpu/drm/i915/i915_vma_types.h | 3 ++-
> > 4 files changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index c5803c434d33..6b326138e765 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -238,8 +238,12 @@ static void gen8_ggtt_insert_entries(struct
> > i915_address_space *vm,
> >
> > gte = (gen8_pte_t __iomem *)ggtt->gsm;
> > gte += vma->node.start / I915_GTT_PAGE_SIZE;
> > - end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
> >
> > + end = gte + vma->guard / I915_GTT_PAGE_SIZE;
> > + while (gte < end)
> > + gen8_set_pte(gte++, vm->scratch[0]->encode);
> > +
> > + end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
> > for_each_sgt_daddr(addr, iter, vma->pages)
> > gen8_set_pte(gte++, pte_encode | addr);
> > GEM_BUG_ON(gte > end);
> > @@ -289,8 +293,12 @@ static void gen6_ggtt_insert_entries(struct
> > i915_address_space *vm,
> >
> > gte = (gen6_pte_t __iomem *)ggtt->gsm;
> > gte += vma->node.start / I915_GTT_PAGE_SIZE;
> > - end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
> >
> > + end = gte + vma->guard / I915_GTT_PAGE_SIZE;
> > + while (gte < end)
> > + gen8_set_pte(gte++, vm->scratch[0]->encode);
> > +
> > + end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
> > for_each_sgt_daddr(addr, iter, vma->pages)
> > iowrite32(vm->pte_encode(addr, level, flags), gte++);
> > GEM_BUG_ON(gte > end);
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > b/drivers/gpu/drm/i915/i915_vma.c
> > index 17fe455bd770..155f510b4cc6 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -623,7 +623,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
> > unsigned long color)
> > static int
> > i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
> > {
> > - unsigned long color;
> > + unsigned long color, guard;
> > u64 start, end;
> > int ret;
> >
> > @@ -631,13 +631,16 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
> > alignment, u64 flags)
> > GEM_BUG_ON(drm_mm_node_allocated(>node));
> >
> > size = max(size, vma->size);
> > - alignment = max(alignment, vma->display_alignment);
> > + alignment = max_t(typeof(alignment), alignment,
> > vma->display_alignment);
> > if (flags & PIN_MAPPABLE) {
> > size = max_t(typeof(size), size, vma->fence_size);
> > alignment = max_t(typeof(alignment),
> > alignment, vma->fence_alignment);
> > }
> >
> > + guard = 0;
> > + size += 2 * guard;
> > +
> > GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
> > GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
> > GEM_BUG_ON(!is_power_of_2(alignment));
> > @@ -674,7 +677,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
>
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Refine VT-d scanout workaround
On Fri, 12 Feb 2021 at 10:22, Chris Wilson wrote: > > VT-d may cause overfetch of the scanout PTE, both before and after the > vma (depending on the scanout orientation). bspec recommends that we > provide a tile-row in either directions, and suggests using 160 PTE, > warning that the accesses will wrap around the ends of the GGTT. > Currently, we fill the entire GGTT with scratch pages when using VT-d to > always ensure there are valid entries around every vma, including > scanout. However, writing every PTE is slow as on recent devices we > perform 8MiB of uncached writes, incurring an extra 100ms during resume. > > If instead we focus on only putting guard pages around scanout, we can > avoid touching the whole GGTT. To avoid having to introduce extra nodes > around each scanout vma, we adjust the scanout drm_mm_node to be smaller > than the allocated space, and fixup the extra PTE during dma binding. > > v2: Move the guard from modifying drm_mm_node.start which is still used > by the drm_mm itself, into an adjustment of node.start at the point of > use. > > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä > Cc: Matthew Auld Yeah, that does look much better, 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 2/3] drm/i915: Introduce guard pages to i915_vma
On Fri, 12 Feb 2021 at 10:22, Chris Wilson wrote:
>
> Introduce the concept of padding the i915_vma with guard pages before
> and aft. The major consequence is that all ordinary uses of i915_vma
> must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
> directly, as the drm_mm_node will include the guard pages that surround
> our object.
>
> So in this patch, we look for all uses of i915_vma->node.start that
> instead need to include the guard offset and switch them to
> i915_vma_offset(), and in a few cases to i915_ggtt_offset(). Notable
> exceptions are the selftests, which expect exact behaviour.
>
> The biggest connundrum is how exactly to mix request a fixed address
> with guard pages, particular through the existing uABI. The user does
> not know about guard pages, so such must be transparent to the user, and
> so the execobj.offset must be that of the object itself excluding the
> guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages.
>
> In the next patch, we start using guard pages for scanout objects. While
> these are limited to GGTT vma, on a few platforms these vma (or at least
> an alias of the vma) is shared with userspace, so we may leak the
> existence of such guards if we are not careful to ensure that the
> execobj.offset is transparent and excludes the guards. (On such platforms,
> without full-ppgtt, userspace has to use relocations so the presence of
> more untouchable regions within its GTT such be of no further issue.)
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
> drivers/gpu/drm/i915/i915_vma.c | 10 +++---
> drivers/gpu/drm/i915/i915_vma.h | 8
> drivers/gpu/drm/i915/i915_vma_types.h | 3 ++-
> 4 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index c5803c434d33..6b326138e765 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -238,8 +238,12 @@ static void gen8_ggtt_insert_entries(struct
> i915_address_space *vm,
>
> gte = (gen8_pte_t __iomem *)ggtt->gsm;
> gte += vma->node.start / I915_GTT_PAGE_SIZE;
> - end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
>
> + end = gte + vma->guard / I915_GTT_PAGE_SIZE;
> + while (gte < end)
> + gen8_set_pte(gte++, vm->scratch[0]->encode);
> +
> + end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
> for_each_sgt_daddr(addr, iter, vma->pages)
> gen8_set_pte(gte++, pte_encode | addr);
> GEM_BUG_ON(gte > end);
> @@ -289,8 +293,12 @@ static void gen6_ggtt_insert_entries(struct
> i915_address_space *vm,
>
> gte = (gen6_pte_t __iomem *)ggtt->gsm;
> gte += vma->node.start / I915_GTT_PAGE_SIZE;
> - end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
>
> + end = gte + vma->guard / I915_GTT_PAGE_SIZE;
> + while (gte < end)
> + gen8_set_pte(gte++, vm->scratch[0]->encode);
> +
> + end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
> for_each_sgt_daddr(addr, iter, vma->pages)
> iowrite32(vm->pte_encode(addr, level, flags), gte++);
> GEM_BUG_ON(gte > end);
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 17fe455bd770..155f510b4cc6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -623,7 +623,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
> unsigned long color)
> static int
> i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
> {
> - unsigned long color;
> + unsigned long color, guard;
> u64 start, end;
> int ret;
>
> @@ -631,13 +631,16 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
> alignment, u64 flags)
> GEM_BUG_ON(drm_mm_node_allocated(>node));
>
> size = max(size, vma->size);
> - alignment = max(alignment, vma->display_alignment);
> + alignment = max_t(typeof(alignment), alignment,
> vma->display_alignment);
> if (flags & PIN_MAPPABLE) {
> size = max_t(typeof(size), size, vma->fence_size);
> alignment = max_t(typeof(alignment),
> alignment, vma->fence_alignment);
> }
>
> + guard = 0;
> + size += 2 * guard;
> +
> GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
> GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
> GEM_BUG_ON(!is_power_of_2(alignment));
> @@ -674,7 +677,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
> alignment, u64 flags)
> return -EINVAL;
Should we bother adjusting the overflows checking to account for the
padding? Also maybe check that offset >= guard?
if (flags & PIN_OFFSET_FIXED) {
u64 offset = flags &
Re: [Intel-gfx] [RFC 00/14] Introduce Intel PXP
I just gave a try to this new iteration and it's apparently failing to enable PXP on a machine with this pciID : 0x9a68. -Lionel On 06/02/2021 04:09, Daniele Ceraolo Spurio wrote: PXP (Protected Xe Path) is an i915 component, available on GEN12+, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. I'm taking over this series from Sean. I've significantly reworked the code since his last revisioni [1], including a different patch split, so I've reset the series revision count. I believe I've addressed most of the pending comments, but please point out aything I've missed. Still RFC for 2 reasons: - mutex usage needs a bit more reworking - very lightly tested [1] https://patchwork.freedesktop.org/series/84620/ Cc: Huang Sean Z Cc: Gaurav Kumar Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Anshuman Gupta (1): drm/i915/pxp: Add plane decryption support Bommu Krishnaiah (2): drm/i915/uapi: introduce drm_i915_gem_create_ext drm/i915/pxp: User interface for Protected buffer Daniele Ceraolo Spurio (5): drm/i915/pxp: Define PXP component interface drm/i915/pxp: define PXP device flag and kconfig drm/i915/pxp: allocate a vcs context for pxp usage drm/i915/pxp: set KCR reg init during the boot time drm/i915/pxp: enable PXP for integrated Gen12 Huang, Sean Z (5): drm/i915/pxp: Implement funcs to create the TEE channel drm/i915/pxp: Create the arbitrary session after boot drm/i915/pxp: Implement arb session teardown drm/i915/pxp: Implement PXP irq handler drm/i915/pxp: Enable PXP power management Vitaly Lubart (1): mei: pxp: export pavp client to me client bus drivers/gpu/drm/i915/Kconfig | 11 + drivers/gpu/drm/i915/Makefile | 9 + drivers/gpu/drm/i915/display/intel_sprite.c | 21 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 34 +++ drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 68 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 5 + drivers/gpu/drm/i915/gt/intel_gt.c| 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 7 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/i915_drv.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 10 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 107 drivers/gpu/drm/i915/pxp/intel_pxp.h | 54 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 227 + drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 ++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 147 +++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 33 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 94 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 36 +++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 123 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 17 ++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 200 +++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 17 ++ drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 29 +++ drivers/misc/mei/Kconfig | 2 + drivers/misc/mei/Makefile | 1 + drivers/misc/mei/pxp/Kconfig | 13 + drivers/misc/mei/pxp/Makefile | 7 + drivers/misc/mei/pxp/mei_pxp.c| 230 ++ drivers/misc/mei/pxp/mei_pxp.h| 18 ++ include/drm/i915_component.h | 1 + include/drm/i915_pxp_tee_interface.h | 45 include/uapi/drm/i915_drm.h | 70 ++ 40 files changed, 1685 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h create mode 100644 drivers/misc/mei/pxp/Kconfig create
Re: [Intel-gfx] [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov wrote: > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote: > > > > Userspace has discovered the functionality offered by SYS_kcmp and has > > started to depend upon it. In particular, Mesa uses SYS_kcmp for > > os_same_file_description() in order to identify when two fd (e.g. device > > or dmabuf) > > As you rightfully point out, SYS_kcmp is a bit of a two edged sword. > While you mention the CONFIG issue, there is also a portability aspect > (mesa runs on more than just linux) and as well as sandbox filtering > of the extra syscall. > > Last time I looked, the latter was still an issue and mesa was using > SYS_kcmp to compare device node fds. > A far shorter and more portable solution is possible, so let me > prepare a Mesa patch. Comparing two DMA-BUFs can be done with their inode number, I think. Comparing two device FDs is more subtle, because of GEM handle ref'counting. You sometimes really want to check whether two FDs are backed by the same file *description*. See [1] for details. [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/debugfs : PCU PM_REQ and PM_RES registers
On Tue, 09 Feb 2021, Saichandana S wrote:
> This debugfs provides the display PM debug information like Time
> to Next VBI and Time to Next Fill from Display Engine <-> PCU Mailbox.
We still lack a rationale for this and the test design. In past review,
I got the impression that a) you need the wakeref, but b) grabbing the
wakeref messes up the test.
What are you testing? What are you trying to achieve?
BR,
Jani.
PS. You leak the wakeref and stay up indefinitely if csr isn't loaded.
>
> 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]
>
> V4 : Used i915 as local variable. [Anshuman Gupta, Jani Nikula]
>
> V5 : Added wakeref to wakeup device. [Chris Wilson]
> Signed-off-by: Saichandana S
> ---
> .../drm/i915/display/intel_display_debugfs.c | 24 +++
> drivers/gpu/drm/i915/i915_reg.h | 9 +++
> 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 d6e4a9237bda..29aaa41fdeec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -591,6 +591,29 @@ static int i915_dmc_info(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int i915_pcu_pm_req_res_info(struct seq_file *m, void *unused)
> +{
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct intel_csr *csr = >csr;
> + intel_wakeref_t wakeref;
> +
> + if (!HAS_CSR(i915))
> + return -ENODEV;
> +
> + wakeref = intel_runtime_pm_get(>runtime_pm);
> + if (!csr->dmc_payload)
> + return 0;
Leak.
> + seq_printf(m, "Time to Next Fill : 0x%08x\n",
> +intel_de_read(i915, PM_RSP_DBG_0) & PM_RESP_TTNF_MASK);
> + seq_printf(m, "Time to Next VBI : 0x%08x\n",
> +(intel_de_read(i915, PM_RSP_DBG_0) & PM_RESP_TTNVBI_MASK) >>
> 16);
> + seq_printf(m, "Selective Exit Latency : 0x%08x\n",
> +intel_de_read(i915, PM_RSP_DBG_1) &
> PM_RESP_SEL_EXIT_LATENCY_MASK);
> +
> + intel_runtime_pm_put(>runtime_pm, wakeref);
> + return 0;
> +}
> +
> static void intel_seq_print_mode(struct seq_file *m, int tabs,
>const struct drm_display_mode *mode)
> {
> @@ -2128,6 +2151,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_pcu_pm_req_res_info", i915_pcu_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 224ad897af34..93d319bf80fd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -12525,4 +12525,13 @@ 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)
> +
> #endif /* _I915_REG_H_ */
--
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] [PATCH v6] drm/i915/gt: Ratelimit heartbeat completion probing
The heartbeat runs through a few phases that we expect to complete
within a certain number of heartbeat intervals. First we must submit the
heartbeat to the queue, and if the queue is occupied it may take a
couple of intervals before the heartbeat preempts the workload and is
submitted to HW. Once running on HW, completion is not instantaneous as
it may have to first reset the current workload before it itself runs
through the empty request and signals completion. As such, we know that
the heartbeat must take at least the preempt reset timeout and before we
have had a chance to reset the engine, we do not want to issue a global
reset ourselves (simply so that we only try to do one reset at a time
and not confuse ourselves by resetting twice and hitting an innocent.)
So by taking into consideration that once running the request must take
a finite amount of time, we can delay the final completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v3: Now with more tracking for selftests and detection of
false/unexpected hang reports.
v2,4,5: Add a completion handler for the heartbeat to speed up discovery
of a successful heartbeat. Remove it, but then put it back to handle
large mismatches between the sysfs properties and reality.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 107 +++---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 ++
.../drm/i915/gt/selftest_engine_heartbeat.c | 103 +++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +-
4 files changed, 173 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..7e7d2ff2299b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -20,6 +20,18 @@
* issue a reset -- in the hope that restores progress.
*/
+#define HEARTBEAT_COMPLETION 50u /* milliseconds */
+
+static long completion_timeout(const struct intel_engine_cs *engine)
+{
+ long timeout = HEARTBEAT_COMPLETION;
+
+ if (intel_engine_has_preempt_reset(engine))
+ timeout += READ_ONCE(engine->props.preempt_timeout_ms);
+
+ return msecs_to_jiffies(timeout);
+}
+
static bool next_heartbeat(struct intel_engine_cs *engine)
{
long delay;
@@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
return false;
delay = msecs_to_jiffies_timeout(delay);
+
+ /*
+* Once we submit a heartbeat to the HW, we know that it will take
+* at least a certain amount of time to complete. On a hanging system
+* it will first have to wait for the preempt reset timeout, and
+* then it will take some time for the reset to resume with the
+* heartbeat and for it to complete. So once we have submitted the
+* heartbeat to HW, we can wait a while longer before declaring the
+* engine stuck and forcing a reset ourselves. If we do a reset
+* and the engine is also doing a reset, it is possible that we
+* reset the engine twice, harming an innocent.
+*
+* Before we have sumitted the heartbeat, we do not want to change
+* the interval as we want to promote the heartbeat and trigger
+* preemption in a deterministic time frame.
+*/
+ if (engine->heartbeat.systole &&
+ i915_request_is_active(engine->heartbeat.systole))
+ delay = max(delay, completion_timeout(engine));
+
if (delay >= HZ)
delay = round_jiffies_up_relative(delay);
mod_delayed_work(system_highpri_wq, >heartbeat.work, delay + 1);
@@ -48,12 +80,52 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
return rq;
}
+static void
+untrack_heartbeat(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = engine->heartbeat.systole;
+ if (!rq)
+ return;
+
+ ENGINE_TRACE(engine, "heartbeat " RQ_FMT " completed\n", RQ_ARG(rq));
+ I915_SELFTEST_ONLY(engine->heartbeat.completed++);
+
+ dma_fence_remove_callback(>fence, >heartbeat.cb);
+ WRITE_ONCE(engine->heartbeat.systole, NULL);
+
+ i915_request_put(rq);
+}
+
+static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+ struct intel_engine_cs *engine =
+ container_of(cb, typeof(*engine), heartbeat.cb);
+
+ if (READ_ONCE(engine->heartbeat.systole))
+ mod_delayed_work(system_highpri_wq, >heartbeat.work, 0);
+}
+
+static void
+track_heartbeat(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ ENGINE_TRACE(engine, "heartbeat " RQ_FMT " started\n", RQ_ARG(rq));
+
Re: [Intel-gfx] [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote: > > Userspace has discovered the functionality offered by SYS_kcmp and has > started to depend upon it. In particular, Mesa uses SYS_kcmp for > os_same_file_description() in order to identify when two fd (e.g. device > or dmabuf) As you rightfully point out, SYS_kcmp is a bit of a two edged sword. While you mention the CONFIG issue, there is also a portability aspect (mesa runs on more than just linux) and as well as sandbox filtering of the extra syscall. Last time I looked, the latter was still an issue and mesa was using SYS_kcmp to compare device node fds. A far shorter and more portable solution is possible, so let me prepare a Mesa patch. -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Wrap all access to i915_vma.node.start|size
On Fri, 12 Feb 2021 at 10:22, Chris Wilson wrote: > > We already wrap i915_vma.node.start for use with the GGTT, as there we > can perform additional sanity checks that the node belongs to the GGTT > and fits within the 32b registers. In the next couple of patches, we > will introduce guard pages around the objects _inside_ the drm_mm_node > allocation. That is we will offset the vma->pages so that the first page > is at drm_mm_node.start + vma->guard (not 0 as is currently the case). > All users must then not use i915_vma.node.start directly, but compute > the guard offset, thus all users are converted to use a > i915_vma_offset() wrapper. > > The notable exceptions are the selftests that are testing exact > behaviour of i915_vma_pin/i915_vma_insert. > > Signed-off-by: Chris Wilson > --- > @@ -562,10 +562,11 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma > *vma) > GEM_BUG_ON(!i915_vma_is_ggtt(vma)); > GEM_BUG_ON(!vma->fence_size); > > - fenceable = (vma->node.size >= vma->fence_size && > -IS_ALIGNED(vma->node.start, vma->fence_alignment)); > + fenceable = (i915_vma_size(vma) >= vma->fence_size && > +IS_ALIGNED(i915_vma_offset(vma), vma->fence_alignment)); > > - mappable = vma->node.start + vma->fence_size <= > i915_vm_to_ggtt(vma->vm)->mappable_end; > + mappable = (i915_vma_offset(vma) + vma->fence_size <= > + i915_vm_to_ggtt(vma->vm)->mappable_end); i915_ggtt_offset(vma) could be used here. 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 series starting with [1/3] drm/i915: Wrap all access to i915_vma.node.start|size
== Series Details ==
Series: series starting with [1/3] drm/i915: Wrap all access to
i915_vma.node.start|size
URL : https://patchwork.freedesktop.org/series/87013/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9769 -> Patchwork_19668
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_19668 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19668, 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_19668/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19668:
### IGT changes ###
Possible regressions
* igt@kms_busy@basic@flip:
- fi-ivb-3770:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-ivb-3770/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-ivb-3770/igt@kms_busy@ba...@flip.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- {fi-ehl-2}: NOTRUN -> [SKIP][3] +20 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-ehl-2/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@i915_module_load@reload:
- {fi-ehl-2}: NOTRUN -> [DMESG-WARN][4] +38 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-ehl-2/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_engines:
- {fi-ehl-2}: NOTRUN -> [DMESG-FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
Known issues
Here are the changes found in Patchwork_19668 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- {fi-ehl-2}: [FAIL][6] ([i915#2992]) -> [PASS][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-ehl-2/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-ehl-2/boot.html
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-cfl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +25 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-cfl-guc/igt@amdgpu/amd_ba...@cs-compute.html
* igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka: NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271]) +26 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_basic@userptr:
- fi-byt-j1900: NOTRUN -> [SKIP][11] ([fdo#109271]) +17 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][12] ([i915#2283])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#1982] /
[k.org#205379])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9769/fi-tgl-y/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@dp-edid-read:
- fi-cfl-guc: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-cfl-guc/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cfl-guc: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-cfl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-ivb-3770:NOTRUN -> [FAIL][18] ([i915#2426])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19668/fi-ivb-3770/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) ->
Re: [Intel-gfx] [RFC v4 05/11] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit
On Mon, 08 Feb 2021, Lyude Paul wrote:
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
>
> v4:
> * Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
> DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index c37ccc8538cb..57218faed4a3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -382,7 +382,7 @@ intel_dp_aux_vesa_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_panel *panel = >panel;
> - u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
> + u8 dpcd_buf, new_dpcd_buf;
> u8 pwmgen_bit_count = panel->backlight.edp.vesa.pwmgen_bit_count;
>
> if (drm_dp_dpcd_readb(_dp->aux,
> @@ -393,12 +393,8 @@ intel_dp_aux_vesa_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> }
>
> new_dpcd_buf = dpcd_buf;
> - edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>
> - switch (edp_backlight_mode) {
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> + if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>
> @@ -406,13 +402,6 @@ intel_dp_aux_vesa_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> pwmgen_bit_count) != 1)
What baseline is this on? None that I can think of have the above != 1,
they're all < 0 AFAICT.
BR,
Jani.
> drm_dbg_kms(>drm,
> "Failed to write aux pwmgen bit count\n");
> -
> - break;
> -
> - /* Do nothing when it is already DPCD mode */
> - case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> - default:
> - break;
> }
>
> if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
--
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.CHECKPATCH: warning for series starting with [1/3] drm/i915: Wrap all access to i915_vma.node.start|size
== Series Details == Series: series starting with [1/3] drm/i915: Wrap all access to i915_vma.node.start|size URL : https://patchwork.freedesktop.org/series/87013/ State : warning == Summary == $ dim checkpatch origin/drm-tip fbe6f8e9939d drm/i915: Wrap all access to i915_vma.node.start|size -:720: WARNING:LEADING_SPACE: please, no spaces at the start of a line #720: FILE: drivers/gpu/drm/i915/i915_vma.h:115: + GEM_BUG_ON(!drm_mm_node_allocated(>node));$ -:721: WARNING:LEADING_SPACE: please, no spaces at the start of a line #721: FILE: drivers/gpu/drm/i915/i915_vma.h:116: + return vma->node.size;$ -:726: WARNING:LEADING_SPACE: please, no spaces at the start of a line #726: FILE: drivers/gpu/drm/i915/i915_vma.h:121: + GEM_BUG_ON(!drm_mm_node_allocated(>node));$ -:727: WARNING:LEADING_SPACE: please, no spaces at the start of a line #727: FILE: drivers/gpu/drm/i915/i915_vma.h:122: + return vma->node.start;$ total: 0 errors, 4 warnings, 0 checks, 649 lines checked 14325abd66e0 drm/i915: Introduce guard pages to i915_vma eb0c0d8b37f3 drm/i915: Refine VT-d scanout workaround ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Refine VT-d scanout workaround
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 160 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
v2: Move the guard from modifying drm_mm_node.start which is still used
by the drm_mm itself, into an adjustment of node.start at the point of
use.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
drivers/gpu/drm/i915/i915_vma.c| 10 +
4 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 0478b069c202..9f2ccc255ca1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -345,6 +345,9 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (ret)
goto err;
+ if (intel_scanout_needs_vtd_wa(i915))
+ flags |= PIN_VTD;
+
/*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 6b326138e765..251b50884d1c 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -319,27 +319,6 @@ static void nop_clear_range(struct i915_address_space *vm,
{
}
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(_base[i], scratch_pte);
-}
-
static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
{
/*
@@ -907,8 +886,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
- ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1054,7 +1031,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c9b0ee5e1d23..8a2dfc7144cf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -41,6 +41,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
#define PIN_HIGH BIT_ULL(5)
#define PIN_OFFSET_BIASBIT_ULL(6)
#define PIN_OFFSET_FIXED BIT_ULL(7)
+#define PIN_VTDBIT_ULL(8)
#define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */
#define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 155f510b4cc6..929d2a1a20b8 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -38,6 +38,8 @@
#include "i915_trace.h"
#include "i915_vma.h"
+#define VTD_GUARD roundup_pow_of_two(160 * SZ_4K) /* 160
[Intel-gfx] [PATCH 2/3] drm/i915: Introduce guard pages to i915_vma
Introduce the concept of padding the i915_vma with guard pages before
and aft. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that surround
our object.
So in this patch, we look for all uses of i915_vma->node.start that
instead need to include the guard offset and switch them to
i915_vma_offset(), and in a few cases to i915_ggtt_offset(). Notable
exceptions are the selftests, which expect exact behaviour.
The biggest connundrum is how exactly to mix request a fixed address
with guard pages, particular through the existing uABI. The user does
not know about guard pages, so such must be transparent to the user, and
so the execobj.offset must be that of the object itself excluding the
guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages.
In the next patch, we start using guard pages for scanout objects. While
these are limited to GGTT vma, on a few platforms these vma (or at least
an alias of the vma) is shared with userspace, so we may leak the
existence of such guards if we are not careful to ensure that the
execobj.offset is transparent and excludes the guards. (On such platforms,
without full-ppgtt, userspace has to use relocations so the presence of
more untouchable regions within its GTT such be of no further issue.)
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
drivers/gpu/drm/i915/i915_vma.c | 10 +++---
drivers/gpu/drm/i915/i915_vma.h | 8
drivers/gpu/drm/i915/i915_vma_types.h | 3 ++-
4 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index c5803c434d33..6b326138e765 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -238,8 +238,12 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
gte = (gen8_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
- end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+ end = gte + vma->guard / I915_GTT_PAGE_SIZE;
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+ end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma->pages)
gen8_set_pte(gte++, pte_encode | addr);
GEM_BUG_ON(gte > end);
@@ -289,8 +293,12 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
gte = (gen6_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
- end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+ end = gte + vma->guard / I915_GTT_PAGE_SIZE;
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+ end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma->pages)
iowrite32(vm->pte_encode(addr, level, flags), gte++);
GEM_BUG_ON(gte > end);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 17fe455bd770..155f510b4cc6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -623,7 +623,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
static int
i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
{
- unsigned long color;
+ unsigned long color, guard;
u64 start, end;
int ret;
@@ -631,13 +631,16 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
GEM_BUG_ON(drm_mm_node_allocated(>node));
size = max(size, vma->size);
- alignment = max(alignment, vma->display_alignment);
+ alignment = max_t(typeof(alignment), alignment, vma->display_alignment);
if (flags & PIN_MAPPABLE) {
size = max_t(typeof(size), size, vma->fence_size);
alignment = max_t(typeof(alignment),
alignment, vma->fence_alignment);
}
+ guard = 0;
+ size += 2 * guard;
+
GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
GEM_BUG_ON(!is_power_of_2(alignment));
@@ -674,7 +677,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
return -EINVAL;
ret = i915_gem_gtt_reserve(vma->vm, >node,
- size, offset, color,
+ size, offset - guard, color,
flags);
if (ret)
return ret;
@@ -725,6 +728,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
[Intel-gfx] [PATCH 1/3] drm/i915: Wrap all access to i915_vma.node.start|size
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.
The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 6 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 29 ++-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +--
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 11 +++
.../drm/i915/gem/selftests/i915_gem_context.c | 16 ++
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 4 +--
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 ++---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 5 ++--
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 +++--
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 ++---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 14 +
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +--
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 21 +++---
drivers/gpu/drm/i915/i915_vma.h | 18 ++--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 ++--
drivers/gpu/drm/i915/selftests/i915_request.c | 8 ++---
.../gpu/drm/i915/selftests/i915_scheduler.c | 4 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 9 --
32 files changed, 134 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 07db8e83f98e..2a72fb3c8416 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -237,8 +237,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
- (unsigned long)(ggtt->gmadr.start + vma->node.start);
- info->fix.smem_len = vma->node.size;
+ (unsigned long)(ggtt->gmadr.start + i915_ggtt_offset(vma));
+ info->fix.smem_len = vma->size;
vaddr = i915_vma_pin_iomap(vma);
if (IS_ERR(vaddr)) {
@@ -248,7 +248,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unpin;
}
info->screen_base = vaddr;
- info->screen_size = vma->node.size;
+ info->screen_size = vma->size;
drm_fb_helper_fill_info(info, >helper, sizes);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index fe170186dd42..f75f6751cf3f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -368,22 +368,23 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size < entry->pad_to_size)
+ const u64 start = i915_vma_offset(vma);
+ const u64 size = i915_vma_size(vma);
+
+ if (size < entry->pad_to_size)
return true;
- if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
+ if (entry->alignment && !IS_ALIGNED(start, entry->alignment))
return true;
- if (flags & EXEC_OBJECT_PINNED &&
- vma->node.start != entry->offset)
+ if (flags & EXEC_OBJECT_PINNED && start != entry->offset)
return true;
- if (flags & __EXEC_OBJECT_NEEDS_BIAS &&
- vma->node.start < BATCH_OFFSET_BIAS)
+ if (flags & __EXEC_OBJECT_NEEDS_BIAS && start < BATCH_OFFSET_BIAS)
return true;
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size + 4095) >> 32)
+ (start
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc NULL check (rev3)
Pushed to drm-intel-next. Thanks for review and re-reporting. Br, Anshuman Gupta. > -Original Message- > From: Vudum, Lakshminarayana > Sent: Friday, February 12, 2021 11:56 AM > To: Gupta, Anshuman > Cc: intel-gfx@lists.freedesktop.org > Subject: RE: ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc > NULL > check (rev3) > > Re-reported. > > -Original Message- > From: Anshuman Gupta > Sent: Thursday, February 11, 2021 7:45 PM > To: Vudum, Lakshminarayana > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/debugfs: HDCP capability enc > NULL > check (rev3) > > On 2021-02-11 at 16:42:07 +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/debugfs: HDCP capability enc NULL check (rev3) > > URL : https://patchwork.freedesktop.org/series/86440/ > > State : failure > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_9761_full -> Patchwork_19664_full > > > > > > Summary > > --- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_19664_full absolutely > need to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_19664_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_19664_full: > > > > ### IGT changes ### > > > > Possible regressions > > > > * igt@perf_pmu@cpu-hotplug: > > - shard-iclb: [PASS][1] -> [TIMEOUT][2] > >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard- > iclb6/igt@perf_...@cpu-hotplug.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-iclb7/i > > gt@perf_...@cpu-hotplug.html > Hi Lakshmi , > Above failure are not related to this series. > could you please create a issue for above failure ans re-report the results. > Thanks, > Anshuman Gupta. > > > > > > Known issues > > > > > > Here are the changes found in Patchwork_19664_full that come from known > issues: > > > > ### IGT changes ### > > > > Issues hit > > > > * igt@core_hotunplug@unbind-rebind: > > - shard-hsw: NOTRUN -> [WARN][3] ([i915#2283]) > >[3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/ig > > t@core_hotunp...@unbind-rebind.html > > > > * igt@gem_ctx_persistence@engines-mixed: > > - shard-hsw: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) > >[4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw6/ig > > t@gem_ctx_persiste...@engines-mixed.html > > > > * igt@gem_ctx_persistence@replace-hostile: > > - shard-hsw: NOTRUN -> [SKIP][5] ([fdo#109271]) +59 similar > > issues > >[5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-hsw4/ig > > t@gem_ctx_persiste...@replace-hostile.html > > > > * igt@gem_ctx_sseu@invalid-args: > > - shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271]) +34 similar > > issues > >[6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-apl2/ig > > t@gem_ctx_s...@invalid-args.html > > > > * igt@gem_exec_create@forked: > > - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / > > [i915#95]) > >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard- > glk5/igt@gem_exec_cre...@forked.html > >[8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-glk5/ig > > t@gem_exec_cre...@forked.html > > > > * igt@gem_exec_fair@basic-deadline: > > - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2846]) > >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard- > kbl1/igt@gem_exec_f...@basic-deadline.html > >[10]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl3/ig > > t@gem_exec_f...@basic-deadline.html > > > > * igt@gem_exec_fair@basic-none@vcs0: > > - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar > > issues > >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard- > kbl2/igt@gem_exec_fair@basic-n...@vcs0.html > >[12]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-kbl7/ig > > t@gem_exec_fair@basic-n...@vcs0.html > > > > * igt@gem_exec_fair@basic-pace-share@rcs0: > > - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar > > issue > >[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9761/shard- > tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > >[14]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19664/shard-tglb7/i > > gt@gem_exec_fair@basic-pace-sh...@rcs0.html > > > > * igt@gem_exec_reloc@basic-wide-active@vcs1: > > - shard-iclb: NOTRUN ->
