Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Limit max_requested_bpc based on src DSC bpc limits
On 10/25/2023 6:20 PM, Ville Syrjälä wrote:
On Wed, Oct 25, 2023 at 05:43:18PM +0530, Ankit Nautiyal wrote:
At the moment the max requested bpc is limited to 6 to 10/12.
For platforms that support DSC, min and max src bpc with DSC are
different.
Account for DSC bpc limitations, when setting min and max value for
max_requested_bpc property.
NAK. DSC capabiliies change dynamically, the property does not.
Hmm, perhaps I should remove the check for sink DSC support and have
only Platform check HAS_DSC.
The problem I am trying to fix is that our HW does not support DSC with
6bpc, but we are allowing the max_requested_bpc to be 6 bpc.
This can be a problem with some eDP panels that support modes like
4k@120 which will always need DSC and when max requested bpc property is
set to 6.
I am wondering how to avoid this. Does it make sense to have the min
value for the max_requested_bpc to be 8, for platforms that support DSC?
Regards,
Ankit
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index abc718f1a878..1935b9014b12 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5907,8 +5907,17 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_broadcast_rgb_property(connector);
if (HAS_GMCH(dev_priv))
drm_connector_attach_max_bpc_property(connector, 6, 10);
- else if (DISPLAY_VER(dev_priv) >= 5)
- drm_connector_attach_max_bpc_property(connector, 6, 12);
+ else if (DISPLAY_VER(dev_priv) >= 5) {
+ int min_bpc = 6, max_bpc = 12;
+ struct intel_connector *intel_connector =
to_intel_connector(connector);
+
+ if (HAS_DSC(dev_priv) &&
drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
+ min_bpc = intel_dp_dsc_min_src_input_bpc(dev_priv);
+ max_bpc = intel_dp_dsc_max_src_input_bpc(dev_priv);
+ }
+
+ drm_connector_attach_max_bpc_property(connector, min_bpc,
max_bpc);
+ }
/* Register HDMI colorspace for case of lspcon */
if
(intel_bios_encoder_is_lspcon(dp_to_dig_port(intel_dp)->base.devdata)) {
--
2.40.1
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file reference for mmap_singleton()y
Hi, CI is always testing against https://cgit.freedesktop.org/drm-tip Br Jani > -Original Message- > From: Intel-gfx On Behalf Of > Christian > Brauner > Sent: Wednesday, October 25, 2023 11:39 PM > To: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file > reference for > mmap_singleton()y > > On Wed, Oct 25, 2023 at 08:16:23PM -, Patchwork wrote: > > == Series Details == > > > > Series: file, i915: fix file reference for mmap_singleton() > > URL : https://patchwork.freedesktop.org/series/125570/ > > State : failure > > > > == Summary == > > > > Error: patch > > https://patchwork.freedesktop.org/api/1.0/series/125570/revisions/1/mb > > ox/ not applied > > Applying: file, i915: fix file reference for mmap_singleton() Using > > index info to reconstruct a base tree... > > M drivers/gpu/drm/i915/gem/i915_gem_mman.c > > M fs/file.c > > M include/linux/fs.h > > Falling back to patching base and 3-way merge... > > Auto-merging include/linux/fs.h > > CONFLICT (content): Merge conflict in include/linux/fs.h Auto-merging > > fs/file.c CONFLICT (content): Merge conflict in fs/file.c Auto-merging > > drivers/gpu/drm/i915/gem/i915_gem_mman.c > > CONFLICT (content): Merge conflict in > > drivers/gpu/drm/i915/gem/i915_gem_mman.c > > error: Failed to merge in the changes. > > hint: Use 'git am --show-current-patch=diff' to see the failed patch > > Patch failed at 0001 file, i915: fix file reference for > > mmap_singleton() When you have resolved this problem, run "git am -- > continue". > > If you prefer to skip this patch, run "git am --skip" instead. > > To restore the original branch and stop patching, run "git am --abort". > > Build failed, no error log produced > > I'm not sure what tree you're testing on but please test on whatever is in > vfs.misc, I guess which has that patch. > git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
[Intel-gfx] [PATCH] drm/i915/gt: Remove {} from if-else
In accordance to Linux coding style(Documentation/process/4.Coding.rst),
remove unneeded braces from if-else block as all arms of this block
contain single statements.
Suggested-by: Andi Shyti
Signed-off-by: Soumya Negi
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1c93e84278a0..9f6f9e138532 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -226,16 +226,15 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
gen8_ggtt_invalidate(ggtt);
list_for_each_entry(gt, >gt_list, ggtt_link) {
- if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+ if (intel_guc_tlb_invalidation_is_available(>uc.guc))
guc_ggtt_ct_invalidate(gt);
- } else if (GRAPHICS_VER(i915) >= 12) {
+ else if (GRAPHICS_VER(i915) >= 12)
intel_uncore_write_fw(gt->uncore,
GEN12_GUC_TLB_INV_CR,
GEN12_GUC_TLB_INV_CR_INVALIDATE);
- } else {
+ else
intel_uncore_write_fw(gt->uncore,
GEN8_GTCR, GEN8_GTCR_INVALIDATE);
- }
}
}
--
2.42.0
[Intel-gfx] ✓ Fi.CI.BAT: success for debugobjects: stop accessing objects after releasing spinlock (rev3)
== Series Details == Series: debugobjects: stop accessing objects after releasing spinlock (rev3) URL : https://patchwork.freedesktop.org/series/124185/ State : success == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_124185v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/index.html Participating hosts (38 -> 40) -- Additional (3): fi-kbl-soraka bat-adlp-11 bat-dg1-5 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_124185v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][1] ([i915#9318]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 other tests skip [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 other test skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#3282]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#6621]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4212]) +7 other tests skip [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4215]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#4103] / [i915#5608]) +1 other test skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213]) +1 other test skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271]) +9 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/fi-kbl-soraka/igt@kms_...@dsc-basic.html - bat-adlp-11:NOTRUN -> [SKIP][15] ([i915#3555] / [i915#3840]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-adlp-11/igt@kms_...@dsc-basic.html - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#3840]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-5: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-adlp-11:NOTRUN -> [SKIP][18] ([i915#4093]) +3 other tests skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124185v3/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_hdmi_inject@inject-audio: - bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#433]) [19]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for debugobjects: stop accessing objects after releasing spinlock (rev3)
== Series Details ==
Series: debugobjects: stop accessing objects after releasing spinlock (rev3)
URL : https://patchwork.freedesktop.org/series/124185/
State : warning
== Summary ==
Error: dim checkpatch failed
bdb4ac71599d debugobjects: stop accessing objects after releasing spinlock
-:13: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line
(possible unwrapped commit description?)
#13:
2. Other thread frees debugobject, then allocates new one on the same memory
-:88: WARNING:LIKELY_MISUSE: nested (un)?likely() calls, IS_ERR already uses
unlikely() internally
#88: FILE: lib/debugobjects.c:715:
+ } else if (likely(!IS_ERR(obj))) {
-:384: CHECK:SPACING: No space is necessary after a cast
#384: FILE: lib/debugobjects.c:992:
+ (void *) oaddr, o.state);
total: 0 errors, 2 warnings, 1 checks, 350 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init (rev2)
== Series Details == Series: drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init (rev2) URL : https://patchwork.freedesktop.org/series/125576/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125576v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125576v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125576v2, please notify your bug team (lgci.bug.fil...@intel.com) 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_125576v2/index.html Participating hosts (38 -> 38) -- Additional (3): fi-kbl-soraka bat-adlp-11 bat-dg1-5 Missing(3): fi-bsw-n3050 fi-snb-2520m fi-pnv-d510 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125576v2: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-guc: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-skl-guc/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/fi-skl-guc/igt@gem_exec_suspend@basic...@smem.html Known issues Here are the changes found in Patchwork_125576v2 that come from known issues: ### CI changes ### Possible fixes * boot: - bat-jsl-1: [FAIL][3] ([i915#8293]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][5] ([i915#9318]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][6] ([i915#9318]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_suspend@basic-s0@lmem0: - bat-dg2-9: [PASS][7] -> [INCOMPLETE][8] ([i915#9275]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][9] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 other tests skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][12] ([i915#4613]) +3 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4083]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4077]) +2 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4079]) +1 other test skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][16] ([i915#3282]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#6621]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][18] ([i915#5334] / [i915#7872]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125576v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][19] ([i915#1886]) [19]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file reference for mmap_singleton() (rev2)
== Series Details == Series: file, i915: fix file reference for mmap_singleton() (rev2) URL : https://patchwork.freedesktop.org/series/125570/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/125570/revisions/2/mbox/ not applied Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To record the empty patch as an empty commit, run "git am --allow-empty". To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
Re: [Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()
On Wed, 25 Oct 2023 at 10:36, Christian Brauner wrote: > > I did think that the loop didn't really matter for this case but since > it seemingly does paper over the weird semantics here let's drop it. > Anyway, pushed to: > > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs.misc LGTM. We could then make the i915 mmap_singleton() do the proper loop over the whole thing. Not quite the way Jann suggested - which would not increment the file refcount properly, but instead of the current smp_store_mb(i915->gem.mmap_singleton, file); drm_dev_get(>drm); return file; it could do something much more complicated like drm_dev_get(>drm); if (cmpxchg(>gem.mmap_singleton, NULL, file) == NULL) return file; // mmap_singleton wasn't NULL: it might be an old one in the // process of being torn down (with a zero refcount), or a new // one that was just installed that we should use instead fput(file); file = READ_ONCE(i915->gem.mmap_singleton); if (!file) goto repeat; // Is it valid? Just try again if (atomic_read(>f_count)) goto repeat; // We have a file pointer, but it's in the process of being torn // down but gem.mmap_singleton hasn't been cleared yet. Yield to // make progress. sched_yield(); goto repeat; which is disgusting, but would probably work. Note the "probably work". I'm handwaving: "something like the above". Presumably not even worth doing - I assume a correct client always just does a single mmap() before starting work. Linus
[Intel-gfx] ✓ Fi.CI.BAT: success for Add gt_to_guc and guc_to_i915 helpers
== Series Details ==
Series: Add gt_to_guc and guc_to_i915 helpers
URL : https://patchwork.freedesktop.org/series/125583/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125583v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/index.html
Participating hosts (38 -> 37)
--
Additional (1): bat-adlp-11
Missing(2): fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_125583v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- bat-jsl-1: [FAIL][1] ([i915#8293]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/boot.html
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#9318])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html
- bat-jsl-1: NOTRUN -> [SKIP][4] ([i915#9318])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- bat-jsl-1: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- bat-jsl-1: NOTRUN -> [SKIP][6] ([i915#4613]) +3 other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#3282])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-adlp-11/igt@gem_tiled_pread_basic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][8] ([i915#4103] / [i915#5608]) +1
other test skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-jsl-1: NOTRUN -> [SKIP][9] ([i915#4103]) +1 other test skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-basic:
- bat-adlp-11:NOTRUN -> [SKIP][10] ([i915#3555] / [i915#3840])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-adlp-11/igt@kms_...@dsc-basic.html
- bat-jsl-1: NOTRUN -> [SKIP][11] ([i915#3555]) +1 other test skip
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-jsl-1: NOTRUN -> [SKIP][12] ([fdo#109285])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][13] ([i915#4093]) +3 other tests skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_hdmi_inject@inject-audio:
- bat-adlp-11:NOTRUN -> [SKIP][14] ([i915#4369])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/bat-adlp-11/igt@kms_hdmi_inj...@inject-audio.html
Possible fixes
* igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][15] ([IGT#3]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125583v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#4093]: https://gitlab.freedesktop.org/drm/intel/issues/4093
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5608]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add gt_to_guc and guc_to_i915 helpers
== Series Details == Series: Add gt_to_guc and guc_to_i915 helpers URL : https://patchwork.freedesktop.org/series/125583/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.BAT: failure for Cleanup a few functions in C10/C20 handling (rev2)
== Series Details == Series: Cleanup a few functions in C10/C20 handling (rev2) URL : https://patchwork.freedesktop.org/series/125323/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125323v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125323v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125323v2, please notify your bug team (lgci.bug.fil...@intel.com) 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_125323v2/index.html Participating hosts (38 -> 37) -- Additional (2): bat-adlp-11 bat-dg1-5 Missing(3): bat-kbl-2 fi-snb-2520m fi-pnv-d510 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125323v2: ### IGT changes ### Possible regressions * igt@gem_lmem_swapping@basic@lmem0: - bat-atsm-1: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-atsm-1/igt@gem_lmem_swapping@ba...@lmem0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-atsm-1/igt@gem_lmem_swapping@ba...@lmem0.html Known issues Here are the changes found in Patchwork_125323v2 that come from known issues: ### CI changes ### Issues hit * boot: - fi-hsw-4770:[PASS][3] -> [FAIL][4] ([i915#8293]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-hsw-4770/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/fi-hsw-4770/boot.html Possible fixes * boot: - bat-jsl-1: [FAIL][5] ([i915#8293]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#9318]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][8] ([i915#9318]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][9] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-jsl-1/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4083]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4077]) +2 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][14] ([i915#3282]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#6621]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4212]) +7 other tests skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4215]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][18] ([i915#4103] / [i915#5608]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125323v2/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-jsl-1: NOTRUN -> [SKIP][19] ([i915#4103]) +1 other test skip [19]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Cleanup a few functions in C10/C20 handling (rev2)
== Series Details == Series: Cleanup a few functions in C10/C20 handling (rev2) URL : https://patchwork.freedesktop.org/series/125323/ State : warning == Summary == Error: dim checkpatch failed 09fd1c2c911d drm/i915/display: Abstract C10/C20 pll hw readout f52ea88bef32 drm/i915/display: Abstract C10/C20 pll calculation -:98: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #98: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:3863: + crtc_state->port_clock = intel_cx0pll_calc_port_clock(encoder, _state->cx0pll_state); total: 0 errors, 1 warnings, 0 checks, 96 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/125580/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125580v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125580v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125580v1, please notify your bug team (lgci.bug.fil...@intel.com) 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_125580v1/index.html Participating hosts (38 -> 39) -- Additional (2): bat-adlp-11 bat-dg1-5 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125580v1: ### IGT changes ### Possible regressions * igt@gem_softpin@allocator-basic: - bat-dg2-11: [PASS][1] -> [FAIL][2] +3 other tests fail [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-dg2-11/igt@gem_soft...@allocator-basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-dg2-11/igt@gem_soft...@allocator-basic.html * igt@gem_softpin@allocator-basic-reserve: - bat-atsm-1: [PASS][3] -> [FAIL][4] +2 other tests fail [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-atsm-1/igt@gem_soft...@allocator-basic-reserve.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-atsm-1/igt@gem_soft...@allocator-basic-reserve.html - bat-dg2-9: [PASS][5] -> [FAIL][6] +3 other tests fail [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-dg2-9/igt@gem_soft...@allocator-basic-reserve.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-dg2-9/igt@gem_soft...@allocator-basic-reserve.html * igt@i915_selftest@live@gtt: - bat-atsm-1: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-atsm-1/igt@i915_selftest@l...@gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-atsm-1/igt@i915_selftest@l...@gtt.html - fi-cfl-guc: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-cfl-guc/igt@i915_selftest@l...@gtt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/fi-cfl-guc/igt@i915_selftest@l...@gtt.html - bat-jsl-3: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-3/igt@i915_selftest@l...@gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-jsl-3/igt@i915_selftest@l...@gtt.html - bat-dg2-9: [PASS][13] -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-dg2-9/igt@i915_selftest@l...@gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-dg2-9/igt@i915_selftest@l...@gtt.html - fi-kbl-x1275: [PASS][15] -> [DMESG-FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-kbl-x1275/igt@i915_selftest@l...@gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/fi-kbl-x1275/igt@i915_selftest@l...@gtt.html - fi-cfl-8109u: [PASS][17] -> [DMESG-FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-cfl-8109u/igt@i915_selftest@l...@gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/fi-cfl-8109u/igt@i915_selftest@l...@gtt.html - bat-mtlp-8: [PASS][19] -> [DMESG-FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-mtlp-8/igt@i915_selftest@l...@gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-mtlp-8/igt@i915_selftest@l...@gtt.html - fi-kbl-guc: [PASS][21] -> [DMESG-FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-kbl-guc/igt@i915_selftest@l...@gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/fi-kbl-guc/igt@i915_selftest@l...@gtt.html - bat-adlm-1: [PASS][23] -> [DMESG-FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-adlm-1/igt@i915_selftest@l...@gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-adlm-1/igt@i915_selftest@l...@gtt.html - bat-jsl-1: NOTRUN -> [DMESG-FAIL][25] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125580v1/bat-jsl-1/igt@i915_selftest@l...@gtt.html - fi-tgl-1115g4: [PASS][26] -> [DMESG-FAIL][27] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-tgl-1115g4/igt@i915_selftest@l...@gtt.html [27]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/125580/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/125580/ State : warning == Summary == Error: dim checkpatch failed 9bcc31776a08 drm/i915: Reserve some kernel space per vm 558c3bcd5f24 drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 -:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine' - possible side-effects? #39: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:85: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS && engine->instance == 0) -:39: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'engine' may be better as '(engine)' to avoid precedence issues #39: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:85: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS && engine->instance == 0) -:59: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #59: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:836: + GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1); -:174: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #174: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1498: + GEM_BUG_ON(cs - start > I915_GTT_PAGE_SIZE / sizeof(*cs)); total: 0 errors, 2 warnings, 2 checks, 168 lines checked 1f7c34f99971 drm/i915/gt: add selftest to exercise WABB 5dca503f70b0 drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
[Intel-gfx] [PATCH v3] debugobjects: stop accessing objects after releasing spinlock
s;
if (!debug_objects_enabled)
@@ -885,24 +852,26 @@ void debug_object_free(void *addr, const struct
debug_obj_descr *descr)
raw_spin_lock_irqsave(>lock, flags);
obj = lookup_object(addr, db);
- if (!obj)
- goto out_unlock;
+ if (!obj) {
+ raw_spin_unlock_irqrestore(>lock, flags);
+ return;
+ }
switch (obj->state) {
case ODEBUG_STATE_ACTIVE:
- state = obj->state;
- raw_spin_unlock_irqrestore(>lock, flags);
- debug_print_object(obj, "free");
- debug_object_fixup(descr->fixup_free, addr, state);
- return;
+ break;
default:
hlist_del(>node);
raw_spin_unlock_irqrestore(>lock, flags);
free_object(obj);
return;
}
-out_unlock:
+
+ o = *obj;
raw_spin_unlock_irqrestore(>lock, flags);
+ debug_print_object(, "free");
+
+ debug_object_fixup(descr->fixup_free, addr, o.state);
}
EXPORT_SYMBOL_GPL(debug_object_free);
@@ -954,10 +923,10 @@ void
debug_object_active_state(void *addr, const struct debug_obj_descr *descr,
unsigned int expect, unsigned int next)
{
+ struct debug_obj o = { .object = addr, .state =
ODEBUG_STATE_NOTAVAILABLE, .descr = descr };
struct debug_bucket *db;
struct debug_obj *obj;
unsigned long flags;
- bool print_object = false;
if (!debug_objects_enabled)
return;
@@ -970,28 +939,20 @@ debug_object_active_state(void *addr, const struct
debug_obj_descr *descr,
if (obj) {
switch (obj->state) {
case ODEBUG_STATE_ACTIVE:
- if (obj->astate == expect)
+ if (obj->astate == expect) {
obj->astate = next;
- else
- print_object = true;
+ raw_spin_unlock_irqrestore(>lock, flags);
+ return;
+ }
break;
-
default:
- print_object = true;
break;
}
+ o = *obj;
}
raw_spin_unlock_irqrestore(>lock, flags);
- if (!obj) {
- struct debug_obj o = { .object = addr,
- .state = ODEBUG_STATE_NOTAVAILABLE,
- .descr = descr };
-
- debug_print_object(, "active_state");
- } else if (print_object) {
- debug_print_object(obj, "active_state");
- }
+ debug_print_object(, "active_state");
}
EXPORT_SYMBOL_GPL(debug_object_active_state);
@@ -999,11 +960,9 @@ EXPORT_SYMBOL_GPL(debug_object_active_state);
static void __debug_check_no_obj_freed(const void *address, unsigned long size)
{
unsigned long flags, oaddr, saddr, eaddr, paddr, chunks;
- const struct debug_obj_descr *descr;
- enum debug_obj_state state;
struct debug_bucket *db;
struct hlist_node *tmp;
- struct debug_obj *obj;
+ struct debug_obj *obj, o;
int cnt, objs_checked = 0;
saddr = (unsigned long) address;
@@ -1026,12 +985,11 @@ static void __debug_check_no_obj_freed(const void
*address, unsigned long size)
switch (obj->state) {
case ODEBUG_STATE_ACTIVE:
- descr = obj->descr;
- state = obj->state;
+ o = *obj;
raw_spin_unlock_irqrestore(>lock, flags);
- debug_print_object(obj, "free");
- debug_object_fixup(descr->fixup_free,
- (void *) oaddr, state);
+ debug_print_object(, "free");
+ debug_object_fixup(o.descr->fixup_free,
+ (void *) oaddr, o.state);
goto repeat;
default:
hlist_del(>node);
---
base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe
change-id: 20231025-debugobjects_fix-66e5292557c4
Best regards,
--
Andrzej Hajda
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add Wa_22016670082
== Series Details ==
Series: drm/i915/mtl: Add Wa_22016670082
URL : https://patchwork.freedesktop.org/series/125574/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125574v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/index.html
Participating hosts (38 -> 39)
--
Additional (3): fi-kbl-soraka bat-adlp-11 bat-dg1-5
Missing(2): bat-mtlp-8 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_125574v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_pm_backlight@basic-brightness@edp-1}:
- bat-rplp-1: [ABORT][1] ([i915#8668]) -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-rplp-1/igt@kms_pm_backlight@basic-brightn...@edp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-rplp-1/igt@kms_pm_backlight@basic-brightn...@edp-1.html
Known issues
Here are the changes found in Patchwork_125574v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- bat-adlp-11:NOTRUN -> [FAIL][3] ([i915#8293])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-adlp-11/boot.html
Possible fixes
* boot:
- bat-jsl-1: [FAIL][4] ([i915#8293]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-jsl-1/boot.html
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-jsl-1: NOTRUN -> [SKIP][6] ([i915#9318])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- bat-jsl-1: NOTRUN -> [SKIP][7] ([i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3
other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@verify-random:
- bat-jsl-1: NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4083])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4077]) +2 other tests skip
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#6621])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][15] ([i915#1886])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4212]) +7 other tests skip
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4215])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-jsl-1: NOTRUN -> [SKIP][18] ([i915#4103]) +1 other test skip
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125574v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#4103] / [i915#4213]) +1
other test skip
[19]:
[Intel-gfx] ✓ Fi.CI.BAT: success for DP DSC min/max src bpc fixes
== Series Details == Series: DP DSC min/max src bpc fixes URL : https://patchwork.freedesktop.org/series/125571/ State : success == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125571v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/index.html Participating hosts (38 -> 38) -- Additional (3): fi-kbl-soraka bat-adlp-11 bat-dg1-5 Missing(3): fi-hsw-4770 bat-atsm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_125571v1 that come from known issues: ### CI changes ### Possible fixes * boot: - bat-jsl-1: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#9318]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][4] ([i915#9318]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][5] ([i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][8] ([i915#4613]) +3 other tests skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4077]) +2 other tests skip [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4079]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#3282]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#6621]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][14] ([i915#1886]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4212]) +7 other tests skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4215]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][17] ([i915#4103] / [i915#5608]) +1 other test skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-jsl-1: NOTRUN -> [SKIP][18] ([i915#4103]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#4103] / [i915#4213]) +1 other test skip [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125571v1/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - fi-kbl-soraka: NOTRUN -> [SKIP][20] ([fdo#109271]) +9 other tests skip [20]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DP DSC min/max src bpc fixes
== Series Details == Series: DP DSC min/max src bpc fixes URL : https://patchwork.freedesktop.org/series/125571/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file reference for mmap_singleton()y
On Wed, Oct 25, 2023 at 08:16:23PM -, Patchwork wrote: > == Series Details == > > Series: file, i915: fix file reference for mmap_singleton() > URL : https://patchwork.freedesktop.org/series/125570/ > State : failure > > == Summary == > > Error: patch > https://patchwork.freedesktop.org/api/1.0/series/125570/revisions/1/mbox/ not > applied > Applying: file, i915: fix file reference for mmap_singleton() > Using index info to reconstruct a base tree... > M drivers/gpu/drm/i915/gem/i915_gem_mman.c > M fs/file.c > M include/linux/fs.h > Falling back to patching base and 3-way merge... > Auto-merging include/linux/fs.h > CONFLICT (content): Merge conflict in include/linux/fs.h > Auto-merging fs/file.c > CONFLICT (content): Merge conflict in fs/file.c > Auto-merging drivers/gpu/drm/i915/gem/i915_gem_mman.c > CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_mman.c > error: Failed to merge in the changes. > hint: Use 'git am --show-current-patch=diff' to see the failed patch > Patch failed at 0001 file, i915: fix file reference for mmap_singleton() > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > Build failed, no error log produced I'm not sure what tree you're testing on but please test on whatever is in vfs.misc, I guess which has that patch. git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
Re: [Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()
ut what it actually does. It seems
that the i915->gem.mmap_singleton pointer itself never had rcu semantics.
The i915->gem.mmap_singleton is replaced in
file->f_op->release::singleton_release():
static int singleton_release(struct inode *inode, struct file *file)
{
struct drm_i915_private *i915 = file->private_data;
cmpxchg(>gem.mmap_singleton, file, NULL);
drm_dev_put(>drm);
return 0;
}
The cmpxchg() is ordered against a concurrent update of
i915->gem.mmap_singleton from mmap_singleton(). IOW, when
mmap_singleton() fails to get a reference on i915->gem.mmap_singleton:
While mmap_singleton() does
rcu_read_lock();
file = get_file_rcu(>gem.mmap_singleton);
rcu_read_unlock();
it allocates a new file via anon_inode_getfile() and does
smp_store_mb(i915->gem.mmap_singleton, file);
So, then what happens in the case of this bug is that at some point
fput() is called and drops the file->f_count to zero leaving the pointer
in i915->gem.mmap_singleton in tact.
Now, there might be delays until
file->f_op->release::singleton_release() is called and
i915->gem.mmap_singleton is set to NULL.
Say concurrently another task hits mmap_singleton() and does:
rcu_read_lock();
file = get_file_rcu(>gem.mmap_singleton);
rcu_read_unlock();
When get_file_rcu() fails to get a reference via atomic_inc_not_zero()
it will try the reload from i915->gem.mmap_singleton expecting it to be
NULL, assuming it has comparable semantics as we expect in
__fget_files_rcu().
But it hasn't so it reloads the same pointer again, trying the same
atomic_inc_not_zero() again and doing so until
file->f_op->release::singleton_release() of the old file has been
called.
So, in contrast to __fget_files_rcu() here we want to not retry when
atomic_inc_not_zero() has failed. We only want to retry in case we
managed to get a reference but the pointer did change on reload.
<3> [511.395679] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
<3> [511.395716] rcu: Tasks blocked on level-1 rcu_node (CPUs 0-9): P6238
<3> [511.395934] rcu: (detected by 16, t=65002 jiffies, g=123977, q=439 ncpus=20)
<6> [511.395944] task:i915_selftest state:R running task stack:10568 pid:6238 tgid:6238 ppid:1001 flags:0x4002
<6> [511.395962] Call Trace:
<6> [511.395966]
<6> [511.395974] ? __schedule+0x3a8/0xd70
<6> [511.395995] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
<6> [511.396003] ? lockdep_hardirqs_on+0xc3/0x140
<6> [511.396013] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
<6> [511.396029] ? get_file_rcu+0x10/0x30
<6> [511.396039] ? get_file_rcu+0x10/0x30
<6> [511.396046] ? i915_gem_object_mmap+0xbc/0x450 [i915]
<6> [511.396509] ? i915_gem_mmap+0x272/0x480 [i915]
<6> [511.396903] ? mmap_region+0x253/0xb60
<6> [511.396925] ? do_mmap+0x334/0x5c0
<6> [511.396939] ? vm_mmap_pgoff+0x9f/0x1c0
<6> [511.396949] ? rcu_is_watching+0x11/0x50
<6> [511.396962] ? igt_mmap_offset+0xfc/0x110 [i915]
<6> [511.397376] ? __igt_mmap+0xb3/0x570 [i915]
<6> [511.397762] ? igt_mmap+0x11e/0x150 [i915]
<6> [511.398139] ? __trace_bprintk+0x76/0x90
<6> [511.398156] ? __i915_subtests+0xbf/0x240 [i915]
<6> [511.398586] ? __pfx___i915_live_setup+0x10/0x10 [i915]
<6> [511.399001] ? __pfx___i915_live_teardown+0x10/0x10 [i915]
<6> [511.399433] ? __run_selftests+0xbc/0x1a0 [i915]
<6> [511.399875] ? i915_live_selftests+0x4b/0x90 [i915]
<6> [511.400308] ? i915_pci_probe+0x106/0x200 [i915]
<6> [511.400692] ? pci_device_probe+0x95/0x120
<6> [511.400704] ? really_probe+0x164/0x3c0
<6> [511.400715] ? __pfx___driver_attach+0x10/0x10
<6> [511.400722] ? __driver_probe_device+0x73/0x160
<6> [511.400731] ? driver_probe_device+0x19/0xa0
<6> [511.400741] ? __driver_attach+0xb6/0x180
<6> [511.400749] ? __pfx___driver_attach+0x10/0x10
<6> [511.400756] ? bus_for_each_dev+0x77/0xd0
<6> [511.400770] ? bus_add_driver+0x114/0x210
<6> [511.400781] ? driver_register+0x5b/0x110
<6> [511.400791] ? i915_init+0x23/0xc0 [i915]
<6> [511.401153] ? __pfx_i915_init+0x10/0x10 [i915]
<6> [511.401503] ? do_one_initcall+0x57/0x270
<6> [511.401515] ? rcu_is_watching+0x11/0x50
<6> [511.401521] ? kmalloc_trace+0xa3/0xb0
<6> [511.401532] ? do_init_module+0x5f/0x210
<6> [511.401544] ? load_module+0x1d00/0x1f60
<6> [511.401581] ? init_module_from_file+0x86/0xd0
<6> [511.401590] ? init_module_from_file+0x86/0xd0
<6> [511.401613] ? idempotent_init_module+0x17c/0x230
<6> [511.401639] ? __x64_sys_finit_module+0x56/0xb0
<6> [511.401650] ? do_syscall_64+0x3c/0x90
<6> [511.401659] ? entry_SYSC
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Darkscreen Feature
== Series Details == Series: Enable Darkscreen Feature URL : https://patchwork.freedesktop.org/series/125563/ State : success == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125563v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/index.html Participating hosts (38 -> 38) -- Additional (2): bat-adlp-11 bat-dg1-5 Missing(2): fi-snb-2520m fi-pnv-d510 Known issues Here are the changes found in Patchwork_125563v1 that come from known issues: ### CI changes ### Possible fixes * boot: - bat-jsl-1: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#9318]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][4] ([i915#9318]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_suspend@basic-s0@lmem0: - bat-dg2-9: [PASS][5] -> [INCOMPLETE][6] ([i915#9275]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][7] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][8] ([i915#4613]) +3 other tests skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4077]) +2 other tests skip [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4079]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#3282]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_module_load@load: - bat-adlp-6: [PASS][13] -> [DMESG-WARN][14] ([i915#8449]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-adlp-6/igt@i915_module_l...@load.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-adlp-6/igt@i915_module_l...@load.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#6621]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4212]) +7 other tests skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4215]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][18] ([i915#4103] / [i915#5608]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-jsl-1: NOTRUN -> [SKIP][19] ([i915#4103]) +1 other test skip [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-dg1-5: NOTRUN -> [SKIP][20] ([i915#4103] / [i915#4213]) +1 other test skip [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125563v1/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][21] ([i915#3546]) [21]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file reference for mmap_singleton()
== Series Details == Series: file, i915: fix file reference for mmap_singleton() URL : https://patchwork.freedesktop.org/series/125570/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/125570/revisions/1/mbox/ not applied Applying: file, i915: fix file reference for mmap_singleton() Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gem/i915_gem_mman.c M fs/file.c M include/linux/fs.h Falling back to patching base and 3-way merge... Auto-merging include/linux/fs.h CONFLICT (content): Merge conflict in include/linux/fs.h Auto-merging fs/file.c CONFLICT (content): Merge conflict in fs/file.c Auto-merging drivers/gpu/drm/i915/gem/i915_gem_mman.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_mman.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 file, i915: fix file reference for mmap_singleton() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable Darkscreen Feature
== Series Details == Series: Enable Darkscreen Feature URL : https://patchwork.freedesktop.org/series/125563/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable Darkscreen Feature
== Series Details == Series: Enable Darkscreen Feature URL : https://patchwork.freedesktop.org/series/125563/ State : warning == Summary == Error: dim checkpatch failed 35c1fae9e76f drm/i915: Add Darkscreen registers and timer handler. Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:7: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?) #7: The logic checks for any black screen at pipe level and upon such detection prints error. -:26: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #26: new file mode 100644 total: 0 errors, 2 warnings, 0 checks, 146 lines checked 4d9018a68bf4 drm/i915: Add the darkscreen debugfs under crtc
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Add Wa_14019821291 (rev3)
== Series Details == Series: drm/i915/mtl: Add Wa_14019821291 (rev3) URL : https://patchwork.freedesktop.org/series/125282/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125282v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125282v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125282v3, please notify your bug team (lgci.bug.fil...@intel.com) 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_125282v3/index.html Participating hosts (38 -> 38) -- Additional (3): bat-dg2-8 bat-adlp-11 bat-dg1-5 Missing(3): fi-kbl-x1275 bat-dg2-9 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125282v3: ### CI changes ### Possible regressions * boot: - fi-blb-e6850: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-blb-e6850/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/fi-blb-e6850/boot.html Known issues Here are the changes found in Patchwork_125282v3 that come from known issues: ### CI changes ### Issues hit * boot: - bat-adlp-11:NOTRUN -> [FAIL][3] ([i915#8293]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-adlp-11/boot.html Possible fixes * boot: - bat-jsl-1: [FAIL][4] ([i915#8293]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-jsl-1: NOTRUN -> [SKIP][6] ([i915#9318]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][7] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-jsl-1/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][8] ([i915#4613]) +3 other tests skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg1-5/igt@gem_m...@basic.html - bat-dg2-8: NOTRUN -> [SKIP][10] ([i915#4083]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg2-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg2-8: NOTRUN -> [SKIP][11] ([i915#4077]) +2 other tests skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg2-8/igt@gem_mmap_...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4077]) +2 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-dg2-8: NOTRUN -> [SKIP][14] ([i915#4079]) +1 other test skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg2-8/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#6621]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg1-5/igt@i915_pm_...@basic-api.html - bat-dg2-8: NOTRUN -> [SKIP][16] ([i915#6621]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg2-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][17] -> [DMESG-FAIL][18] ([i915#5334]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_suspend@basic-s3-without-i915: - bat-dg2-8: NOTRUN -> [SKIP][19] ([i915#6645]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125282v3/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-dg2-8: NOTRUN -> [SKIP][20] ([i915#5190]) [20]:
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check if pmu is closed before stopping event
On Tue, Oct 24, 2023 at 02:20:33PM +0200, Andi Shyti wrote:
Hi Umesh,
On Fri, Oct 20, 2023 at 08:24:41AM -0700, Umesh Nerlige Ramappa wrote:
When the driver unbinds, pmu is unregistered and i915->uabi_engines is
set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine
events, it issues a warn_on because engine lookup fails.
All perf hooks are taking care of this using a pmu->closed flag that is
set when PMU unregisters. The stop event seems to have been left out.
Check for pmu->closed in pmu_event_stop as well.
Based on discussion here -
https://patchwork.freedesktop.org/patch/492079/?series=105790=2
v2: s/is/if/ in commit title
v3: Add fixes tag and cc stable
Cc: # v5.11+
Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Tvrtko Ursulin
argh! 4th time that this patch has been sent. Please next time
use:
git format-patch -v
Reviewed-by: Andi Shyti
No need to resend :-)
Sorry about the versioning. Will keep inn mind next time.
Thanks,
Umesh
Andi
---
drivers/gpu/drm/i915/i915_pmu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 108b675088ba..f861863eb7c1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -831,9 +831,18 @@ static void i915_pmu_event_start(struct perf_event *event,
int flags)
static void i915_pmu_event_stop(struct perf_event *event, int flags)
{
+ struct drm_i915_private *i915 =
+ container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = >pmu;
+
+ if (pmu->closed)
+ goto out;
+
if (flags & PERF_EF_UPDATE)
i915_pmu_event_read(event);
i915_pmu_disable(event);
+
+out:
event->hw.state = PERF_HES_STOPPED;
}
--
2.38.1
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add Wa_14019821291 (rev3)
== Series Details == Series: drm/i915/mtl: Add Wa_14019821291 (rev3) URL : https://patchwork.freedesktop.org/series/125282/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy expression type 31
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Apply notify_guc to all GTs
== Series Details == Series: drm/i915/mtl: Apply notify_guc to all GTs URL : https://patchwork.freedesktop.org/series/125560/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125560v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125560v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125560v1, please notify your bug team (lgci.bug.fil...@intel.com) 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_125560v1/index.html Participating hosts (38 -> 40) -- Additional (4): fi-kbl-soraka bat-dg2-8 bat-adlp-11 bat-dg1-5 Missing(2): bat-dg2-9 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125560v1: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3@smem: - bat-dg2-11: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/fi-kbl-soraka/igt@kms_addfb_ba...@basic-x-tiled-legacy.html Known issues Here are the changes found in Patchwork_125560v1 that come from known issues: ### CI changes ### Issues hit * boot: - fi-hsw-4770:[PASS][4] -> [FAIL][5] ([i915#8293]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-hsw-4770/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/fi-hsw-4770/boot.html Possible fixes * boot: - bat-jsl-1: [FAIL][6] ([i915#8293]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][8] ([i915#9318]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][9] ([i915#9318]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][10] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][13] ([i915#4613]) +3 other tests skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4083]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg1-5/igt@gem_m...@basic.html - bat-dg2-8: NOTRUN -> [SKIP][15] ([i915#4083]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg2-8/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg2-8: NOTRUN -> [SKIP][16] ([i915#4077]) +2 other tests skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg2-8/igt@gem_mmap_...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4077]) +2 other tests skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#4079]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-dg2-8: NOTRUN -> [SKIP][19] ([i915#4079]) +1 other test skip [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125560v1/bat-dg2-8/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][20] ([i915#3282]) [20]:
Re: [Intel-gfx] [PATCH v2] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
On 25.10.2023 19:08, Nirmoy Das wrote:
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name),
^~
"%c/TC#%d", port_name(port), tc_port + 1);
~
v2: use kasprintf(Imre)
Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port
struct")
Cc: Mika Kahola
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/display/intel_tc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 37b0f8529b4f..0fa54450d51b 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -58,7 +58,7 @@ struct intel_tc_port {
struct delayed_work link_reset_work;
int link_refcount;
bool legacy_port:1;
- char port_name[8];
+ char *port_name;
enum tc_port_mode mode;
enum tc_port_mode init_mode;
enum phy_fia phy_fia;
@@ -1875,8 +1875,10 @@ int intel_tc_port_init(struct intel_digital_port
*dig_port, bool is_legacy)
else
tc->phy_ops = _tc_phy_ops;
- snprintf(tc->port_name, sizeof(tc->port_name),
-"%c/TC#%d", port_name(port), tc_port + 1);
+ tc->port_name = kasprintf(GFP_KERNEL, "%c/TC#%d", port_name(port),
+ tc_port + 1);
+ if (!tc->port_name)
+ return -ENOMEM;
mutex_init(>lock);
/* TODO: Combine the two works */
@@ -1897,6 +1899,7 @@ void intel_tc_port_cleanup(struct intel_digital_port
*dig_port)
{
intel_tc_port_suspend(dig_port);
+ kfree(dig_port->tc->port_name);
kfree(dig_port->tc);
dig_port->tc = NULL;
}
Re: [Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()
On Wed, 25 Oct 2023 at 02:01, Christian Brauner wrote:
>
> rcu_read_lock();
> - file = get_file_rcu(>gem.mmap_singleton);
> + file = get_file_rcu_once(>gem.mmap_singleton);
> rcu_read_unlock();
> if (file)
> return file;
Honestly, the get_file_rcu_once() function seems a bit pointless.
The above doesn't want a loop at all. Yet your "once" still does loop,
because "even get_file_rcu_once() is trying to deal with the whole
"the pointer itself changed".
And the i915 code is actually designed to just depend on the atomicity
of the mmap_singleton access itself, in how it uses
cmpxchg(>gem.mmap_singleton, file, NULL);
...
file = READ_ONCE(i915->gem.mmap_singleton);
and literally says "I'll remove my singleton as it is released". The
important part there is that the 'map_singleton' pointer itself isn't
actually reference-counted - it's the reverse, where
reference-counting *other* instances will then auto-clear it.
And that's what then makes that get_file_rcu() model not work with it,
because get_file_rcu() kind of assumes that the argument it gets is
*part* of the reference counting, not a cached *result* of the
reference counting that gets cleared as a result of the ref going down
to zero.
I may explain my objections badly, but hopefully you get what I mean.
And I think that also means that using that new get_file_rcu_once()
may be hiding the actual problem, but it's still conceptually wrong,
because it still has that conceptual model of "the pointer I'm getting
is part of the reference counting", when it really isn't.
So I think we'd actually be better off with something that is more
clearly different from get_file_rcu() in naming, so make that
conceptual difference clearer. Make it be something like
"get_active_file(struct file **)", and make the implementation be just
exactly what your current __get_file_rcu() is with no loops at all.
Then thew i915 code ends up being
rcu_read_lock();
file = get_active_file(>gem.mmap_singleton);
rcu_read_unlock();
if (!IS_ERR_OR_NULL(file))
return file;
.. create new mmap_singleton ..
and that's it.
If you don't want to expose __get_file_rcu() as-is, you could maybe just do
struct file *get_active_file(struct file **fp)
{
struct file *file;
rcu_read_lock();
file = __get_file_rcu(fp);
rcu_read_unlock();
return file;
}
and then the i916 code would just drop the RCU locking that it has no
business even knowing about.
I realize that my complaints are a bit conceptual, and that the
practical end result is pretty much the same, but I do think that it
is worth noting this conceptual difference between "file pointer is
ref-counted" and "file counter is *controlled* by ref-counting".
Add a comment to the effect at get_active_file() users.
The old i915 code is already racy, in that it's called a "singleton",
but if you have multiple concurrent callers to mmap_singleton(), they
all might see a NULL file at first, and then they all create
*separate* new "singleton" files, and they *all* do that
smp_store_mb(i915->gem.mmap_singleton, file);
and one random case of them happens to win the race and set *its* file
as "THE singleton" file.
So your "let's loop if it changes" is not fixing anything as-is, and
it's just actually hiding what is going on.
If the i915 code wants to be consistent and really have just one
singleton, it needs to do the looping with some cmpxchg or whatever
itself. Doing the loop in some get_file_rcu_once() function for when
the file pointer changed isn't going to fix the race.
Am I missing something?
Linus
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier
== Series Details == Series: drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier URL : https://patchwork.freedesktop.org/series/125558/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125558v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125558v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125558v1, please notify your bug team (lgci.bug.fil...@intel.com) 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_125558v1/index.html Participating hosts (38 -> 37) -- Additional (1): bat-adlp-11 Missing(2): fi-snb-2520m fi-bsw-n3050 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125558v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-ivb-3770:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_125558v1 that come from known issues: ### CI changes ### Issues hit * boot: - bat-adlp-11:NOTRUN -> [FAIL][3] ([i915#8293]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-adlp-11/boot.html Possible fixes * boot: - bat-jsl-1: [FAIL][4] ([i915#8293]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-jsl-1: NOTRUN -> [SKIP][6] ([i915#9318]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][7] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][8] ([i915#4613]) +3 other tests skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][9] -> [DMESG-FAIL][10] ([i915#5334]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-jsl-1: NOTRUN -> [SKIP][11] ([i915#4103]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - bat-jsl-1: NOTRUN -> [SKIP][12] ([i915#3555]) +1 other test skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-jsl-1: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125558v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 [i915#9318]: https://gitlab.freedesktop.org/drm/intel/issues/9318 Build changes - * Linux: CI_DRM_13786 -> Patchwork_125558v1 CI-20190529: 20190529 CI_DRM_13786: e8d777a5e7e0ec452142ad0073022733f99c1eb7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7557: 18fc864d68d382847596594d7eb3488f2c8fb45e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_125558v1: e8d777a5e7e0ec452142ad0073022733f99c1eb7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits d940fd43c9f3 drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier == Logs == For more details see:
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Add Wa_14019821291
On Wed, Oct 25, 2023 at 04:06:46PM +0530, Dnyaneshwar Bhadane wrote:
> This workaround is primarily implemented by the BIOS. However if the
> BIOS applies the workaround it will reserve a small piece of our DSM
> (which should be at the top, right below the WOPCM); we just need to
> keep that region reserved so that nothing else attempts to re-use it.
>
> v2: Declare regs in intel_gt_regs.h (Matt Roper)
>
> v3: Shift WA implementation before calculation of *base (Matt Roper)
>
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 17 +
> drivers/gpu/drm/i915/gt/intel_gt_regs.h| 3 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 1a766d8e7cce..192c9a333c0a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -404,6 +404,23 @@ static void icl_get_stolen_reserved(struct
> drm_i915_private *i915,
> MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
> }
>
> + /* Wa_14019821291 */
> + if (MEDIA_VER_FULL(i915) == IP_VER(13, 0)) {
> + /*
> + * This workaround is primarily implemented by the BIOS. We
> + * just need to figure out whether the BIOS has applied the
> + * workaround (meaning the programmed address falls within
> + * the DSM) and, if so, reserve that part of the DSM to
> + * prevent accidental reuse. The DSM location should be just
> + * below the WOPCM.
> + */
> + u64 gscpsmi_base = intel_uncore_read64_2x32(uncore,
> +
> MTL_GSCPSMI_BASEADDR_LSB,
> +
> MTL_GSCPSMI_BASEADDR_MSB);
I overlooked it while reviewing the previous revisions, but I think
we're mixing up which regions size/base refer to. Basically the layout
of the overall DSM stolen memory area is:
[[ usable DSM area ][ GSCPSMI WA area ][ WOPCM ]]
^ ^
| |
DSM baseDSM end
In i915 we have a resource tracking the DSM as a whole, and then also
another resource tracking the "reserved" subregion of the DSM. Your
patch is trying to incorporate the gscpsmi workaround area into the
reserved subregion:
[ usable DSM area ][[ GSCPSMI WA area ][ WOPCM ]]
^^
||
reserved base reserved end
So regarding the first condition here:
> + if (gscpsmi_base >= *base && gscpsmi_base < *base + *size)
I don't think this is checking the right thing. You want to see whether
the gscpsmi base address falls somewhere within within the DSM as a
whole, whereas the base/size you're comparing against above are the
preliminary bounds for the reserved area. Assuming the gscpsmi address
does fall somewhere within the DSM area, then we can pretty much assume
that the BIOS set things up properly and the GSCPSMI workaround area is
immediately before the WOPCM. I.e., the gscpsmi_base should become the
new start of the reserved region.
So what you really want is a condition like:
if (gscpsmi_base >= i915->dsm.stolen.start &&
gscpsmi_base < i915->dsm.stolen.end)
to see if it falls somewhere within the entire DSM area. If it does,
then everything from gscpsmi_base to the end of the DSM can be
considered to be the reserved area, and we don't even need to look at
the value in GEN6_STOLEN_RESERVED to find the WOPCM size.
So maybe the best thing to do is move this condition to the very top of
the function before we do anything else:
if (gscpsmi_base >= i915->dsm.stolen.start &&
gscpsmi_base < i915->dsm.stolen.end) {
*base = gscpsmi_base;
*size = i915->dsm.stolen.end - gscpsmi_base;
return;
}
Then if the GSCPSMI workaround is not in effect we fall back to reading
the WOPCM size from the register and use that to calculate the reserved
region base.
This is a bit different from how things work in my Xe patch because Xe
isn't tracking the reserved region of the DSM, but rather the usable
region, so the logic is somewhat the inverse of what this i915 function
needs.
Matt
> + *size = gscpsmi_base - *base;
> + }
> +
> if (HAS_LMEMBAR_SMEM_STOLEN(i915))
> /* the base is initialized to stolen top so subtract size to
> get base */
> *base -= *size;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index eecd0a87a647..9de41703fae5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: Additional conditions to enable hdcp
== Series Details == Series: drm/i915/hdcp: Additional conditions to enable hdcp URL : https://patchwork.freedesktop.org/series/125550/ State : success == Summary == CI Bug Log - changes from CI_DRM_13786 -> Patchwork_125550v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/index.html Participating hosts (38 -> 37) -- Additional (3): fi-kbl-soraka bat-adlp-11 bat-dg1-5 Missing(4): fi-hsw-4770 fi-tgl-1115g4 fi-snb-2520m fi-pnv-d510 Known issues Here are the changes found in Patchwork_125550v1 that come from known issues: ### CI changes ### Possible fixes * boot: - bat-jsl-1: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-jsl-1/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#9318]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][4] ([i915#9318]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [PASS][5] -> [INCOMPLETE][6] ([i915#9275]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][7] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 other tests skip [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-jsl-1: NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4083]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#4077]) +2 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4079]) +1 other test skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-adlp-11:NOTRUN -> [SKIP][14] ([i915#3282]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#6621]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][16] ([i915#5334] / [i915#7872]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][17] ([i915#1886]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [PASS][18] -> [FAIL][19] ([fdo#103375]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13786/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][20] ([i915#4212]) +7 other tests skip [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125550v1/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][21] ([i915#4215]) [21]:
[Intel-gfx] [PATCH v2] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name),
^~
"%c/TC#%d", port_name(port), tc_port + 1);
~
v2: use kasprintf(Imre)
Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port
struct")
Cc: Mika Kahola
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_tc.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 37b0f8529b4f..0fa54450d51b 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -58,7 +58,7 @@ struct intel_tc_port {
struct delayed_work link_reset_work;
int link_refcount;
bool legacy_port:1;
- char port_name[8];
+ char *port_name;
enum tc_port_mode mode;
enum tc_port_mode init_mode;
enum phy_fia phy_fia;
@@ -1875,8 +1875,10 @@ int intel_tc_port_init(struct intel_digital_port
*dig_port, bool is_legacy)
else
tc->phy_ops = _tc_phy_ops;
- snprintf(tc->port_name, sizeof(tc->port_name),
-"%c/TC#%d", port_name(port), tc_port + 1);
+ tc->port_name = kasprintf(GFP_KERNEL, "%c/TC#%d", port_name(port),
+ tc_port + 1);
+ if (!tc->port_name)
+ return -ENOMEM;
mutex_init(>lock);
/* TODO: Combine the two works */
@@ -1897,6 +1899,7 @@ void intel_tc_port_cleanup(struct intel_digital_port
*dig_port)
{
intel_tc_port_suspend(dig_port);
+ kfree(dig_port->tc->port_name);
kfree(dig_port->tc);
dig_port->tc = NULL;
}
--
2.41.0
Re: [Intel-gfx] [PATCH] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
On 10/25/2023 5:45 PM, Imre Deak wrote:
On Wed, Oct 25, 2023 at 03:57:26PM +0200, Nirmoy Das wrote:
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name),
^~
"%c/TC#%d", port_name(port), tc_port + 1);
~
Fixes: fe03f637b7bd ("drm/i915/tc: Fix -Wformat-truncation in
intel_tc_port_init")
intel_tc_port struct")
Cc: Mika Kahola
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 37b0f8529b4f..0afcee279aff 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -58,7 +58,7 @@ struct intel_tc_port {
struct delayed_work link_reset_work;
int link_refcount;
bool legacy_port:1;
- char port_name[8];
+ char port_name[17];
I'd use instead kasprintf() to suppress the warn.
Imo (at one point) the 'Port %s:', tc->port_name prefix could be
replaced by the usual [ENCODER:%d:%s].
That is even better, thanks I will resend.
Regards,
Nirmoy
enum tc_port_mode mode;
enum tc_port_mode init_mode;
enum phy_fia phy_fia;
--
2.41.0
Re: [Intel-gfx] [PATCH 08/29] drm/dp: Add helpers to calculate the link BW overhead
Hi Imre,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Imre-Deak/drm-dp_mst-Fix-fractional-DSC-bpp-handling/20231024-091920
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20231024010925.3949910-9-imre.deak%40intel.com
patch subject: [Intel-gfx] [PATCH 08/29] drm/dp: Add helpers to calculate the
link BW overhead
config: arm-s5pv210_defconfig
(https://download.01.org/0day-ci/archive/20231025/202310252345.i0qkzguh-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231025/202310252345.i0qkzguh-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202310252345.i0qkzguh-...@intel.com/
All errors (new ones prefixed by >>):
arm-linux-gnueabi-ld: drivers/gpu/drm/display/drm_dp_mst_topology.o: in
function `drm_dp_calc_pbn_mode':
>> drivers/gpu/drm/display/drm_dp_mst_topology.c:4745:(.text+0x12b0): undefined
>> reference to `drm_dp_bw_overhead'
vim +4745 drivers/gpu/drm/display/drm_dp_mst_topology.c
4718
4719 /**
4720 * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
4721 * @clock: dot clock
4722 * @bpp: bpp as .4 binary fixed point
4723 *
4724 * This uses the formula in the spec to calculate the PBN value for a
mode.
4725 */
4726 int drm_dp_calc_pbn_mode(int clock, int bpp)
4727 {
4728 /*
4729 * The unit of 54/64Mbytes/sec is an arbitrary unit chosen
based on
4730 * common multiplier to render an integer PBN for all link
rate/lane
4731 * counts combinations
4732 * calculate
4733 * peak_kbps = clock * bpp / 16
4734 * peak_kbps *= SSC overhead / 100
4735 * peak_kbps /= 8convert to Kbytes
4736 * peak_kBps *= (64/54) / 1000convert to PBN
4737 */
4738 /*
4739 * TODO: Use the actual link and mode parameters to calculate
4740 * the overhead. For now it's assumed that these are
4741 * 4 link lanes, 4096 hactive pixels, which don't add any
4742 * significant data padding overhead and that there is no DSC
4743 * or FEC overhead.
4744 */
> 4745 int overhead = drm_dp_bw_overhead(4, 4096, 0, bpp,
4746DRM_DP_BW_OVERHEAD_MST |
4747DRM_DP_BW_OVERHEAD_SSC);
4748
4749 return DIV64_U64_ROUND_UP(mul_u32_u32(clock * bpp, 64 *
overhead >> 4),
4750100ULL * 8 * 54 * 1000);
4751 }
4752 EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
4753
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [Intel-gfx] [PATCH] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
On Wed, Oct 25, 2023 at 03:57:26PM +0200, Nirmoy Das wrote:
> Fix below compiler warning:
>
> intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
> writing between 1 and 11 bytes into a region of size 3
> [-Werror=format-truncation=]
> "%c/TC#%d", port_name(port), tc_port + 1);
>^~
> intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
> into a destination of size 8
> snprintf(tc->port_name, sizeof(tc->port_name),
> ^~
> "%c/TC#%d", port_name(port), tc_port + 1);
> ~
>
> Fixes: fe03f637b7bd ("drm/i915/tc: Fix -Wformat-truncation in
> intel_tc_port_init")
> intel_tc_port struct")
> Cc: Mika Kahola
> Cc: Imre Deak
> Cc: Jani Nikula
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 37b0f8529b4f..0afcee279aff 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -58,7 +58,7 @@ struct intel_tc_port {
> struct delayed_work link_reset_work;
> int link_refcount;
> bool legacy_port:1;
> - char port_name[8];
> + char port_name[17];
I'd use instead kasprintf() to suppress the warn.
Imo (at one point) the 'Port %s:', tc->port_name prefix could be
replaced by the usual [ENCODER:%d:%s].
> enum tc_port_mode mode;
> enum tc_port_mode init_mode;
> enum phy_fia phy_fia;
> --
> 2.41.0
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915/lnl: Fix check for TC phy
On Mon, Oct 23, 2023 at 12:28:46PM -0300, Gustavo Sousa wrote:
Quoting Lucas De Marchi (2023-10-20 13:04:48-03:00)
On Thu, Oct 19, 2023 at 01:04:40PM -0300, Gustavo Sousa wrote:
Quoting Lucas De Marchi (2023-10-18 19:24:41-03:00)
With MTL adding PICA between the port and the real phy, the path
add for DG2 stopped being followed and newer platforms are simply using
the older path for TC phys. LNL is no different than MTL in this aspect,
so just add it to the mess. In future the phy and port designation and
deciding if it's TC should better be cleaned up.
To make it just a bit better, also change intel_phy_is_snps() to show
this is DG2-only.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 29 ++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 28d85e1e858e..0797ace31417 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1784,31 +1784,32 @@ bool intel_phy_is_combo(struct drm_i915_private
*dev_priv, enum phy phy)
bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
{
+/* DG2's "TC1" output uses a SNPS PHY and is handled separately */
if (IS_DG2(dev_priv))
-/* DG2's "TC1" output uses a SNPS PHY */
return false;
-else if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER_FULL(dev_priv) ==
IP_VER(14, 0))
+
+/*
+ * TODO: This should mostly match intel_port_to_phy(), considering the
+ * ports already encode if they are connected to a TC phy in their
name.
+ */
+if (IS_LUNARLAKE(dev_priv) || IS_METEORLAKE(dev_priv) ||
+IS_ALDERLAKE_P(dev_priv))
Just like already done with the previous patch, I think we should have a
paragraph in the commit message justifying s/DISPLAY_VER_FULL(dev_priv) ==
IP_VER(14, 0)/IS_METEORLAKE(dev_priv)/.
humn... after giving this a second thought, I will take this back.
intel_phy_is_tc() is different than the check in the first patch and
it's actually something dependent on display engine. Here the check is
about is this a DDIA/DDIB or a TC1-TC4? This will change how some
registers in the display engine are programmed:
Hm, yeah. I overlooked that... But we are looking into the PHY
regardless. Is the mapping "phy number -> port type" really associated
to the display engine rather than to the SoC?
we are converting back and forth. The phy number always come from the
port by using intel_port_to_phy(). See intel_ddi_init() for example:
intel_ddi_init()
{
port = intel_bios_encoder_port(devdata);
...
phy = intel_port_to_phy(dev_priv, port);
}
intel_port_to_phy() does use the display engine version and a
platform-based check in a few cases. Looking at the history, this was
added for EHL, where the ports DDI-A and DDI-D are muxed to one PHY,
called PHY-A. Then some registers need to use that number to configure
the registers.
4+ years later I don't see the bspec doing any better job on the
registers that are using the phy vs port and this is derived mostly on a
case by case basis :(
Looking at intel_port_to_phy() and ignoring EHL/JSL as outlier, all the
others are basically answering the question "from the display pov, where
does the native/combo port end and we start the ports connected to "TC
ports". From those, then DG2 starts to be the outlier as it identifies
itself as neither combo nor tc, but rather snps. XeLPD is very
"creative" as we assigned a PORT_D_XELPD = PORT_TC5 to make it work
with the register offsets from the display engine pov they replaced
TC5/TC6. Then the phy_is_tc() also has to workaround that, as those are
not TC phys :-/
I think a better abstraction looking back would be to nuke this
intel_port_to_* / intel_phy_to_* / intel_phy_is_tc. Then we only set
that during ddi init.
Note that this is all different than the is this a C10 or C20 phy
question. The display engine has no idea about that and doesn't care.
Until a few days ago it was not even documented in bspec as this is a
SoC characteristics.
To summarize: I think here we should keep the display engine version
check, resorting to platform checks for the exceptions to match what
intel_port_to_phy() does. Long term we need to better abstract/document
that, but that is for another day.
Lucas De Marchi
--
Gustavo Sousa
$ git grep intel_phy_is_tc -- drivers/gpu/drm/i915/display/intel_ddi.c
drivers/gpu/drm/i915/display/intel_ddi.c: if
(intel_phy_is_tc(dev_priv, phy))
drivers/gpu/drm/i915/display/intel_ddi.c: if (IS_ALDERLAKE_P(i915)
&& intel_phy_is_tc(i915, phy)) {
drivers/gpu/drm/i915/display/intel_ddi.c:
intel_phy_is_tc(i915, phy)))
drivers/gpu/drm/i915/display/intel_ddi.c: if
Re: [Intel-gfx] [PATCH 10/29] drm/i915/dp: Specify the FEC overhead as an increment vs. a remainder
On Wed, Oct 25, 2023 at 06:27:58PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 24, 2023 at 04:09:06AM +0300, Imre Deak wrote:
> > A follow-up patch will add up all the overheads on a DP link, where it
> > makes more sense to specify each overhead factor in terms of the added
> > overhead amount vs. the reciprocal remainder (of usable BW remaining
> > after deducting the overhead). Prepare for that here, keeping the
> > existing behavior.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2048649b420b2..0c0f026fb3161 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -85,8 +85,8 @@
> > #define DP_DSC_MAX_ENC_THROUGHPUT_034
> > #define DP_DSC_MAX_ENC_THROUGHPUT_140
> >
> > -/* DP DSC FEC Overhead factor = 1/(0.972261) */
> > -#define DP_DSC_FEC_OVERHEAD_FACTOR 972261
>
> Does anyone know where this magic number comes from?
>
> AFAICS we should have 250 LL + 5 FEC_PARITY_PH + 1 CD_ADJ, which
> gives us the 256/250 = 2.4% number. In addition there's the
> extra parity marker symbol insterted every 128 FEC blocks,
> which makes the total overhead 2.4015625%, which is still
> not that magic number.
IIRC it's mentioned in the bpsec audio programming sequence, but the
rational for it isn't detailed. I suppose it could be the 2.4% FEC
overhead + a fixed overhead for DSC EOC symbols; but the latter is not
really fixed, it depends on the video mode/slice count etc. as I
commented on later.
>
> > +/* DP DSC FEC Overhead factor = 1/(0.972261) = 1.028530 ppm */
> > +#define DP_DSC_FEC_OVERHEAD_FACTOR 1028530
> >
> > /* Compliance test status bits */
> > #define INTEL_DP_RESOLUTION_SHIFT_MASK 0
> > @@ -680,8 +680,8 @@ int intel_dp_get_link_train_fallback_values(struct
> > intel_dp *intel_dp,
> >
> > u32 intel_dp_mode_to_fec_clock(u32 mode_clock)
> > {
> > - return div_u64(mul_u32_u32(mode_clock, 100U),
> > - DP_DSC_FEC_OVERHEAD_FACTOR);
> > + return div_u64(mul_u32_u32(mode_clock, DP_DSC_FEC_OVERHEAD_FACTOR),
> > + 100U);
> > }
> >
> > static int
> > --
> > 2.39.2
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 10/29] drm/i915/dp: Specify the FEC overhead as an increment vs. a remainder
On Tue, Oct 24, 2023 at 04:09:06AM +0300, Imre Deak wrote:
> A follow-up patch will add up all the overheads on a DP link, where it
> makes more sense to specify each overhead factor in terms of the added
> overhead amount vs. the reciprocal remainder (of usable BW remaining
> after deducting the overhead). Prepare for that here, keeping the
> existing behavior.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2048649b420b2..0c0f026fb3161 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -85,8 +85,8 @@
> #define DP_DSC_MAX_ENC_THROUGHPUT_0 34
> #define DP_DSC_MAX_ENC_THROUGHPUT_1 40
>
> -/* DP DSC FEC Overhead factor = 1/(0.972261) */
> -#define DP_DSC_FEC_OVERHEAD_FACTOR 972261
Does anyone know where this magic number comes from?
AFAICS we should have 250 LL + 5 FEC_PARITY_PH + 1 CD_ADJ, which
gives us the 256/250 = 2.4% number. In addition there's the
extra parity marker symbol insterted every 128 FEC blocks,
which makes the total overhead 2.4015625%, which is still
not that magic number.
> +/* DP DSC FEC Overhead factor = 1/(0.972261) = 1.028530 ppm */
> +#define DP_DSC_FEC_OVERHEAD_FACTOR 1028530
>
> /* Compliance test status bits */
> #define INTEL_DP_RESOLUTION_SHIFT_MASK 0
> @@ -680,8 +680,8 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
>
> u32 intel_dp_mode_to_fec_clock(u32 mode_clock)
> {
> - return div_u64(mul_u32_u32(mode_clock, 100U),
> -DP_DSC_FEC_OVERHEAD_FACTOR);
> + return div_u64(mul_u32_u32(mode_clock, DP_DSC_FEC_OVERHEAD_FACTOR),
> +100U);
> }
>
> static int
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
On 10/25/2023 4:53 PM, Andi Shyti wrote:
Hi Nirmoy,
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return guc_to_gt(guc)->i915;
+}
+
We don't want inline functions in headers files[1]. Otherwise the series
looks fine to me:
the reason for that patch is that we were including the
i915_drv.h just for that inline function and we were doing it
inside the gt/.
In this patch I am not changing any header dependency.
Sounds fair, thanks,
Nirmoy
I guess the original idea from Matt was to have a generic network
of intel_gt_needs_wa_xxx(), but it didn't develop further.
Reviewed-by: Nirmoy Das
Thanks,
Andi
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence
On Wed, Oct 25, 2023 at 05:18:00PM +0300, Ville Syrjälä wrote: > On Fri, Oct 20, 2023 at 12:41:03PM +0300, Jouni Högander wrote: > > We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence > > implementation. Lets drop i915_sw_fence usage from display code and > > use dma_fence interfaces directly. > > > > For this purpose stack dma fences from related objects into new plane > > state. Drm_gem_plane_helper_prepare_fb can be used for fences in new > > fb. Separate local implementation is used for Stacking fences from old fb > > into new plane state. Then wait for these stacked fences during atomic > > commit. There is no be need for separate GPU reset handling in > > intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is > > detected and GPU is being reset. > > > > v2: > > - Add fences from old fb into new_plane_state->uapi.fence rather than > > into old_plane_state->uapi.fence > > > > Cc: Ville Syrjälä > > Cc: Maarten Lankhorst > > Cc: José Roberto de Souza > > > > Signed-off-by: Jouni Högander > > Reviewed-by: Maarten Lankhorst > > --- > > drivers/gpu/drm/i915/display/intel_atomic.c | 3 - > > .../gpu/drm/i915/display/intel_atomic_plane.c | 89 +++ > > drivers/gpu/drm/i915/display/intel_display.c | 78 ++-- > > .../drm/i915/display/intel_display_types.h| 2 - > > 4 files changed, 77 insertions(+), 95 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > > b/drivers/gpu/drm/i915/display/intel_atomic.c > > index 5d18145da279..ec0d5168b503 100644 > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > > @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state > > *_state) > > > > drm_atomic_state_default_release(>base); > > kfree(state->global_objs); > > - > > - i915_sw_fence_fini(>commit_ready); > > - > > kfree(state); > > } > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > index b1074350616c..20fd12df6850 100644 > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > > @@ -31,7 +31,10 @@ > > * prepare/check/commit/cleanup steps. > > */ > > > > +#include > > + > > #include > > +#include > > #include > > #include > > > > @@ -1012,6 +1015,44 @@ int intel_plane_check_src_coordinates(struct > > intel_plane_state *plane_state) > > return 0; > > } > > > > +static int add_fences(struct dma_resv *obj, > > + struct drm_plane_state *dst) > > I would name things differently: > s/obj/resv/ > s/dst/plane_state/ Probably should be "new_plane_state" to make it clear what must be passed in. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
Hi Nirmoy,
> > +static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
> > +{
> > + return guc_to_gt(guc)->i915;
> > +}
> > +
>
> We don't want inline functions in headers files[1]. Otherwise the series
> looks fine to me:
the reason for that patch is that we were including the
i915_drv.h just for that inline function and we were doing it
inside the gt/.
In this patch I am not changing any header dependency.
I guess the original idea from Matt was to have a generic network
of intel_gt_needs_wa_xxx(), but it didn't develop further.
> Reviewed-by: Nirmoy Das
Thanks,
Andi
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
Hi Andi,
On 10/25/2023 4:35 PM, Andi Shyti wrote:
Given a reference to "guc", the guc_to_i915() returns the
pointer to "i915" private data.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
8 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a..12a638f05d63 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -114,6 +114,11 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return guc_to_gt(guc)->i915;
+}
+
We don't want inline functions in headers files[1]. Otherwise the series
looks fine to me:
Reviewed-by: Nirmoy Das
[1] https://patchwork.freedesktop.org/series/124069/
Regards,
Nirmoy
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 3f3df1166b86..2b450c43bbd7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -330,7 +330,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
static u32 guc_ctl_devid(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
return (INTEL_DEVID(i915) << 16) | INTEL_REVID(i915);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a4da0208c883..a1cd40d80517 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -355,7 +355,7 @@ guc_capture_alloc_steered_lists(struct intel_guc *guc,
static const struct __guc_mmio_reg_descr_group *
guc_capture_get_device_reglist(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
const struct __guc_mmio_reg_descr_group *lists;
if (GRAPHICS_VER(i915) >= 12)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 89e314b3756b..4e147de5118f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -265,7 +265,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
u32 *cmds;
int err;
- err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
+ err = i915_inject_probe_error(guc_to_i915(guc), -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 55bc8b55fbc0..bf16351c9349 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -520,7 +520,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
static int guc_log_relay_create(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
size_t n_subbufs, subbuf_size;
int ret;
@@ -573,7 +573,7 @@ static void guc_log_relay_destroy(struct intel_guc_log *log)
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
intel_wakeref_t wakeref;
_guc_log_copy_debuglogs_for_relay(log);
@@ -589,7 +589,7 @@ static void guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
static u32 __get_default_log_level(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
/* A negative value means "use platform/config default" */
if (i915->params.guc_log_level < 0) {
@@ -664,7 +664,7 @@ void intel_guc_log_destroy(struct intel_guc_log *log)
int intel_guc_log_set_level(struct intel_guc_log *log, u32 level)
{
struct intel_guc *guc = log_to_guc(log);
- struct
[Intel-gfx] [PATCH v2 4/5] drm/i915: Use the new gt_to_guc() wrapper
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_debugfs_params.c | 5 +++--
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 614bde321589..8a385c57c0fe 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -38,10 +38,11 @@ static int i915_param_int_open(struct inode *inode, struct
file *file)
static int notify_guc(struct drm_i915_private *i915)
{
+ struct intel_gt *gt = to_gt(i915);
int ret = 0;
- if (intel_uc_uses_guc_submission(_gt(i915)->uc))
- ret = intel_guc_global_policies_update(_gt(i915)->uc.guc);
+ if (intel_uc_uses_guc_submission(>uc))
+ ret = intel_guc_global_policies_update(gt_to_guc(gt));
return ret;
}
diff --git a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
index 2990dd4d4a0d..d9d8f0336702 100644
--- a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
+++ b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
@@ -65,7 +65,7 @@ int intel_selftest_modify_policy(struct intel_engine_cs
*engine,
if (!intel_engine_uses_guc(engine))
return 0;
- err = intel_guc_global_policies_update(>gt->uc.guc);
+ err = intel_guc_global_policies_update(gt_to_guc(engine->gt));
if (err)
intel_selftest_restore_policy(engine, saved);
@@ -84,7 +84,7 @@ int intel_selftest_restore_policy(struct intel_engine_cs
*engine,
if (!intel_engine_uses_guc(engine))
return 0;
- return intel_guc_global_policies_update(>gt->uc.guc);
+ return intel_guc_global_policies_update(gt_to_guc(engine->gt));
}
int intel_selftest_wait_for_rq(struct i915_request *rq)
--
2.42.0
[Intel-gfx] [PATCH v2 5/5] drm/i915/guc: Use the ce_to_guc() wrapper whenever possible
Get the guc reference from the ce using the ce_to_guc() helper.
Just a leftover from previous cleanups.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 023b10ef5be4..8b6396179615 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3511,7 +3511,7 @@ static inline void sub_context_inflight_prio(struct
intel_context *ce,
static inline void update_context_prio(struct intel_context *ce)
{
- struct intel_guc *guc = >engine->gt->uc.guc;
+ struct intel_guc *guc = ce_to_guc(ce);
int i;
BUILD_BUG_ON(GUC_CLIENT_PRIORITY_KMD_HIGH != 0);
--
2.42.0
[Intel-gfx] [PATCH v2 2/5] drm/i915/gt: Create the gt_to_guc() wrapper
We already have guc_to_gt() and getting to guc from the GT it
requires some mental effort. Add the gt_to_guc().
Given the reference to the "gt", the gt_to_guc() will return the
pinter to the "guc".
Update all the files under the gt/ directory.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +++--
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +++---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 8
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
drivers/gpu/drm/i915/gt/intel_tlb.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 +++---
10 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4a11219e560e..ea9c331a38c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -589,7 +589,7 @@ u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs
*engine, u64 value)
* NB: The GuC API only supports 32bit values. However, the limit is
further
* reduced due to internal calculations which would otherwise overflow.
*/
- if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ if (intel_guc_submission_is_wanted(gt_to_guc(engine->gt)))
value = min_t(u64, value, guc_policy_max_preempt_timeout_ms());
value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
@@ -610,7 +610,7 @@ u64 intel_clamp_timeslice_duration_ms(struct
intel_engine_cs *engine, u64 value)
* NB: The GuC API only supports 32bit values. However, the limit is
further
* reduced due to internal calculations which would otherwise overflow.
*/
- if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ if (intel_guc_submission_is_wanted(gt_to_guc(engine->gt)))
value = min_t(u64, value, guc_policy_max_exec_quantum_ms());
value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1c93e84278a0..acd0912a1abd 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -211,11 +211,8 @@ static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
- struct intel_guc *guc = >uc.guc;
-
- intel_guc_invalidate_tlb_guc(guc);
- }
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref)
+ intel_guc_invalidate_tlb_guc(gt_to_guc(gt));
}
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -226,7 +223,7 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
gen8_ggtt_invalidate(ggtt);
list_for_each_entry(gt, >gt_list, ggtt_link) {
- if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+ if (intel_guc_tlb_invalidation_is_available(gt_to_guc(gt))) {
guc_ggtt_ct_invalidate(gt);
} else if (GRAPHICS_VER(i915) >= 12) {
intel_uncore_write_fw(gt->uncore,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 12a638f05d63..228a26017851 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -119,6 +119,11 @@ static inline struct drm_i915_private *guc_to_i915(struct
intel_guc *guc)
return guc_to_gt(guc)->i915;
}
+static inline struct intel_guc *gt_to_guc(struct intel_gt *gt)
+{
+ return >uc.guc;
+}
+
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 77fb57223465..ad4c51f18d3a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -68,9 +68,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
instance,
struct intel_gt *media_gt = gt->i915->media_gt;
if (instance == OTHER_GUC_INSTANCE)
- return guc_irq_handler(>uc.guc, iir);
+ return guc_irq_handler(gt_to_guc(gt), iir);
if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
- return guc_irq_handler(_gt->uc.guc, iir);
+ return guc_irq_handler(gt_to_guc(media_gt), iir);
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
@@ -442,7 +442,7 @@ void gen8_gt_irq_handler(struct intel_gt *gt, u32
master_ctl)
iir
[Intel-gfx] [PATCH v2 3/5] drm/i915/guc: Use the new gt_to_guc() wrapper
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 +--
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 6 ++--
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 28 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 4 +--
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +-
9 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index e2e42b3e0d5d..3b69bc6616bd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -298,7 +298,7 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
memset_io(gsc->local_vaddr + gsc->fw.size, 0, gsc->local->size -
gsc->fw.size);
- intel_guc_write_barrier(>uc.guc);
+ intel_guc_write_barrier(gt_to_guc(gt));
i915_gem_object_unpin_map(gsc->fw.obj);
@@ -351,7 +351,7 @@ static int gsc_fw_query_compatibility_version(struct
intel_gsc_uc *gsc)
void *vaddr;
int err;
- err = intel_guc_allocate_and_map_vma(>uc.guc, GSC_VER_PKT_SZ * 2,
+ err = intel_guc_allocate_and_map_vma(gt_to_guc(gt), GSC_VER_PKT_SZ * 2,
, );
if (err) {
gt_err(gt, "failed to allocate vma for GSC version query\n");
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index 5f138de3c14f..765d74dbb5b5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -356,7 +356,8 @@ static int proxy_channel_alloc(struct intel_gsc_uc *gsc)
void *vaddr;
int err;
- err = intel_guc_allocate_and_map_vma(>uc.guc,
GSC_PROXY_CHANNEL_SIZE,
+ err = intel_guc_allocate_and_map_vma(gt_to_guc(gt),
+GSC_PROXY_CHANNEL_SIZE,
, );
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 63724e17829a..1ef470e64604 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -956,7 +956,7 @@ u32 intel_guc_engine_usage_offset(struct intel_guc *guc)
struct iosys_map intel_guc_engine_usage_record_map(struct intel_engine_cs
*engine)
{
- struct intel_guc *guc = >gt->uc.guc;
+ struct intel_guc *guc = gt_to_guc(engine->gt);
u8 guc_class = engine_class_to_guc_class(engine->class);
size_t offset = offsetof(struct __guc_ads_blob,
engine_usage.engines[guc_class][ilog2(engine->logical_mask)]);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a1cd40d80517..488372b71555 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1441,7 +1441,7 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *ebuf,
if (!cap || !ee->engine)
return -ENODEV;
- guc = >engine->gt->uc.guc;
+ guc = gt_to_guc(ee->engine->gt);
i915_error_printf(ebuf, "global --- GuC Error Capture on %s command
stream:\n",
ee->engine->name);
@@ -1543,7 +1543,7 @@ bool intel_guc_capture_is_matching_engine(struct intel_gt
*gt,
if (!gt || !ce || !engine)
return false;
- guc = >uc.guc;
+ guc = gt_to_guc(gt);
if (!guc->capture)
return false;
@@ -1573,7 +1573,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
if (!gt || !ee || !ce)
return;
- guc = >uc.guc;
+ guc = gt_to_guc(gt);
if (!guc->capture)
return;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index cc9569af7f0c..b67a15f74276 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -111,7 +111,7 @@ static bool has_table(struct drm_i915_private *i915)
static int guc_hwconfig_init(struct intel_gt *gt)
{
struct intel_hwconfig *hwconfig = >info.hwconfig;
- struct intel_guc *guc = >uc.guc;
+ struct intel_guc *guc = gt_to_guc(gt);
int ret;
if (!has_table(gt->i915))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 669f2892bf74..023b10ef5be4 100644
---
[Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
Given a reference to "guc", the guc_to_i915() returns the
pointer to "i915" private data.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
8 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a..12a638f05d63 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -114,6 +114,11 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return guc_to_gt(guc)->i915;
+}
+
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 3f3df1166b86..2b450c43bbd7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -330,7 +330,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
static u32 guc_ctl_devid(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
return (INTEL_DEVID(i915) << 16) | INTEL_REVID(i915);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a4da0208c883..a1cd40d80517 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -355,7 +355,7 @@ guc_capture_alloc_steered_lists(struct intel_guc *guc,
static const struct __guc_mmio_reg_descr_group *
guc_capture_get_device_reglist(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
const struct __guc_mmio_reg_descr_group *lists;
if (GRAPHICS_VER(i915) >= 12)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 89e314b3756b..4e147de5118f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -265,7 +265,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
u32 *cmds;
int err;
- err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
+ err = i915_inject_probe_error(guc_to_i915(guc), -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 55bc8b55fbc0..bf16351c9349 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -520,7 +520,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
static int guc_log_relay_create(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
size_t n_subbufs, subbuf_size;
int ret;
@@ -573,7 +573,7 @@ static void guc_log_relay_destroy(struct intel_guc_log *log)
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
intel_wakeref_t wakeref;
_guc_log_copy_debuglogs_for_relay(log);
@@ -589,7 +589,7 @@ static void guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
static u32 __get_default_log_level(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
/* A negative value means "use platform/config default" */
if (i915->params.guc_log_level < 0) {
@@ -664,7 +664,7 @@ void intel_guc_log_destroy(struct intel_guc_log *log)
int intel_guc_log_set_level(struct intel_guc_log *log, u32 level)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
intel_wakeref_t wakeref;
int ret = 0;
@@ -796,7 +796,7 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
static void guc_log_relay_stop(struct
[Intel-gfx] [PATCH v2 0/5] Add gt_to_guc and guc_to_i915 helpers
Hi, while working on the GuC TLB invalidation these days, I just wished I had the two helpers I am submitting today: gt_to_guc() guc_to_i915() Now I have them, at the next GuC TLB invalidation my life will be easier :-) Andi Changelog: == - add the gt_to_guc() helper and change files in: - i915/gt/ - i915/gt/uc - i915/ Andi Shyti (5): drm/i915/guc: Create the guc_to_i915() wrapper drm/i915/gt: Create the gt_to_guc() wrapper drm/i915/guc: Use the new gt_to_guc() wrapper drm/i915: Use the new gt_to_guc() wrapper drm/i915/guc: Use the ce_to_guc() wrapper whenever possible drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-- drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 ++--- drivers/gpu/drm/i915/gt/intel_gt.h| 10 ++ drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 ++-- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 8 ++--- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-- drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- drivers/gpu/drm/i915/gt/intel_tlb.c | 2 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 ++-- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 +-- drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 8 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 10 +++--- drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 34 +-- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 +-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 4 +-- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +- drivers/gpu/drm/i915/i915_debugfs_params.c| 5 +-- .../i915/selftests/intel_scheduler_helpers.c | 4 +-- 26 files changed, 76 insertions(+), 67 deletions(-) -- 2.42.0
Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
On Mon, Oct 23, 2023 at 02:34:17PM +0100, Daniel Thompson wrote: > On Sun, Oct 22, 2023 at 11:46:22AM +0100, Sean Young wrote: > > On Sat, Oct 21, 2023 at 11:08:22AM +0200, Hans de Goede wrote: > > > On 10/19/23 12:51, Uwe Kleine-König wrote: > > > > On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: > > > >> On 10/17/23 11:17, Sean Young wrote: > > > > I think it's very subjective if you consider this > > > > churn or not. > > > > > > I consider it churn because I don't think adding a postfix > > > for what is the default/expected behavior is a good idea > > > (with GPIOs not sleeping is the expected behavior). > > > > > > I agree that this is very subjective and very much goes > > > into the territory of bikeshedding. So please consider > > > the above my 2 cents on this and lets leave it at that. > > > > You have a valid point. Let's focus on having descriptive function names. > > For a couple of days I've been trying to resist the bikeshedding (esp. > given the changes to backlight are tiny) so I'll try to keep it as > brief as I can: > > 1. I dislike the do_it() and do_it_cansleep() pairing. It is >difficult to detect when a client driver calls do_it() by mistake. >In fact a latent bug of this nature can only be detected by runtime >testing with the small number of PWMs that do not support >configuration from an atomic context. > >In contrast do_it() and do_it_atomic()[*] means that although >incorrectly calling do_it() from an atomic context can be pretty >catastrophic it is also trivially detected (with any PWM driver) >simply by running with CONFIG_DEBUG_ATOMIC_SLEEP. > >No objections (beyond churn) to fully spelt out pairings such as >do_it_cansleep() and do_it_atomic()[*]! I must say I do like the look of this. Uwe, how do you feel about: pwm_apply_cansleep() and pwm_apply_atomic()? I know we've talked about pwm_apply_atomic in the past, however I think this this the best option I've seen so far. > 2. If there is an API rename can we make sure the patch contains no >other changes (e.g. don't introduce any new API in the same patch). >Seperating renames makes the patches easier to review! >It makes each one smaller and easier to review! Yes, this should have been separated out. Will fix for next version. Thanks, Sean
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence
On Fri, Oct 20, 2023 at 12:41:03PM +0300, Jouni Högander wrote:
> We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
> implementation. Lets drop i915_sw_fence usage from display code and
> use dma_fence interfaces directly.
>
> For this purpose stack dma fences from related objects into new plane
> state. Drm_gem_plane_helper_prepare_fb can be used for fences in new
> fb. Separate local implementation is used for Stacking fences from old fb
> into new plane state. Then wait for these stacked fences during atomic
> commit. There is no be need for separate GPU reset handling in
> intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
> detected and GPU is being reset.
>
> v2:
> - Add fences from old fb into new_plane_state->uapi.fence rather than
> into old_plane_state->uapi.fence
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: José Roberto de Souza
>
> Signed-off-by: Jouni Högander
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 3 -
> .../gpu/drm/i915/display/intel_atomic_plane.c | 89 +++
> drivers/gpu/drm/i915/display/intel_display.c | 78 ++--
> .../drm/i915/display/intel_display_types.h| 2 -
> 4 files changed, 77 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 5d18145da279..ec0d5168b503 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -331,9 +331,6 @@ void intel_atomic_state_free(struct drm_atomic_state
> *_state)
>
> drm_atomic_state_default_release(>base);
> kfree(state->global_objs);
> -
> - i915_sw_fence_fini(>commit_ready);
> -
> kfree(state);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index b1074350616c..20fd12df6850 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -31,7 +31,10 @@
> * prepare/check/commit/cleanup steps.
> */
>
> +#include
> +
> #include
> +#include
> #include
> #include
>
> @@ -1012,6 +1015,44 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
> return 0;
> }
>
> +static int add_fences(struct dma_resv *obj,
> + struct drm_plane_state *dst)
I would name things differently:
s/obj/resv/
s/dst/plane_state/
The function name should probably be a bit more
descriptive as well.
> +{
> + struct dma_fence *fence = dma_fence_get(dst->fence);
> + enum dma_resv_usage usage;
> + struct dma_fence *new;
> + int ret;
> +
> + usage = fence ? DMA_RESV_USAGE_KERNEL : DMA_RESV_USAGE_WRITE;
> +
> + ret = dma_resv_get_singleton(obj, usage, );
> + if (ret)
> + goto error;
> +
> + if (new && fence) {
> + struct dma_fence_chain *chain = dma_fence_chain_alloc();
> +
> + if (!chain) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + dma_fence_chain_init(chain, fence, new, 1);
> + fence = >base;
> +
> + } else if (new) {
> + fence = new;
> + }
> +
> + dma_fence_put(dst->fence);
> + dst->fence = fence;
> + return 0;
> +
> +error:
> + dma_fence_put(fence);
> + return ret;
> +}
> +
> /**
> * intel_prepare_plane_fb - Prepare fb for usage on plane
> * @_plane: drm plane to prepare for
> @@ -1035,7 +1076,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> struct intel_atomic_state *state =
> to_intel_atomic_state(new_plane_state->uapi.state);
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct intel_plane_state *old_plane_state =
> + struct intel_plane_state *old_plane_state =
> intel_atomic_get_old_plane_state(state, plane);
> struct drm_i915_gem_object *obj = intel_fb_obj(new_plane_state->hw.fb);
> struct drm_i915_gem_object *old_obj =
> intel_fb_obj(old_plane_state->hw.fb);
> @@ -1057,56 +1098,30 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>* This should only fail upon a hung GPU, in which case we
>* can safely continue.
>*/
> - if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state))
> {
> - ret =
> i915_sw_fence_await_reservation(>commit_ready,
> -
> old_obj->base.resv,
> - false, 0,
> - GFP_KERNEL);
> + if (new_crtc_state && intel_crtc_needs_modeset(new_crtc_state)
> &&
> + !dma_resv_test_signaled(old_obj->base.resv,
> +
[Intel-gfx] [PATCH v5 1/4] drm/i915: Reserve some kernel space per vm
Reserve one page in each vm for kernel space to use for things
such as workarounds.
v2: use real memory, do not decrease vm.total
v4: reserve only one page and explain flag
v5: remove allocated object on ppgtt cleanup
Suggested-by: Chris Wilson
Signed-off-by: Andrzej Hajda
Reviewed-by: Jonathan Cavitt
Reviewed-by: Nirmoy Das
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 42
drivers/gpu/drm/i915/gt/intel_gtt.h | 4
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 9895e18df0435a..90adb4751c4d8a 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -5,6 +5,7 @@
#include
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_lmem.h"
#include "gen8_ppgtt.h"
@@ -222,6 +223,9 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
*vm)
{
struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ if (vm->rsvd.obj)
+ i915_gem_object_put(vm->rsvd.obj);
+
if (intel_vgpu_active(vm->i915))
gen8_ppgtt_notify_vgt(ppgtt, false);
@@ -950,6 +954,40 @@ gen8_alloc_top_pd(struct i915_address_space *vm)
return ERR_PTR(err);
}
+static int gen8_init_rsvd(struct i915_address_space *vm)
+{
+ struct drm_i915_private *i915 = vm->i915;
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int ret;
+
+ /* The memory will be used only by GPU. */
+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE,
+ I915_BO_ALLOC_VOLATILE |
+ I915_BO_ALLOC_GPU_ONLY);
+ if (IS_ERR(obj))
+ obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto unref;
+ }
+
+ ret = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_HIGH);
+ if (ret)
+ goto unref;
+
+ vm->rsvd.vma = i915_vma_make_unshrinkable(vma);
+ vm->rsvd.obj = obj;
+ return 0;
+unref:
+ i915_gem_object_put(obj);
+ return ret;
+}
+
/*
* GEN8 legacy ppgtt programming is accomplished through a max 4 PDP registers
* with a net effect resembling a 2-level page table in normal x86 terms. Each
@@ -1031,6 +1069,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
if (intel_vgpu_active(gt->i915))
gen8_ppgtt_notify_vgt(ppgtt, true);
+ err = gen8_init_rsvd(>vm);
+ if (err)
+ goto err_put;
+
return ppgtt;
err_put:
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index b471edac269920..028a5a988eea02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -249,6 +249,10 @@ struct i915_address_space {
struct work_struct release_work;
struct drm_mm mm;
+ struct {
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ } rsvd;
struct intel_gt *gt;
struct drm_i915_private *i915;
struct device *dma;
--
2.34.1
[Intel-gfx] [PATCH v5 3/4] drm/i915/gt: add selftest to exercise WABB
Test re-uses logic form indirect ctx BB selftest.
Signed-off-by: Nirmoy Das
Signed-off-by: Jonathan Cavitt
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 --
1 file changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 823d38aa393467..e17b8777d21dc9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1555,7 +1555,7 @@ static int live_lrc_isolation(void *arg)
return err;
}
-static int indirect_ctx_submit_req(struct intel_context *ce)
+static int wabb_ctx_submit_req(struct intel_context *ce)
{
struct i915_request *rq;
int err = 0;
@@ -1579,7 +1579,8 @@ static int indirect_ctx_submit_req(struct intel_context
*ce)
#define CTX_BB_CANARY_INDEX (CTX_BB_CANARY_OFFSET / sizeof(u32))
static u32 *
-emit_indirect_ctx_bb_canary(const struct intel_context *ce, u32 *cs)
+emit_wabb_ctx_canary(const struct intel_context *ce,
+u32 *cs, bool per_ctx)
{
*cs++ = MI_STORE_REGISTER_MEM_GEN8 |
MI_SRM_LRM_GLOBAL_GTT |
@@ -1587,26 +1588,43 @@ emit_indirect_ctx_bb_canary(const struct intel_context
*ce, u32 *cs)
*cs++ = i915_mmio_reg_offset(RING_START(0));
*cs++ = i915_ggtt_offset(ce->state) +
context_wa_bb_offset(ce) +
- CTX_BB_CANARY_OFFSET;
+ CTX_BB_CANARY_OFFSET +
+ (per_ctx ? PAGE_SIZE : 0);
*cs++ = 0;
return cs;
}
+static u32 *
+emit_indirect_ctx_bb_canary(const struct intel_context *ce, u32 *cs)
+{
+ return emit_wabb_ctx_canary(ce, cs, false);
+}
+
+static u32 *
+emit_per_ctx_bb_canary(const struct intel_context *ce, u32 *cs)
+{
+ return emit_wabb_ctx_canary(ce, cs, true);
+}
+
static void
-indirect_ctx_bb_setup(struct intel_context *ce)
+wabb_ctx_setup(struct intel_context *ce, bool per_ctx)
{
- u32 *cs = context_wabb(ce, false);
+ u32 *cs = context_wabb(ce, per_ctx);
cs[CTX_BB_CANARY_INDEX] = 0xdeadf00d;
- setup_indirect_ctx_bb(ce, ce->engine, emit_indirect_ctx_bb_canary);
+ if (per_ctx)
+ setup_per_ctx_bb(ce, ce->engine, emit_per_ctx_bb_canary);
+ else
+ setup_indirect_ctx_bb(ce, ce->engine,
emit_indirect_ctx_bb_canary);
}
-static bool check_ring_start(struct intel_context *ce)
+static bool check_ring_start(struct intel_context *ce, bool per_ctx)
{
const u32 * const ctx_bb = (void *)(ce->lrc_reg_state) -
- LRC_STATE_OFFSET + context_wa_bb_offset(ce);
+ LRC_STATE_OFFSET + context_wa_bb_offset(ce) +
+ (per_ctx ? PAGE_SIZE : 0);
if (ctx_bb[CTX_BB_CANARY_INDEX] == ce->lrc_reg_state[CTX_RING_START])
return true;
@@ -1618,21 +1636,21 @@ static bool check_ring_start(struct intel_context *ce)
return false;
}
-static int indirect_ctx_bb_check(struct intel_context *ce)
+static int wabb_ctx_check(struct intel_context *ce, bool per_ctx)
{
int err;
- err = indirect_ctx_submit_req(ce);
+ err = wabb_ctx_submit_req(ce);
if (err)
return err;
- if (!check_ring_start(ce))
+ if (!check_ring_start(ce, per_ctx))
return -EINVAL;
return 0;
}
-static int __live_lrc_indirect_ctx_bb(struct intel_engine_cs *engine)
+static int __lrc_wabb_ctx(struct intel_engine_cs *engine, bool per_ctx)
{
struct intel_context *a, *b;
int err;
@@ -1667,14 +1685,14 @@ static int __live_lrc_indirect_ctx_bb(struct
intel_engine_cs *engine)
* As ring start is restored apriori of starting the indirect ctx bb and
* as it will be different for each context, it fits to this purpose.
*/
- indirect_ctx_bb_setup(a);
- indirect_ctx_bb_setup(b);
+ wabb_ctx_setup(a, per_ctx);
+ wabb_ctx_setup(b, per_ctx);
- err = indirect_ctx_bb_check(a);
+ err = wabb_ctx_check(a, per_ctx);
if (err)
goto unpin_b;
- err = indirect_ctx_bb_check(b);
+ err = wabb_ctx_check(b, per_ctx);
unpin_b:
intel_context_unpin(b);
@@ -1688,7 +1706,7 @@ static int __live_lrc_indirect_ctx_bb(struct
intel_engine_cs *engine)
return err;
}
-static int live_lrc_indirect_ctx_bb(void *arg)
+static int lrc_wabb_ctx(void *arg, bool per_ctx)
{
struct intel_gt *gt = arg;
struct intel_engine_cs *engine;
@@ -1697,7 +1715,7 @@ static int live_lrc_indirect_ctx_bb(void *arg)
for_each_engine(engine, gt, id) {
intel_engine_pm_get(engine);
- err = __live_lrc_indirect_ctx_bb(engine);
+ err = __lrc_wabb_ctx(engine, per_ctx);
intel_engine_pm_put(engine);
if (igt_flush_test(gt->i915))
@@ -1710,6 +1728,16 @@ static int
[Intel-gfx] [PATCH v5 4/4] drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
From: Jonathan Cavitt Set copy engine arbitration into round robin mode for part of Wa_16018031267 / Wa_16018063123 mitigation. Signed-off-by: Nirmoy Das Signed-off-by: Jonathan Cavitt Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h b/drivers/gpu/drm/i915/gt/intel_engine_regs.h index b8618ee3e3041a..c0c8c12edea104 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h @@ -124,6 +124,9 @@ #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) /* gen8+ */ #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ */ #define ECOSKPD(base) _MMIO((base) + 0x1d0) +#define XEHP_BLITTER_SCHEDULING_MODE_MASKREG_GENMASK(12, 11) +#define XEHP_BLITTER_ROUND_ROBIN_MODE\ + REG_FIELD_PREP(XEHP_BLITTER_SCHEDULING_MODE_MASK, 1) #define ECO_CONSTANT_BUFFER_SR_DISABLE REG_BIT(4) #define ECO_GATING_CX_ONLY REG_BIT(3) #define GEN6_BLITTER_FBC_NOTIFY REG_BIT(3) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 192ac0e59afa13..108d9326735910 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2782,6 +2782,11 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) RING_SEMA_WAIT_POLL(engine->mmio_base), 1); } + /* Wa_16018031267, Wa_16018063123 */ + if (NEEDS_FASTCOLOR_BLT_WABB(engine)) + wa_masked_field_set(wal, ECOSKPD(engine->mmio_base), + XEHP_BLITTER_SCHEDULING_MODE_MASK, + XEHP_BLITTER_ROUND_ROBIN_MODE); } static void -- 2.34.1
[Intel-gfx] [PATCH v5 2/4] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
Apply WABB blit for Wa_16018031267 / Wa_16018063123.
v3: drop unused enum definition
v4: move selftest to separate patch, use wa only on BCS0.
v5: fixed selftest caller to context_wabb
Signed-off-by: Nirmoy Das
Signed-off-by: Jonathan Cavitt
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 4 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
4 files changed, 105 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index fdd4ddd3a978a2..b8618ee3e3041a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
#define CCID_EXTENDED_STATE_RESTORE BIT(2)
#define CCID_EXTENDED_STATE_SAVE BIT(3)
#define RING_BB_PER_CTX_PTR(base) _MMIO((base) + 0x1c0) /* gen8+
*/
+#define PER_CTX_BB_FORCE BIT(2)
+#define PER_CTX_BB_VALID BIT(0)
+
#define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4)
/* gen8+ */
#define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+
*/
#define ECOSKPD(base) _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a7b..9ffdb05e231e21 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -82,6 +82,10 @@ struct drm_printer;
##__VA_ARGS__); \
} while (0)
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+ IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+ engine->class == COPY_ENGINE_CLASS && engine->instance == 0)
+
static inline bool gt_is_root(struct intel_gt *gt)
{
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eaf66d90316655..7c367ba8d9dcf1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct
intel_engine_cs *engine)
return 0;
}
+static void
+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+ GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+ regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+ ctx_bb_ggtt_addr |
+ PER_CTX_BB_FORCE |
+ PER_CTX_BB_VALID;
+}
+
static void
lrc_setup_indirect_ctx(u32 *regs,
const struct intel_engine_cs *engine,
@@ -1020,7 +1032,13 @@ static u32 context_wa_bb_offset(const struct
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
}
-static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB. When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
{
void *ptr;
@@ -1029,6 +1047,7 @@ static u32 *context_indirect_bb(const struct
intel_context *ce)
ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+ ptr += per_ctx ? PAGE_SIZE : 0;
return ptr;
}
@@ -1105,7 +1124,8 @@ __lrc_alloc_state(struct intel_context *ce, struct
intel_engine_cs *engine)
if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
- context_size += PAGE_SIZE;
+ /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+ context_size += PAGE_SIZE * 2;
}
if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
@@ -1407,12 +1427,85 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
return gen12_emit_aux_table_inv(ce->engine, cs);
}
+static u32 *xehp_emit_fastcolor_blt_wabb(const struct intel_context *ce, u32
*cs)
+{
+ struct intel_gt *gt = ce->engine->gt;
+ int mocs = gt->mocs.uc_index << 1;
+
+ /**
+* Wa_16018031267 / Wa_16018063123 requires that SW forces the
+* main copy engine arbitration into round robin mode. We
+* additionally need to submit the following WABB blt command
+* to produce 4 subblits with each subblit generating 0 byte
+* write requests as WABB:
+*
+* XY_FASTCOLOR_BLT
+* BG0-> 510E
+* BG1-> 003F (Dest pitch)
+* BG2-> (X1, Y1) = (0, 0)
+* BG3-> 00040001 (X2, Y2) = (1, 4)
+* BG4->
[Intel-gfx] [PATCH v5 0/4] Apply Wa_16018031267 / Wa_16018063123
Hi all, This the series from Jonathan: [PATCH v12 0/4] Apply Wa_16018031267 / Wa_16018063123 taken over by me. Changes in this version are described in the patches, in short: v2: - use real memory as WABB destination, - address CI compains - do not decrease vm.total, - minor reordering. v3: - fixed typos, - removed spare defs, - added tags v4: - removed NULL PTE patch, - separate selftest to separate patch, - use BB only on BCS0 v5: - fixed reserved memory allocation Regards Andrzej Andrzej Hajda (1): drm/i915: Reserve some kernel space per vm Jonathan Cavitt (3): drm/i915: Enable NULL PTE support for vm scratch drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123 .../drm/i915/gem/selftests/i915_gem_context.c | 6 ++ drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 41 +++ drivers/gpu/drm/i915/gt/intel_engine_regs.h | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h| 4 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 + drivers/gpu/drm/i915/gt/intel_gtt.h | 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + drivers/gpu/drm/i915/gt/selftest_lrc.c| 65 drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/intel_device_info.h | 1 + 12 files changed, 215 insertions(+), 21 deletions(-) --- - Link to v3: https://lore.kernel.org/r/20231023-wabb-v3-0-1a4fbc632...@intel.com - Link to v4: https://lore.kernel.org/r/20231023-wabb-v4-0-f75dec962...@intel.com --- Andrzej Hajda (3): drm/i915: Reserve some kernel space per vm drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 drm/i915/gt: add selftest to exercise WABB Jonathan Cavitt (1): drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123 drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 42 drivers/gpu/drm/i915/gt/intel_engine_regs.h | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 4 ++ drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++ drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++- drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 ++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 +- 7 files changed, 205 insertions(+), 21 deletions(-) --- base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe change-id: 20231020-wabb-bbe9324a69a8 Best regards, -- Andrzej Hajda
[Intel-gfx] [PATCH] drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name),
^~
"%c/TC#%d", port_name(port), tc_port + 1);
~
Fixes: fe03f637b7bd ("drm/i915/tc: Fix -Wformat-truncation in
intel_tc_port_init")
intel_tc_port struct")
Cc: Mika Kahola
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 37b0f8529b4f..0afcee279aff 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -58,7 +58,7 @@ struct intel_tc_port {
struct delayed_work link_reset_work;
int link_refcount;
bool legacy_port:1;
- char port_name[8];
+ char port_name[17];
enum tc_port_mode mode;
enum tc_port_mode init_mode;
enum phy_fia phy_fia;
--
2.41.0
Re: [Intel-gfx] Regression on linux-next (next-20231013)
Hello Christian, > -Original Message- > From: Christian Brauner > Sent: Wednesday, October 25, 2023 1:02 PM > To: Borah, Chaitanya Kumar > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar > ; Saarinen, Jani > Subject: Re: Regression on linux-next (next-20231013) > > On Wed, Oct 25, 2023 at 06:32:01AM +, Borah, Chaitanya Kumar wrote: > > Hello Christian, > > > > Hope you are doing well. I am Chaitanya from the linux graphics team in > Intel. > > > > This mail is regarding a regression we are seeing in our CI runs[1] > > on linux-next repository. > > Any chance I can reproduce this locally? Thank you for your response. I see that you have already floated a patch [1] to fix the issue. We will test it and get back to you ASAP. In case, you still need it. If you happen to have a device with intel CPU on it (we are seeing it in machines as old as Gen3[2]), you can follow the below steps. 1. Get the latest drm-tip from https://cgit.freedesktop.org/drm-tip/ and install it on the machine 2. Get IGT suite from https://gitlab.freedesktop.org/drm/igt-gpu-tools 3. Build the test suite You can use the instructions in the README.md file for building the suite. We use ubuntu and I generally do the following a) Make sure the packages listed in Dockerfile.build-debian-minimal and Dockerfile.build-debian are installed. b) meson build && ninja -C build 4. If everything goes fine, there should be a "build" folder created within the base folder of your repository Then run the test using the following command. sudo build/tests/i915_selftest --run-subtest live Regards Chaitanya [1] https://lore.kernel.org/intel-gfx/20231025-formfrage-watscheln-84526cd3bd7d@brauner/ [2] http://gfx-ci.igk.intel.com/tree/linux-next/igt@i915_selftest@l...@mman.html
[Intel-gfx] [PATCH] drm/i915/mtl: Add Wa_22016670082
Implemented workaround for XeLPM+ BSpec: 51762 Signed-off-by: Dnyaneshwar Bhadane --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 192ac0e59afa..6ae7a4de83b0 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1674,6 +1674,9 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) */ wa_write_or(wal, XELPMP_GSC_MOD_CTRL, FORCE_MISS_FTLB); + /* Wa_22016670082 */ + wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE); + debug_dump_steering(gt); } -- 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Apply notify_guc to all GTs
On 25.10.2023 12:28, Nirmoy Das wrote:
Handle platforms with multiple GTs by iterate over all GTs.
Add a Fixes commit so this gets propagated for MTL support.
Fixes: 213c43676beb ("drm/i915/mtl: Remove the 'force_probe' requirement for Meteor
Lake")
Suggested-by: John Harrison
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_debugfs_params.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 614bde321589..8bca02025e09 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -38,10 +38,13 @@ static int i915_param_int_open(struct inode *inode, struct
file *file)
static int notify_guc(struct drm_i915_private *i915)
{
- int ret = 0;
+ struct intel_gt *gt;
+ int i, ret = 0;
- if (intel_uc_uses_guc_submission(_gt(i915)->uc))
- ret = intel_guc_global_policies_update(_gt(i915)->uc.guc);
+ for_each_gt(gt, i915, i) {
+ if (intel_uc_uses_guc_submission(>uc))
+ ret = intel_guc_global_policies_update(>uc.guc);
+ }
Reviewed-by: Andrzej Hajda
Regards
Andrzej
return ret;
}
Re: [Intel-gfx] [PATCH] drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier
On Wed, 2023-10-25 at 12:46 +0300, Mika Kahola wrote:
> Display driver shall read DPCD 00071h[3:1] during configuration
> to get PSR setup time. This register provides the setup time
> requirement on the VSC SDP entry packet. If setup time cannot be
> met with the current timings
> (e.g., PSR setup time + other blanking requirements > blanking time),
> driver should enable sending VSC SDP one frame earlier before sending
> the capture frame.
>
> BSpec: 69895 (PSR Entry Setup Frames 17:16)
>
> Signed-off-by: Mika Kahola
> ---
> .../drm/i915/display/intel_display_types.h | 1 +
> drivers/gpu/drm/i915/display/intel_psr.c | 35 -
> --
> drivers/gpu/drm/i915/display/intel_psr_regs.h | 2 ++
> 3 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 65ea37fe8cff..a0bcab6f2bec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1710,6 +1710,7 @@ struct intel_psr {
> u32 dc3co_exitline;
> u32 dc3co_exit_delay;
> struct delayed_work dc3co_work;
> + u8 entry_setup_frames;
eDP spec is speaking about 1 frame. Our HW seem to have possibility to
have several.
> };
>
> struct intel_dp {
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 4f1f31fc9529..0acb4edae128 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -592,6 +592,9 @@ static void intel_psr_enable_sink(struct intel_dp
> *intel_dp)
> if (intel_dp->psr.req_psr2_sdp_prior_scanline)
> dpcd_val |= DP_PSR_SU_REGION_SCANLINE_CAPTURE;
>
> + if (intel_dp->psr.entry_setup_frames > 0)
> + dpcd_val |= DP_PSR_FRAME_CAPTURE;
> +
> drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
>
> drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> DP_SET_POWER_D0);
> @@ -690,6 +693,9 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
> if (DISPLAY_VER(dev_priv) >= 8)
> val |= EDP_PSR_CRC_ENABLE;
>
> + if (intel_dp->psr.entry_setup_frames > 0)
> + val |= EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp-
> >psr.entry_setup_frames);
> +
> intel_de_rmw(dev_priv, psr_ctl_reg(dev_priv, cpu_transcoder),
> ~EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK, val);
> }
> @@ -731,6 +737,7 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> + u8 frames_before_su_entry;
> u32 val = EDP_PSR2_ENABLE;
>
> val |=
> EDP_PSR2_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
> @@ -741,7 +748,10 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <=
> 12)
> val |= EDP_Y_COORDINATE_ENABLE;
>
> - val |= EDP_PSR2_FRAME_BEFORE_SU(max_t(u8, intel_dp-
> >psr.sink_sync_latency + 1, 2));
> + frames_before_su_entry = max_t(u8,
> + intel_dp-
> >psr.sink_sync_latency + 1,
> + 2);
> + val |= EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry);
I think you want to do this only once. Below or here.
> val |= intel_psr2_get_tp_time(intel_dp);
>
> if (DISPLAY_VER(dev_priv) >= 12) {
> @@ -785,6 +795,14 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> if (intel_dp->psr.req_psr2_sdp_prior_scanline)
> val |= EDP_PSR2_SU_SDP_SCANLINE;
>
> + /* Entry setup frames must be at least 1 less than frames
> before SU entry */
> + if (intel_dp->psr.entry_setup_frames > 0) {
> + val |= EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp-
> >psr.entry_setup_frames);
This is not the correct register. You want to have this in PSR_CTL (not
PSR2_CTL).
> +
> + if (intel_dp->psr.entry_setup_frames >=
> frames_before_su_entry)
> + val |=
> EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry + 1);
> + }
> +
Here you are ORing second time. Please do it only once.
> if (intel_dp->psr.psr2_sel_fetch_enabled) {
> u32 tmp;
>
> @@ -1252,10 +1270,17 @@ void intel_psr_compute_config(struct intel_dp
> *intel_dp,
>
> if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
> adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay
> - 1) {
> - drm_dbg_kms(_priv->drm,
> - "PSR condition failed: PSR setup time (%d
> us) too long\n",
> - psr_setup_time);
> - return;
> + if (DISPLAY_VER(dev_priv) >= 20) {
> +
Re: [Intel-gfx] [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
On Wed, Oct 18, 2023 at 04:24:00PM +0300, Stanislav Lisovskiy wrote:
> For validation purposes, it might be useful to be able to
> force Bigjoiner mode, even if current dotclock/resolution
> do not require that.
> Lets add such to option to debugfs.
>
> v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> debugfs entry is created so lets just check manually
> the DISPLAY_VER.
>
> v3: - Switch to intel_connector from drm_connector(Jani Nikula)
> - Remove redundant modeset lock(Jani Nikula)
> - Use kstrtobool_from_user for boolean value(Jani Nikula)
>
> v4: - Apply the changes to proper function(Jani Nikula)
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> .../drm/i915/display/intel_display_debugfs.c | 66 +++
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
> 3 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index fbe75d47a165..9b810c6f96ea 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1398,6 +1398,30 @@ out:
> drm_modeset_unlock(>mode_config.connection_mutex);
> return ret;
> }
>
> +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> +{
> + struct intel_connector *connector = to_intel_connector(m->private);
> + struct drm_crtc *crtc;
> + struct intel_encoder *encoder = intel_attached_encoder(connector);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + int ret = 0;
> +
> + if (!encoder)
> + return -ENODEV;
> +
> + crtc = connector->base.state->crtc;
> + if (connector->base.status != connector_status_connected || !crtc) {
> + ret = -ENODEV;
Why do we need this extra complication?
> + goto out;
> + }
> +
> + seq_printf(m, "Bigjoiner enable: %d\n",
> intel_dp->force_bigjoiner_enable);
> +
> +out:
> +
> + return ret;
> +}
> +
> static ssize_t i915_dsc_output_format_write(struct file *file,
> const char __user *ubuf,
> size_t len, loff_t *offp)
> @@ -1419,12 +1443,39 @@ static ssize_t i915_dsc_output_format_write(struct
> file *file,
> return len;
> }
>
> +static ssize_t i915_bigjoiner_enable_fops_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct intel_connector *connector = m->private;
> + struct intel_encoder *encoder = intel_attached_encoder(connector);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + bool bigjoiner_en = 0;
> + int ret;
> +
> + ret = kstrtobool_from_user(ubuf, len, _en);
> + if (ret < 0)
> + return ret;
> +
> + intel_dp->force_bigjoiner_enable = bigjoiner_en;
> + *offp += len;
> +
> + return len;
> +}
> +
> static int i915_dsc_output_format_open(struct inode *inode,
> struct file *file)
> {
> return single_open(file, i915_dsc_output_format_show, inode->i_private);
> }
>
> +static int i915_bigjoiner_enable_open(struct inode *inode,
> + struct file *file)
> +{
> + return single_open(file, i915_bigjoiner_enable_show, inode->i_private);
> +}
> +
> static const struct file_operations i915_dsc_output_format_fops = {
> .owner = THIS_MODULE,
> .open = i915_dsc_output_format_open,
> @@ -1434,6 +1485,15 @@ static const struct file_operations
> i915_dsc_output_format_fops = {
> .write = i915_dsc_output_format_write
> };
>
> +static const struct file_operations i915_bigjoiner_enable_fops = {
> + .owner = THIS_MODULE,
> + .open = i915_bigjoiner_enable_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = i915_bigjoiner_enable_fops_write
> +};
> +
> /*
> * Returns the Current CRTC's bpc.
> * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> @@ -1513,6 +1573,12 @@ void intel_connector_debugfs_add(struct
> intel_connector *intel_connector)
> connector, _dsc_output_format_fops);
> }
>
> + if (DISPLAY_VER(dev_priv) >= 11 &&
> + intel_connector->base.connector_type ==
> DRM_MODE_CONNECTOR_DisplayPort) {
eDP missing
> + debugfs_create_file("i915_bigjoiner_force_enable", 0644, root,
> + _connector->base,
> _bigjoiner_enable_fops);
> + }
> +
> if (connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
> connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> connector->connector_type ==
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending
On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote: On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote: On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote: Thanks for taking the time to review this Tvrtko, replies inline below. alan:snip Main concern is that we need to be sure there are no possible ill-effects, like letting the GPU/GuC scribble on some memory we unmapped (or will unmap), having let the suspend continue after timing out, and not perhaps doing the forced wedge like wait_for_suspend() does on the existing timeout path. alan: this will not happen because the held wakeref is never force-released after the timeout - so what happens is the kernel would bail the suspend. How does it know to fail the suspend when there is no error code returned with this timeout? Maybe a stupid question.. my knowledge of suspend-resume paths was not great even before I forgot it all. alan:Tvrtko, you and I both sir. (apologies for the tardy response yet again busy week). So i did trace back the gt->wakeref before i posted these patches and discovered that runtime get/put call, i believe that the first 'get' leads to __intel_wakeref_get_first which calls intel_runtime_pm_get via rpm_get helper and eventually executes a pm_runtime_get_sync(rpm->kdev); (hanging off i915). (ofc, there is a corresponding for '_put_last') - so non-first, non-last increases the counter for the gt... but this last miss will mean kernel knows i915 hasnt 'put' everything. alan:snip Recap: so in both cases (original vs this patch), if we had a buggy gt-wakeref leak, we dont get invalid guc-accesses, but without this patch, we wait forever, and with this patch, we get some messages and eventually bail the suspend. It is not possible to wait for lost G2H in something like intel_uc_suspend() and simply declare "bad things happened" if it times out there, and forcibly clean it all up? (Which would include releasing all the abandoned pm refs, so this patch wouldn't be needed.) alan: I'm not sure if intel_uc_suspend should be held up by gt-level wakeref check unless huc/guc/gsc-uc are the only ones ever taking a gt wakeref. As we already know, what we do know from a uc-perspective: - ensure the outstanding guc related workers is flushed which we didnt before (addressed by patch #1). - any further late H2G-SchedDisable is not leaking wakerefs when calling H2G and not realizing it failed (addressed by patch #2). - (we already), "forcibly clean it all up" at the end of the intel_uc_suspend when we do the guc reset and cleanup all guc-ids. (pre-existing upstream code) - we previously didnt have a coherrent guarantee that "this is the end" i.e. no more new request after intel_uc_suspend. I mean by code logic, we thought we did (thats why intel_uc_suspend ends wth a guc reset), but we now know otherwise. So we that fix by adding the additional rcu_barrier (also part of patch #2). It is not clear to me from the above if that includes cleaning up the outstanding CT replies or no. But anyway.. That said, patch-3 is NOT fixing a bug in guc -its about "if we ever have a future racy gt-wakeref late-leak somewhere - no matter which subsystem took it (guc is not the only subsystem taking gt wakerefs), we at least don't hang forever in this code. Ofc, based on that, even without patch-3 i am confident the issue is resolved anyway. So we could just drop patch-3 is you prefer? .. given this it does sound to me that if you are confident patch 3 isn't fixing anything today that it should be dropped. Regards, Tvrtko
Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Limit max_requested_bpc based on src DSC bpc limits
On Wed, Oct 25, 2023 at 05:43:18PM +0530, Ankit Nautiyal wrote:
> At the moment the max requested bpc is limited to 6 to 10/12.
> For platforms that support DSC, min and max src bpc with DSC are
> different.
>
> Account for DSC bpc limitations, when setting min and max value for
> max_requested_bpc property.
NAK. DSC capabiliies change dynamically, the property does not.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index abc718f1a878..1935b9014b12 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5907,8 +5907,17 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> intel_attach_broadcast_rgb_property(connector);
> if (HAS_GMCH(dev_priv))
> drm_connector_attach_max_bpc_property(connector, 6, 10);
> - else if (DISPLAY_VER(dev_priv) >= 5)
> - drm_connector_attach_max_bpc_property(connector, 6, 12);
> + else if (DISPLAY_VER(dev_priv) >= 5) {
> + int min_bpc = 6, max_bpc = 12;
> + struct intel_connector *intel_connector =
> to_intel_connector(connector);
> +
> + if (HAS_DSC(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
> + min_bpc = intel_dp_dsc_min_src_input_bpc(dev_priv);
> + max_bpc = intel_dp_dsc_max_src_input_bpc(dev_priv);
> + }
> +
> + drm_connector_attach_max_bpc_property(connector, min_bpc,
> max_bpc);
> + }
>
> /* Register HDMI colorspace for case of lspcon */
> if
> (intel_bios_encoder_is_lspcon(dp_to_dig_port(intel_dp)->base.devdata)) {
> --
> 2.40.1
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH 4/4] drm/i915/dp: Limit max_requested_bpc based on src DSC bpc limits
At the moment the max requested bpc is limited to 6 to 10/12.
For platforms that support DSC, min and max src bpc with DSC are
different.
Account for DSC bpc limitations, when setting min and max value for
max_requested_bpc property.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index abc718f1a878..1935b9014b12 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5907,8 +5907,17 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_broadcast_rgb_property(connector);
if (HAS_GMCH(dev_priv))
drm_connector_attach_max_bpc_property(connector, 6, 10);
- else if (DISPLAY_VER(dev_priv) >= 5)
- drm_connector_attach_max_bpc_property(connector, 6, 12);
+ else if (DISPLAY_VER(dev_priv) >= 5) {
+ int min_bpc = 6, max_bpc = 12;
+ struct intel_connector *intel_connector =
to_intel_connector(connector);
+
+ if (HAS_DSC(dev_priv) &&
drm_dp_sink_supports_dsc(intel_connector->dp.dsc_dpcd)) {
+ min_bpc = intel_dp_dsc_min_src_input_bpc(dev_priv);
+ max_bpc = intel_dp_dsc_max_src_input_bpc(dev_priv);
+ }
+
+ drm_connector_attach_max_bpc_property(connector, min_bpc,
max_bpc);
+ }
/* Register HDMI colorspace for case of lspcon */
if
(intel_bios_encoder_is_lspcon(dp_to_dig_port(intel_dp)->base.devdata)) {
--
2.40.1
[Intel-gfx] [PATCH 3/4] drm/i915/dp_mst: Use helpers to get dsc min/max input bpc
Use helpers for source min/max input bpc with DSC.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 --
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 ---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5adab761f2e8..abc718f1a878 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1566,7 +1566,6 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
return -EINVAL;
}
-static
u8 intel_dp_dsc_max_src_input_bpc(struct drm_i915_private *i915)
{
if (!HAS_DSC(i915))
@@ -1946,7 +1945,6 @@ static int dsc_compute_compressed_bpp(struct intel_dp
*intel_dp,
dsc_max_bpp, dsc_min_bpp, pipe_bpp,
timeslots);
}
-static
u8 intel_dp_dsc_min_src_input_bpc(struct drm_i915_private *i915)
{
/* Min DSC Input BPC for ICL+ is 8 */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 484aea215a25..53e88c00900c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -164,5 +164,7 @@ intel_dp_compute_config_link_bpp_limits(struct intel_dp
*intel_dp,
struct link_config_limits *limits);
void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_connector *connector);
+u8 intel_dp_dsc_max_src_input_bpc(struct drm_i915_private *i915);
+u8 intel_dp_dsc_min_src_input_bpc(struct drm_i915_private *i915);
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 7b4628f4f124..d32e5258e1ec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -194,18 +194,15 @@ static int intel_dp_dsc_mst_compute_link_config(struct
intel_encoder *encoder,
int i, num_bpc;
u8 dsc_bpc[3] = {};
int min_bpp, max_bpp, sink_min_bpp, sink_max_bpp;
- u8 dsc_max_bpc;
+ u8 dsc_max_bpc, dsc_min_bpc;
bool need_timeslot_recalc = false;
u32 last_compressed_bpp;
- /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
- if (DISPLAY_VER(i915) >= 12)
- dsc_max_bpc = min_t(u8, 12, conn_state->max_requested_bpc);
- else
- dsc_max_bpc = min_t(u8, 10, conn_state->max_requested_bpc);
+ dsc_max_bpc = intel_dp_dsc_max_src_input_bpc(i915);
+ dsc_min_bpc = intel_dp_dsc_min_src_input_bpc(i915);
max_bpp = min_t(u8, dsc_max_bpc * 3, limits->pipe.max_bpp);
- min_bpp = limits->pipe.min_bpp;
+ min_bpp = max_t(u8, dsc_min_bpc * 3, limits->pipe.min_bpp);
num_bpc = drm_dp_dsc_sink_supported_input_bpcs(connector->dp.dsc_dpcd,
dsc_bpc);
--
2.40.1
[Intel-gfx] [PATCH 2/4] drm/i915/dp: Fix the max DSC bpc supported by source
Use correct helper for getting max DSC bpc supported by the source.
Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best
compressed bpp")
Cc: Ankit Nautiyal
Cc: Stanislav Lisovskiy
Cc: Jani Nikula
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d9e1d15a386e..5adab761f2e8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2022,7 +2022,7 @@ static int intel_dp_dsc_compute_pipe_bpp(struct intel_dp
*intel_dp,
}
}
- dsc_max_bpc = intel_dp_dsc_min_src_input_bpc(i915);
+ dsc_max_bpc = intel_dp_dsc_max_src_input_bpc(i915);
if (!dsc_max_bpc)
return -EINVAL;
--
2.40.1
[Intel-gfx] [PATCH 1/4] drm/i915/dp: Simplify checks for helper intel_dp_dsc_max_src_input_bpc
Return 0 if platform doesn't support DSC, and return 12 for Display ver
12+.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1891c0cc187d..d9e1d15a386e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1569,13 +1569,14 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
static
u8 intel_dp_dsc_max_src_input_bpc(struct drm_i915_private *i915)
{
+ if (!HAS_DSC(i915))
+ return 0;
+
/* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
- if (DISPLAY_VER(i915) >= 12)
- return 12;
if (DISPLAY_VER(i915) == 11)
return 10;
- return 0;
+ return 12;
}
int intel_dp_dsc_compute_max_bpp(const struct intel_connector *connector,
--
2.40.1
[Intel-gfx] [PATCH 0/4] DP DSC min/max src bpc fixes
Use helpers for source min/max src bpc appropriately for dp mst case and to limit max_requested_bpc property min/max values. Ankit Nautiyal (4): drm/i915/dp: Simplify checks for helper intel_dp_dsc_max_src_input_bpc drm/i915/dp: Fix the max DSC bpc supported by source drm/i915/dp_mst: Use helpers to get dsc min/max input bpc drm/i915/dp: Limit max_requested_bpc based on src DSC bpc limits drivers/gpu/drm/i915/display/intel_dp.c | 24 ++--- drivers/gpu/drm/i915/display/intel_dp.h | 2 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 -- 3 files changed, 22 insertions(+), 15 deletions(-) -- 2.40.1
Re: [Intel-gfx] [PATCH] drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier
On Wed, Oct 25, 2023 at 12:46:00PM +0300, Mika Kahola wrote:
> Display driver shall read DPCD 00071h[3:1] during configuration
> to get PSR setup time. This register provides the setup time
> requirement on the VSC SDP entry packet. If setup time cannot be
> met with the current timings
> (e.g., PSR setup time + other blanking requirements > blanking time),
> driver should enable sending VSC SDP one frame earlier before sending
> the capture frame.
>
> BSpec: 69895 (PSR Entry Setup Frames 17:16)
>
> Signed-off-by: Mika Kahola
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_psr.c | 35 ---
> drivers/gpu/drm/i915/display/intel_psr_regs.h | 2 ++
> 3 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 65ea37fe8cff..a0bcab6f2bec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1710,6 +1710,7 @@ struct intel_psr {
> u32 dc3co_exitline;
> u32 dc3co_exit_delay;
> struct delayed_work dc3co_work;
> + u8 entry_setup_frames;
> };
>
> struct intel_dp {
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 4f1f31fc9529..0acb4edae128 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -592,6 +592,9 @@ static void intel_psr_enable_sink(struct intel_dp
> *intel_dp)
> if (intel_dp->psr.req_psr2_sdp_prior_scanline)
> dpcd_val |= DP_PSR_SU_REGION_SCANLINE_CAPTURE;
>
> + if (intel_dp->psr.entry_setup_frames > 0)
> + dpcd_val |= DP_PSR_FRAME_CAPTURE;
> +
> drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
>
> drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
> @@ -690,6 +693,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
> if (DISPLAY_VER(dev_priv) >= 8)
> val |= EDP_PSR_CRC_ENABLE;
>
> + if (intel_dp->psr.entry_setup_frames > 0)
> + val |=
> EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp->psr.entry_setup_frames);
> +
> intel_de_rmw(dev_priv, psr_ctl_reg(dev_priv, cpu_transcoder),
>~EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK, val);
> }
> @@ -731,6 +737,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> + u8 frames_before_su_entry;
> u32 val = EDP_PSR2_ENABLE;
>
> val |= EDP_PSR2_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
> @@ -741,7 +748,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
> val |= EDP_Y_COORDINATE_ENABLE;
>
> - val |= EDP_PSR2_FRAME_BEFORE_SU(max_t(u8,
> intel_dp->psr.sink_sync_latency + 1, 2));
> + frames_before_su_entry = max_t(u8,
> +intel_dp->psr.sink_sync_latency + 1,
> +2);
I would put that (and the setup_frames +1) into its own function.
> + val |= EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry);
> val |= intel_psr2_get_tp_time(intel_dp);
>
> if (DISPLAY_VER(dev_priv) >= 12) {
> @@ -785,6 +795,14 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> if (intel_dp->psr.req_psr2_sdp_prior_scanline)
> val |= EDP_PSR2_SU_SDP_SCANLINE;
>
> + /* Entry setup frames must be at least 1 less than frames before SU
> entry */
> + if (intel_dp->psr.entry_setup_frames > 0) {
> + val |=
> EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp->psr.entry_setup_frames);
You're writitng that into the wrong registers.
> +
> + if (intel_dp->psr.entry_setup_frames >= frames_before_su_entry)
> + val |= EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry
> + 1);
> + }
> +
> if (intel_dp->psr.psr2_sel_fetch_enabled) {
> u32 tmp;
>
> @@ -1252,10 +1270,17 @@ void intel_psr_compute_config(struct intel_dp
> *intel_dp,
>
> if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
> adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay - 1) {
> - drm_dbg_kms(_priv->drm,
> - "PSR condition failed: PSR setup time (%d us) too
> long\n",
> - psr_setup_time);
> - return;
> + if (DISPLAY_VER(dev_priv) >= 20) {
> + intel_dp->psr.entry_setup_frames = 1;
I don't see where you're clearing this to 0.
I would extract the whole setup_time -> setup_frames conversion into
its own function and just do a setup_frames vs. platform check here.
> + drm_dbg_kms(_priv->drm,
> +
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/display: debugfs entry to list display capabilities
On Thu, 19 Oct 2023, "Borah, Chaitanya Kumar"
wrote:
>> -Original Message-
>> From: Govindapillai, Vinod
>> Sent: Wednesday, October 18, 2023 3:57 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Govindapillai, Vinod ; Sharma, Swati2
>> ; Borah, Chaitanya Kumar
>>
>> Subject: [PATCH v4 1/2] drm/i915/display: debugfs entry to list display
>> capabilities
>>
>> Create a separate debugfs entry to list the display capabilities IGT can
>> rely on
>> this debugfs entry for tests that depend on display device and display
>> runtime
>> info for both xe and i915 drivers.
>>
>> v2: rename the entry to i915_display_capabilities (Chaitanya)
>>
>> Signed-off-by: Vinod Govindapillai
>
> Assuming that it has no other impact in user-space. The change looks LGTM.
>
> Reviewed-by: Chaitanya Kumar Borah
Thanks for the patches and review, pushed the first patch.
Please get the igt change merged before pushing the second patch.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> index fbe75d47a165..b0248dfa8dea 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> @@ -641,6 +641,17 @@ static int i915_display_info(struct seq_file *m, void
>> *unused)
>> return 0;
>> }
>>
>> +static int i915_display_capabilities(struct seq_file *m, void *unused)
>> +{
>> +struct drm_i915_private *i915 = node_to_i915(m->private);
>> +struct drm_printer p = drm_seq_file_printer(m);
>> +
>> +intel_display_device_info_print(DISPLAY_INFO(i915),
>> +DISPLAY_RUNTIME_INFO(i915), );
>> +
>> +return 0;
>> +}
>> +
>> static int i915_shared_dplls_info(struct seq_file *m, void *unused) {
>> struct drm_i915_private *dev_priv = node_to_i915(m->private); @@
>> -1059,6 +1070,7 @@ static const struct drm_info_list
>> intel_display_debugfs_list[] = {
>> {"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
>> {"i915_power_domain_info", i915_power_domain_info, 0},
>> {"i915_display_info", i915_display_info, 0},
>> +{"i915_display_capabilities", i915_display_capabilities, 0},
>> {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
>> {"i915_dp_mst_info", i915_dp_mst_info, 0},
>> {"i915_ddb_info", i915_ddb_info, 0},
>> --
>> 2.34.1
>
--
Jani Nikula, Intel
[Intel-gfx] [PATCH] file, i915: fix file reference for mmap_singleton()
Today we got a report at [1] for rcu stalls on the i915 testsuite in [2]
due to the conversion of files to SLAB_TYPSSAFE_BY_RCU. Afaict,
get_file_rcu() goes into an infinite loop trying to carefully verify
that i915->gem.mmap_singleton hasn't changed - see the splat below.
So I stared at this code to figure out what it actually does. It seems
that the i915->gem.mmap_singleton pointer itself never had rcu semantics.
The i915->gem.mmap_singleton is replaced in
file->f_op->release::singleton_release():
static int singleton_release(struct inode *inode, struct file *file)
{
struct drm_i915_private *i915 = file->private_data;
cmpxchg(>gem.mmap_singleton, file, NULL);
drm_dev_put(>drm);
return 0;
}
The cmpxchg() is ordered against a concurrent update of
i915->gem.mmap_singleton from mmap_singleton(). IOW, when
mmap_singleton() fails to get a reference on i915->gem.mmap_singleton
via mmap_singleton():
rcu_read_lock();
file = get_file_rcu(>gem.mmap_singleton);
rcu_read_unlock();
mmap_singleton() allocates a new file via anon_inode_getfile() and does
smp_store_mb(i915->gem.mmap_singleton, file);
So, afaiu, then what happens in the case of this bug is that at some
point fput() is called and drops the file->f_count to zero but obviously
leaving the pointer in i915->gem.mmap_singleton in tact until
file->f_op->release::singleton_release() is called.
Now, there might be possibly larger delays until
file->f_op->release::singleton_release() is called and
i915->gem.mmap_singleton is set to NULL?
Say concurrently another task hits mmap_singleton() and does:
rcu_read_lock();
file = get_file_rcu(>gem.mmap_singleton);
rcu_read_unlock();
When get_file_rcu() fails to get a reference via atomic_inc_not_zero()
it will try the reload from i915->gem.mmap_singleton assuming it has
comparable semantics as __fget_files_rcu() that also reloads on
atomic_inc_not_zero() failure.
But since i915->gem.mmap_singleton doesn't have proper rcu semantics it
reloads the same pointer again, trying the same atomic_inc_not_zero()
again and doing so until file->f_op->release::singleton_release() of the
old file has been called.
So, in contrast to __fget_files_rcu() here we want to not retry when
atomic_inc_not_zero() has failed. We only want to retry in case we
managed to get a reference but the pointer did change on reload.
<3> [511.395679] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
<3> [511.395716] rcu: Tasks blocked on level-1 rcu_node (CPUs 0-9): P6238
<3> [511.395934] rcu: (detected by 16, t=65002 jiffies, g=123977, q=439
ncpus=20)
<6> [511.395944] task:i915_selftest state:R running task stack:10568
pid:6238 tgid:6238 ppid:1001 flags:0x4002
<6> [511.395962] Call Trace:
<6> [511.395966]
<6> [511.395974] ? __schedule+0x3a8/0xd70
<6> [511.395995] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
<6> [511.396003] ? lockdep_hardirqs_on+0xc3/0x140
<6> [511.396013] ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
<6> [511.396029] ? get_file_rcu+0x10/0x30
<6> [511.396039] ? get_file_rcu+0x10/0x30
<6> [511.396046] ? i915_gem_object_mmap+0xbc/0x450 [i915]
<6> [511.396509] ? i915_gem_mmap+0x272/0x480 [i915]
<6> [511.396903] ? mmap_region+0x253/0xb60
<6> [511.396925] ? do_mmap+0x334/0x5c0
<6> [511.396939] ? vm_mmap_pgoff+0x9f/0x1c0
<6> [511.396949] ? rcu_is_watching+0x11/0x50
<6> [511.396962] ? igt_mmap_offset+0xfc/0x110 [i915]
<6> [511.397376] ? __igt_mmap+0xb3/0x570 [i915]
<6> [511.397762] ? igt_mmap+0x11e/0x150 [i915]
<6> [511.398139] ? __trace_bprintk+0x76/0x90
<6> [511.398156] ? __i915_subtests+0xbf/0x240 [i915]
<6> [511.398586] ? __pfx___i915_live_setup+0x10/0x10 [i915]
<6> [511.399001] ? __pfx___i915_live_teardown+0x10/0x10 [i915]
<6> [511.399433] ? __run_selftests+0xbc/0x1a0 [i915]
<6> [511.399875] ? i915_live_selftests+0x4b/0x90 [i915]
<6> [511.400308] ? i915_pci_probe+0x106/0x200 [i915]
<6> [511.400692] ? pci_device_probe+0x95/0x120
<6> [511.400704] ? really_probe+0x164/0x3c0
<6> [511.400715] ? __pfx___driver_attach+0x10/0x10
<6> [511.400722] ? __driver_probe_device+0x73/0x160
<6> [511.400731] ? driver_probe_device+0x19/0xa0
<6> [511.400741] ? __driver_attach+0xb6/0x180
<6> [511.400749] ? __pfx___driver_attach+0x10/0x10
<6> [511.400756] ? bus_for_each_dev+0x77/0xd0
<6> [511.400770] ? bus_add_driver+0x114/0x210
<6> [511.400781] ? driver_register+0x5b/0x110
<6> [511.400791] ? i915_init+0x23/0xc0 [i915]
<6> [511.401153] ? __pfx_i915_init+0x10/0x10 [i915]
<6> [511.401503] ? do_one_initcall+0x57/0x270
<6> [511.401515] ? rcu_is_watching+0x11/0x50
<6> [511.401521] ? kmalloc_trace+0xa3/0xb0
<6> [511.401532] ? do_init_module+0x5f/0x210
<6> [511.401544] ? load_module+0x1d00/0x1f60
<6> [511.401581] ? init_module_from_file+0x86/0xd0
<6> [511.401590] ? init_module_from_file+0x86/0xd0
<6> [511.401613] ? idempotent_init_module+0x17c/0x230
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check if pmu is closed before stopping event
Hi Umesh,
On Fri, Oct 20, 2023 at 08:24:41AM -0700, Umesh Nerlige Ramappa wrote:
> When the driver unbinds, pmu is unregistered and i915->uabi_engines is
> set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine
> events, it issues a warn_on because engine lookup fails.
>
> All perf hooks are taking care of this using a pmu->closed flag that is
> set when PMU unregisters. The stop event seems to have been left out.
>
> Check for pmu->closed in pmu_event_stop as well.
>
> Based on discussion here -
> https://patchwork.freedesktop.org/patch/492079/?series=105790=2
>
> v2: s/is/if/ in commit title
> v3: Add fixes tag and cc stable
>
> Cc: # v5.11+
> Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
> Signed-off-by: Umesh Nerlige Ramappa
> Reviewed-by: Tvrtko Ursulin
the failure from the shards tests looks unrelated.
Please next time don't forget to add a versioning to the patches
you are sending.
Pushed in drm-intel-gt-next.
Thank you,
Andi
Re: [Intel-gfx] [PATCH] drm/i915/mtl: avoid stringop-overflow warning
On Tue, 24 Oct 2023, Andi Shyti wrote:
> Hi Jani,
>
>> > static void rc6_res_reg_init(struct intel_rc6 *rc6)
>> > {
>> > - memset(rc6->res_reg, INVALID_MMIO_REG.reg, sizeof(rc6->res_reg));
>>
>> That's just bollocks. memset() is byte granularity, while
>> INVALID_MMIO_REG.reg is u32. If the value was anything other than 0,
>> this would break.
>
> Actually it's:
>
>void *memset(void *s, int c, size_t count)
And? It still sets each byte in s to (the lowest 8 bits of) c.
>
>> And you're not supposed to look at the guts of i915_reg_t to begin with,
>> that's why it's a typedef. Basically any code that accesses the members
>> of i915_reg_t outside of its implementation are doing it wrong.
>>
>> Reviewed-by: Jani Nikula
>
> in any case, I agree with your argument, but why can't we simply
> do:
>
>memset(rc6->res_reg, 0, sizeof(rc6->res_reg));
>
> ?
We can simply do a lot of things in C, but IMO that's semantically
wrong. i915_reg_t is supposed to be an opaque type. We're not supposed
to know what it contains, and what values are valid or invalid for it.
That's one of the reasons we have i915_reg_t in the first place (type
safety being the primary one).
Basically you should be able to do
-#define INVALID_MMIO_REG _MMIO(0)
+#define INVALID_MMIO_REG _MMIO(0xdeadbeef)
and expect everything to still work.
BR,
Jani.
>
> The patch looks to me like it's being more complex that it
> should.
>
> Andi
--
Jani Nikula, Intel
Re: [Intel-gfx] [topic/core-for-CI][PATCH 0/2] Drop some unnecessary patches
On Tue, 24 Oct 2023, Ville Syrjala wrote: > From: Ville Syrjälä > > Try to drop a few seemingly unnecessary patches from core-for-CI. Yay, ack! > > Ville Syrjälä (2): > Revert "freezer: Dump more info on whoever is trying to get frozen > with locks held" > Revert "iommu: Remove iova cpu hotplugging flushing" > > drivers/iommu/iova.c | 28 > include/linux/cpuhotplug.h | 1 + > include/linux/iova.h | 1 + > kernel/freezer.c | 12 ++-- > 4 files changed, 32 insertions(+), 10 deletions(-) -- Jani Nikula, Intel
Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Implement fbdev emulation as in-kernel client
Hi Thomas, couple of minor comments and a question below.
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Replace all code that initializes or releases fbdev emulation
> throughout the driver. Instead initialize the fbdev client by a
> single call to i915_fbdev_setup() after i915 has registered its
intel_fbdev_setup
> DRM device. Just like similar code in other drivers, i915 fbdev
> emulation now acts as a regular DRM client.
>
> The fbdev client setup consists of the initial preparation and the
> hot-plugging of the display. The latter creates the fbdev device
> and sets up the fbdev framebuffer. The setup performs display
> hot-plugging once. If no display can be detected, DRM probe helpers
> re-run the detection on each hotplug event.
>
> A call to drm_dev_unregister() releases the client automatically.
> No further action is required within i915. If the fbdev framebuffer
> has been fully set up, struct fb_ops.fb_destroy implements the
> release. For partially initialized emulation, the fbdev client
> reverts the initial setup.
>
> v3:
> * as before, silently ignore devices without displays
> v2:
> * let drm_client_register() handle initial hotplug
> * fix driver name in error message (Jani)
> * fix non-fbdev build (kernel test robot)
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> .../drm/i915/display/intel_display_driver.c | 18 --
> drivers/gpu/drm/i915/display/intel_fbdev.c | 180
> --
> drivers/gpu/drm/i915/display/intel_fbdev.h | 20 +-
> drivers/gpu/drm/i915/i915_driver.c | 2 +
> 5 files changed, 83 insertions(+), 138 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index edbcf5968804d..7efa8d2787c39 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -81,7 +81,6 @@
> #include "intel_dvo.h"
> #include "intel_fb.h"
> #include "intel_fbc.h"
> -#include "intel_fbdev.h"
> #include "intel_fdi.h"
> #include "intel_fifo_underrun.h"
> #include "intel_frontbuffer.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index ffdcddd1943e0..213a4ee93ffc2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -364,10 +364,6 @@ int intel_display_driver_probe(struct
> drm_i915_private *i915)
>
> intel_overlay_setup(i915);
>
> - ret = intel_fbdev_init(>drm);
> - if (ret)
> - return ret;
> -
> /* Only enable hotplug handling once the fbdev is fully set
> up. */
> intel_hpd_init(i915);
> intel_hpd_poll_disable(i915);
> @@ -392,16 +388,6 @@ void intel_display_driver_register(struct
> drm_i915_private *i915)
>
> intel_display_debugfs_register(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(i915);
> -
> /*
> * We need to coordinate the hotplugs with the asynchronous
> * fbdev configuration, for which we use the
> @@ -445,9 +431,6 @@ void intel_display_driver_remove_noirq(struct
> drm_i915_private *i915)
> */
> intel_hpd_poll_fini(i915);
>
> - /* poll work can call into fbdev, hence clean that up
> afterwards */
> - intel_fbdev_fini(i915);
> -
> intel_unregister_dsm_handler();
>
> /* flush any delayed tasks or pending work */
> @@ -484,7 +467,6 @@ void intel_display_driver_unregister(struct
> drm_i915_private *i915)
> if (!HAS_DISPLAY(i915))
> return;
>
> - intel_fbdev_unregister(i915);
> intel_audio_deinit(i915);
>
> /*
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 39de61d4e7906..100a4aaf1b7e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -24,7 +24,6 @@
> * David Airlie
> */
>
> -#include
> #include
> #include
> #include
> @@ -39,6 +38,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -58,7 +58,6 @@ struct intel_fbdev {
> struct intel_framebuffer *fb;
> struct i915_vma *vma;
> unsigned long vma_flags;
> - async_cookie_t cookie;
> int preferred_bpp;
>
> /* Whether or not fbdev hpd processing is temporarily
> suspended */
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Additional conditions to enable hdcp
On Wed, 25 Oct 2023, Suraj Kandpal wrote:
> When we dock a monitor we end up with a enable and disable connector
> cycle but if hdcp content is running we get the userspace in
> enabled state and driver maintaing a undesired state which causes
> the content to stop playing and we only enabe hdcp if the userspace
> state in desired. This patch fixes that.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c| 14 --
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 +--
> 2 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9151d5add960..3dbf2d545f24 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3242,6 +3242,10 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
> {
> + struct intel_connector *connector =
> + to_intel_connector(conn_state->connector);
> + struct intel_hdcp *hdcp = >hdcp;
> +
> drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
>
> if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> @@ -3259,9 +3263,15 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
> else
> intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
>
> - /* Enable hdcp if it's desired */
> + /*
> + * Enable hdcp if it's desired or if userspace is enabled and
> + * driver set its state to undesired
> + */
> if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> + DRM_MODE_CONTENT_PROTECTION_DESIRED ||
> + (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_ENABLED && hdcp->value ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
Why don't we move all of this inside intel_hdcp.c to not pollute
intel_ddi.c with the logic?
> intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 7b4628f4f124..008ff14fad18 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -788,6 +788,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state
> *state,
> struct intel_digital_port *dig_port = intel_mst->primary;
> struct intel_dp *intel_dp = _port->dp;
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> + struct intel_hdcp *hdcp = >hdcp;
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct drm_dp_mst_topology_state *mst_state =
> drm_atomic_get_new_mst_topology_state(>base,
> _dp->mst_mgr);
> @@ -836,9 +837,15 @@ static void intel_mst_enable_dp(struct
> intel_atomic_state *state,
>
> intel_audio_codec_enable(encoder, pipe_config, conn_state);
>
> - /* Enable hdcp if it's desired */
> + /*
> + * Enable hdcp if it's desired or if userspace is enabled and
> + * driver set its state to undesired
> + */
> if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> + DRM_MODE_CONTENT_PROTECTION_DESIRED ||
> + (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_ENABLED && hdcp->value ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
Ditto. This is just copy-paste here anyway.
> intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> }
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add the darkscreen debugfs under crtc
On Wed, 25 Oct 2023, Nemesa Garg wrote:
> Add debugfs entry for darkscreen to know the status
> bpc and timer value .
Superfluous space before '.'.
>
> Signed-off-by: Nemesa Garg
> ---
> .../gpu/drm/i915/display/intel_darkscreen.c | 38 +++
> .../drm/i915/display/intel_display_debugfs.c | 2 +
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_darkscreen.c
> b/drivers/gpu/drm/i915/display/intel_darkscreen.c
> index ef68dbc7a296..c6490c16fdb5 100644
> --- a/drivers/gpu/drm/i915/display/intel_darkscreen.c
> +++ b/drivers/gpu/drm/i915/display/intel_darkscreen.c
> @@ -67,3 +67,41 @@ void dark_screen_enable(struct intel_crtc_state
> *crtc_state)
> intel_de_rmw(dev_priv, DARK_SCREEN(crtc->config->cpu_transcoder), 0,
> DARK_SCREEN_DETECT |
> DARK_SCREEN_DONE);
> }
> +
> +static int intel_darkscreen_debugfs_status_get(void *data, u64 *val)
> +{
> + struct intel_crtc *crtc = data;
> +
> + *val = crtc->dark_screen.enable;
> +
> + return 0;
> +}
> +
> +static int intel_darkscreen_debugfs_status_set(void *data, u64 val)
> +{
> + struct intel_crtc *crtc = data;
> + struct intel_crtc_state *crtc_state;
> +
> + crtc->dark_screen.enable = val;
> +
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> +
> + if (crtc_state)
> + dark_screen_enable(crtc_state);
Can it be enabled on the fly?
The function returns early if !enable. So how do you *disable* this
thing?
> +
> + return 0;
> +}
> +
> +/*
> + * Check the status whether the darkscreen
> + * is enabled or not.
> + */
Useless comment.
> +DEFINE_DEBUGFS_ATTRIBUTE(intel_darkscreen_debugfs_status_fops,
> + intel_darkscreen_debugfs_status_get,
> + intel_darkscreen_debugfs_status_set, "%llu\n");
> +
> +void intel_darkscreen_crtc_debugfs_add(struct intel_crtc *crtc)
> +{
> + debugfs_create_file("i915_darkscreen_status", 0644,
> crtc->base.debugfs_entry,
> + crtc, _darkscreen_debugfs_status_fops);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 2836826f8c05..27a6141eab3e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -33,6 +33,7 @@
> #include "intel_psr.h"
> #include "intel_psr_regs.h"
> #include "intel_wm.h"
> +#include "intel_darkscreen.h"
>
> static inline struct drm_i915_private *node_to_i915(struct drm_info_node
> *node)
> {
> @@ -1539,6 +1540,7 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
> intel_drrs_crtc_debugfs_add(crtc);
> intel_fbc_crtc_debugfs_add(crtc);
> hsw_ips_crtc_debugfs_add(crtc);
> + intel_darkscreen_crtc_debugfs_add(crtc);
>
> debugfs_create_file("i915_current_bpc", 0444, root, crtc,
> _current_bpc_fops);
--
Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add Darkscreen registers and timer handler.
On Wed, 25 Oct 2023, Nemesa Garg wrote:
> Add new registers for Darkscreen
> The logic checks for any black screen at pipe level and upon such detection
> prints error.
> Darkscreen compares the pixels with the compare value(0x00 - black) for the
> detection purpose.
> This feature can be enable/disable through debugfs.
The most important question a commit message should answer is *why*.
Why do we need this, what is it for?
Please find a number of nitpicks below.
First, the commit subject does not describe the patch. Registers and
timer handling? Huh?
The commit message should be wrapped. This is all explained in
Documentation/process/submitting-patches.rst; please read it.
>
> Signed-off-by: Nemesa Garg
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/display/intel_darkscreen.c | 69 +++
> .../gpu/drm/i915/display/intel_darkscreen.h | 40 +++
> .../drm/i915/display/intel_display_types.h| 3 +
> drivers/gpu/drm/i915/i915_reg.h | 9 +++
> 5 files changed, 122 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 88b2bb005014..538d5a42f9e3 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -254,6 +254,7 @@ i915-y += \
> display/intel_crtc.o \
> display/intel_crtc_state_dump.o \
> display/intel_cursor.o \
> + display/intel_darkscreen.o \
> display/intel_display.o \
> display/intel_display_driver.o \
> display/intel_display_irq.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_darkscreen.c
> b/drivers/gpu/drm/i915/display/intel_darkscreen.c
> new file mode 100644
> index ..ef68dbc7a296
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_darkscreen.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2018 Intel Corporation
It's 2023 now.
> + *
> + * Author: Nemesa Garg
Please don't add Author: lines in source code.
The git history says who has done what, and is always up-to-date. Adding
authors in source presents a problem: when do you amend it? Some people
update them with a typo fix, some people almost never, even when they
rewrite the entire file. Then it's just stale information.
I, for example, have modified almost every file in the entire i915
driver. Should I add my name to all of them? What would be the point?
Finally, I think author lines give a false sense of ownership in a
fundamentally shared project.
Yes, we have existing author lines, but that's just because of another
problem with author lines: they're actually incredibly hard to remove.
> + */
Blank line here.
> +#include "i915_reg.h"
> +#include "intel_display_types.h"
> +#include "intel_de.h"
Please sort includes.
> +
> +/*
> + * Dark screen detection check if all pixels
> + * in a frame are less than or equal to compare
> + * value.Check the color format and compute the
> + * compare value based on bpc.
Rewrap, space after '.'.
> + */
> +void dark_screen_enable(struct intel_crtc_state *crtc_state)
Non-static functions should have prefix that matches the file name.
E.g. intel_foo.[ch] -> intel_foo_bar().
> +{
> + u32 comparevalue;
Usually the longer declarations go first.
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +
> + if (!crtc->dark_screen.enable)
> + return;
> +
> + if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
> + return;
Blank line here.
> + drm_err(_priv->drm,
> + "RGB format is not present%c\n",
Is this a useful log line:
RGB format is not presentB
Is it worth an *error* in the dmesg?
> + pipe_name(crtc->pipe));
The whole thing fits on two lines.
> +
> + switch (crtc_state->pipe_bpp / 3) {
> + case DD_COLOR_DEPTH_6BPC:
> + comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_6_BPC;
> + break;
> + case DD_COLOR_DEPTH_8BPC:
> + comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_8_BPC;
> + break;
> + case DD_COLOR_DEPTH_10BPC:
> + comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_10_BPC;
> + break;
> + case DD_COLOR_DEPTH_12BPC:
> + comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_12_BPC;
> + break;
> + default:
You'll get a warning about uninitialized comparevalue on this code path.
> + break;
> + }
> +
> + comparevalue = comparevalue <<
> + (DARKSCREEN_PROGRAMMED_COMPARE_VALUE_CALCULATION_FACTOR -
> crtc->dark_screen.bpc);
That macro name is silly long.
> +
> + intel_de_write(dev_priv,
Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available
On 25/10/2023 11:32, Coelho, Luciano wrote:
On Wed, 2023-10-25 at 11:25 +0100, Tvrtko Ursulin wrote:
On 25/10/2023 11:18, Tvrtko Ursulin wrote:
On 23/10/2023 11:33, Luca Coelho wrote:
The uncore code may not always be available (e.g. when we build the
display code with Xe), so we can't always rely on having the uncore's
spinlock.
To handle this, split the spin_lock/unlock_irqsave/restore() into
spin_lock/unlock() followed by a call to local_irq_save/restore() and
create wrapper functions for locking and unlocking the uncore's
spinlock. In these functions, we have a condition check and only
actually try to lock/unlock the spinlock when I915 is defined, and
thus uncore is available.
This keeps the ifdefs contained in these new functions and all such
logic inside the display code.
Signed-off-by: Luca Coelho
---
In v2:
* Renamed uncore_spin_*() to intel_spin_*()
* Corrected the order: save, lock, unlock, restore
In v3:
* Undid the change to pass drm_i915_private instead of the lock
itself, since we would have to include i915_drv.h and that pulls
in a truckload of other includes.
drivers/gpu/drm/i915/display/intel_display.h | 20
drivers/gpu/drm/i915/display/intel_vblank.c | 19 ---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 0e5dffe8f018..2a33fcc8ce68 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -559,4 +559,24 @@ bool assert_port_valid(struct drm_i915_private
*i915, enum port port);
bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915);
+/*
+ * The uncore version of the spin lock functions is used to decide
+ * whether we need to lock the uncore lock or not. This is only
+ * needed in i915, not in Xe. Keep the decision-making centralized
+ * here.
+ */
+static inline void intel_spin_lock(spinlock_t *lock)
+{
+#ifdef I915
+ spin_lock(lock);
+#endif
+}
+
+static inline void intel_spin_unlock(spinlock_t *lock)
+{
+#ifdef I915
+ spin_unlock(lock);
+#endif
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
b/drivers/gpu/drm/i915/display/intel_vblank.c
index 2cec2abf9746..9b482d648762 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -306,7 +306,8 @@ static bool i915_get_crtc_scanoutpos(struct
drm_crtc *_crtc,
* register reads, potentially with preemption disabled, so the
* following code must not block on uncore.lock.
*/
- spin_lock_irqsave(_priv->uncore.lock, irqflags);
+ local_irq_save(irqflags);
Does Xe needs interrupts off?
I'm actually not sure, but this is how it was in the Xe driver code, so
I kept it.
+ intel_spin_lock(_priv->uncore.lock);
My 2p/c is that intel_spin_lock as a name does not work when it is
specifically about the single and specific (uncore) lock. One cannot
call intel_spin_lock(some->other->lock) etc.
Right, this was changed when I was passing only dev_priv, but I
couldn't do that wihtout adding i915_drv.h, which was not good
either... But yeah, this is too generic, while the actual case is not.
Perhaps call it i915_uncore_lock_irqsave(i915, flags) so it is clear it
is only for i915.
I wanted to avoid "i915", since we also call it when the display is
used with xe...
Or, if the implementation will later gain the #else block for Xe,
perhaps intel_uncore_lock_...?
But still, uncore doesn't exist in Xe, so this is still not good...
Any other suggestions?
I think it will boil down to the reason uncore lock is held over the
respective sections ie. the comment in i915_get_crtc_scanoutpos.
If it is timing sensitive to the extent irq off was needed it may apply
to Xe as well. Likewise the need to use mmio helpers which rely on the
uncore lock already held. Question of whether there is conceptual
commonality, will probably drive the best name, or the best approach in
general.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Hello, On Wed, Oct 25, 2023 at 10:53:27AM +0100, Sean Young wrote: > On Mon, Oct 23, 2023 at 02:34:17PM +0100, Daniel Thompson wrote: > > On Sun, Oct 22, 2023 at 11:46:22AM +0100, Sean Young wrote: > > > On Sat, Oct 21, 2023 at 11:08:22AM +0200, Hans de Goede wrote: > > > > On 10/19/23 12:51, Uwe Kleine-König wrote: > > > > > On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: > > > > >> On 10/17/23 11:17, Sean Young wrote: > > > > > I think it's very subjective if you consider this > > > > > churn or not. > > > > > > > > I consider it churn because I don't think adding a postfix > > > > for what is the default/expected behavior is a good idea > > > > (with GPIOs not sleeping is the expected behavior). > > > > > > > > I agree that this is very subjective and very much goes > > > > into the territory of bikeshedding. So please consider > > > > the above my 2 cents on this and lets leave it at that. > > > > > > You have a valid point. Let's focus on having descriptive function names. > > > > For a couple of days I've been trying to resist the bikeshedding (esp. > > given the changes to backlight are tiny) so I'll try to keep it as > > brief as I can: > > > > 1. I dislike the do_it() and do_it_cansleep() pairing. It is > >difficult to detect when a client driver calls do_it() by mistake. > >In fact a latent bug of this nature can only be detected by runtime > >testing with the small number of PWMs that do not support > >configuration from an atomic context. > > > >In contrast do_it() and do_it_atomic()[*] means that although > >incorrectly calling do_it() from an atomic context can be pretty > >catastrophic it is also trivially detected (with any PWM driver) > >simply by running with CONFIG_DEBUG_ATOMIC_SLEEP. Wrongly calling the atomic variant (no matter how it's named) in a context where sleeping is possible is only a minor issue. Being faster than necessary is hardly a problem, so it only hurts by not being an preemption point with PREEMPT_VOLUNTARY which might not even be relevant because we're near to a system call anyhow. For me the naming is only very loosely related to the possible bugs. I think calling the wrong function happens mainly because the driver author isn't aware in which context the call happens and not because of wrong assumptions about the sleepiness of a certain function call. If you consider this an argument however, do_it + do_it_cansleep is better than do_it_atomic + do_it as wrongly assuming do_it would sleep is less bad than wrongly assuming do_it wouldn't sleep. (The latter is catched by CONFIG_DEBUG_ATOMIC_SLEEP, but only if it's enabled.) Having said that while my subjective preference ordering is (with first = best): do_it + do_it_cansleep do_it_atomic + do_it_cansleep do_it_atomic + do_it wi(th a _might_sleep or _mightsleep suffix ranging below _cansleep) I wouldn't get sleepless nights when I get overruled here (uwe_cansleep :-). > >No objections (beyond churn) to fully spelt out pairings such as > >do_it_cansleep() and do_it_atomic()[*]! > > I must say I do like the look of this. Uwe, how do you feel about: > pwm_apply_cansleep() and pwm_apply_atomic()? I know we've talked about > pwm_apply_atomic in the past, however I think this this the best > option I've seen so far. > > > 2. If there is an API rename can we make sure the patch contains no > >other changes (e.g. don't introduce any new API in the same patch). > >Seperating renames makes the patches easier to review! > >It makes each one smaller and easier to review! > > Yes, this should have been separated out. Will fix for next version. +1 Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH 2/2] drm/i915: move Makefile display debugfs files next to display
On Wed, 25 Oct 2023, Nirmoy Das wrote: > On 10/24/2023 3:04 PM, Jani Nikula wrote: >> Keep the display build lists together. >> >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/Makefile | 7 --- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile >> index bc785dd89c19..e92682424915 100644 >> --- a/drivers/gpu/drm/i915/Makefile >> +++ b/drivers/gpu/drm/i915/Makefile >> @@ -95,9 +95,7 @@ i915-$(CONFIG_COMPAT) += \ >> i915_ioc32.o >> i915-$(CONFIG_DEBUG_FS) += \ >> i915_debugfs.o \ >> -i915_debugfs_params.o \ >> -display/intel_display_debugfs.o \ >> -display/intel_pipe_crc.o >> +i915_debugfs_params.o >> i915-$(CONFIG_PERF_EVENTS) += \ >> i915_pmu.o >> >> @@ -318,6 +316,9 @@ i915-$(CONFIG_ACPI) += \ >> display/intel_opregion.o >> i915-$(CONFIG_DRM_FBDEV_EMULATION) += \ >> display/intel_fbdev.o >> +i915-$(CONFIG_DEBUG_FS) += \ >> +display/intel_display_debugfs.o \ >> +display/intel_pipe_crc.o > > From a quick look, I am not sure how this file is related to debugfs. I > will try to find out but that is The pipe crc is only available via drm debugfs. > > unrelated to this patch so > > Reviewed-by: Nirmoy Das Thanks, Jani. > >> >> # modesetting output/encoder code >> i915-y += \ -- Jani Nikula, Intel
[Intel-gfx] [PATCH 1/2] drm/i915: Add Darkscreen registers and timer handler.
Add new registers for Darkscreen
The logic checks for any black screen at pipe level and upon such detection
prints error.
Darkscreen compares the pixels with the compare value(0x00 - black) for the
detection purpose.
This feature can be enable/disable through debugfs.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/display/intel_darkscreen.c | 69 +++
.../gpu/drm/i915/display/intel_darkscreen.h | 40 +++
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/i915_reg.h | 9 +++
5 files changed, 122 insertions(+)
create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.c
create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 88b2bb005014..538d5a42f9e3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -254,6 +254,7 @@ i915-y += \
display/intel_crtc.o \
display/intel_crtc_state_dump.o \
display/intel_cursor.o \
+ display/intel_darkscreen.o \
display/intel_display.o \
display/intel_display_driver.o \
display/intel_display_irq.o \
diff --git a/drivers/gpu/drm/i915/display/intel_darkscreen.c
b/drivers/gpu/drm/i915/display/intel_darkscreen.c
new file mode 100644
index ..ef68dbc7a296
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_darkscreen.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright ?? 2018 Intel Corporation
+ *
+ * Author: Nemesa Garg
+ */
+#include "i915_reg.h"
+#include "intel_display_types.h"
+#include "intel_de.h"
+
+/*
+ * Dark screen detection check if all pixels
+ * in a frame are less than or equal to compare
+ * value.Check the color format and compute the
+ * compare value based on bpc.
+ */
+void dark_screen_enable(struct intel_crtc_state *crtc_state)
+{
+ u32 comparevalue;
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (!crtc->dark_screen.enable)
+ return;
+
+ if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
+ return;
+ drm_err(_priv->drm,
+ "RGB format is not present%c\n",
+ pipe_name(crtc->pipe));
+
+ switch (crtc_state->pipe_bpp / 3) {
+ case DD_COLOR_DEPTH_6BPC:
+ comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_6_BPC;
+ break;
+ case DD_COLOR_DEPTH_8BPC:
+ comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_8_BPC;
+ break;
+ case DD_COLOR_DEPTH_10BPC:
+ comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_10_BPC;
+ break;
+ case DD_COLOR_DEPTH_12BPC:
+ comparevalue = DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_12_BPC;
+ break;
+ default:
+ break;
+ }
+
+ comparevalue = comparevalue <<
+ (DARKSCREEN_PROGRAMMED_COMPARE_VALUE_CALCULATION_FACTOR -
crtc->dark_screen.bpc);
+
+ intel_de_write(dev_priv, DARK_SCREEN(cpu_transcoder),
+ DARK_SCREEN_ENABLE | DARK_SCREEN_DETECT |
+ DARK_SCREEN_DONE |
DARK_SCREEN_COMPARE_VAL(comparevalue));
+
+ intel_de_wait_for_set(dev_priv,
+ DARK_SCREEN(crtc->config->cpu_transcoder),
DARK_SCREEN_DONE, 1);
+
+ if (intel_de_read(dev_priv, DARK_SCREEN(crtc->config->cpu_transcoder)) &
+ DARK_SCREEN_DETECT) {
+ drm_err(_priv->drm,
+ "Dark Screen detected %c\n",
+ pipe_name(crtc->pipe));
+ }
+
+ intel_de_rmw(dev_priv, DARK_SCREEN(crtc->config->cpu_transcoder), 0,
DARK_SCREEN_DETECT |
+ DARK_SCREEN_DONE);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_darkscreen.h
b/drivers/gpu/drm/i915/display/intel_darkscreen.h
new file mode 100644
index ..69da1ea56829
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_darkscreen.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright ?? 2018 Intel Corporation
+ *
+ * Author: Nemesa Garg
+ */
+
+#ifndef __INTEL_DARKSCREEN_H__
+#define __INTEL_DARKSCREEN_H__
+
+#include
+
+#define DD_COLOR_DEPTH_6BPC 6
+#define DD_COLOR_DEPTH_8BPC 8
+#define DD_COLOR_DEPTH_10BPC 10
+#define DD_COLOR_DEPTH_12BPC 12
+
+// HW Darkscreen Detection Macros
+#define DARKSCREEN_PROGRAMMED_COMPARE_VALUE_CALCULATION_FACTOR 12
+
+// Compare Value = 16*(2 ^ (bpc-8))
+#define DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_6_BPC 4
+#define DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_8_BPC 16
+#define DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_10_BPC 64
+#define DARKSCREEN_COMPARE_VALUE_LIMITED_RANGE_12_BPC 256
+
+struct intel_crtc_state;
+struct
[Intel-gfx] [PATCH 2/2] drm/i915: Add the darkscreen debugfs under crtc
Add debugfs entry for darkscreen to know the status
bpc and timer value .
Signed-off-by: Nemesa Garg
---
.../gpu/drm/i915/display/intel_darkscreen.c | 38 +++
.../drm/i915/display/intel_display_debugfs.c | 2 +
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_darkscreen.c
b/drivers/gpu/drm/i915/display/intel_darkscreen.c
index ef68dbc7a296..c6490c16fdb5 100644
--- a/drivers/gpu/drm/i915/display/intel_darkscreen.c
+++ b/drivers/gpu/drm/i915/display/intel_darkscreen.c
@@ -67,3 +67,41 @@ void dark_screen_enable(struct intel_crtc_state *crtc_state)
intel_de_rmw(dev_priv, DARK_SCREEN(crtc->config->cpu_transcoder), 0,
DARK_SCREEN_DETECT |
DARK_SCREEN_DONE);
}
+
+static int intel_darkscreen_debugfs_status_get(void *data, u64 *val)
+{
+ struct intel_crtc *crtc = data;
+
+ *val = crtc->dark_screen.enable;
+
+ return 0;
+}
+
+static int intel_darkscreen_debugfs_status_set(void *data, u64 val)
+{
+ struct intel_crtc *crtc = data;
+ struct intel_crtc_state *crtc_state;
+
+ crtc->dark_screen.enable = val;
+
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
+ if (crtc_state)
+ dark_screen_enable(crtc_state);
+
+ return 0;
+}
+
+/*
+ * Check the status whether the darkscreen
+ * is enabled or not.
+ */
+DEFINE_DEBUGFS_ATTRIBUTE(intel_darkscreen_debugfs_status_fops,
+intel_darkscreen_debugfs_status_get,
+intel_darkscreen_debugfs_status_set, "%llu\n");
+
+void intel_darkscreen_crtc_debugfs_add(struct intel_crtc *crtc)
+{
+ debugfs_create_file("i915_darkscreen_status", 0644,
crtc->base.debugfs_entry,
+ crtc, _darkscreen_debugfs_status_fops);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2836826f8c05..27a6141eab3e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -33,6 +33,7 @@
#include "intel_psr.h"
#include "intel_psr_regs.h"
#include "intel_wm.h"
+#include "intel_darkscreen.h"
static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
{
@@ -1539,6 +1540,7 @@ void intel_crtc_debugfs_add(struct intel_crtc *crtc)
intel_drrs_crtc_debugfs_add(crtc);
intel_fbc_crtc_debugfs_add(crtc);
hsw_ips_crtc_debugfs_add(crtc);
+ intel_darkscreen_crtc_debugfs_add(crtc);
debugfs_create_file("i915_current_bpc", 0444, root, crtc,
_current_bpc_fops);
--
2.25.1
[Intel-gfx] [PATCH 0/2] Enable Darkscreen Feature
The logic checks for any black screen at pipe level and upon such detection prints error. Darkscreen compares the pixels with the compare value(0x00 - black) for the detection purpose. This feature can be enables/disabled through debugfs. Nemesa Garg (2): drm/i915: Add Darkscreen registers and timer handler. drm/i915: Add the darkscreen debugfs under crtc drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/display/intel_darkscreen.c | 107 ++ .../gpu/drm/i915/display/intel_darkscreen.h | 40 +++ .../drm/i915/display/intel_display_debugfs.c | 2 + .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/i915_reg.h | 9 ++ 6 files changed, 162 insertions(+) create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.c create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.h -- 2.25.1
[Intel-gfx] [PATCH v3] drm/i915/mtl: Add Wa_14019821291
This workaround is primarily implemented by the BIOS. However if the
BIOS applies the workaround it will reserve a small piece of our DSM
(which should be at the top, right below the WOPCM); we just need to
keep that region reserved so that nothing else attempts to re-use it.
v2: Declare regs in intel_gt_regs.h (Matt Roper)
v3: Shift WA implementation before calculation of *base (Matt Roper)
Signed-off-by: Dnyaneshwar Bhadane
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 17 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h| 3 +++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 1a766d8e7cce..192c9a333c0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -404,6 +404,23 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+ /* Wa_14019821291 */
+ if (MEDIA_VER_FULL(i915) == IP_VER(13, 0)) {
+ /*
+* This workaround is primarily implemented by the BIOS. We
+* just need to figure out whether the BIOS has applied the
+* workaround (meaning the programmed address falls within
+* the DSM) and, if so, reserve that part of the DSM to
+* prevent accidental reuse. The DSM location should be just
+* below the WOPCM.
+*/
+ u64 gscpsmi_base = intel_uncore_read64_2x32(uncore,
+
MTL_GSCPSMI_BASEADDR_LSB,
+
MTL_GSCPSMI_BASEADDR_MSB);
+ if (gscpsmi_base >= *base && gscpsmi_base < *base + *size)
+ *size = gscpsmi_base - *base;
+ }
+
if (HAS_LMEMBAR_SMEM_STOLEN(i915))
/* the base is initialized to stolen top so subtract size to
get base */
*base -= *size;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index eecd0a87a647..9de41703fae5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -537,6 +537,9 @@
#define XEHP_SQCM MCR_REG(0x8724)
#define EN_32B_ACCESSREG_BIT(30)
+#define MTL_GSCPSMI_BASEADDR_LSB _MMIO(0x880c)
+#define MTL_GSCPSMI_BASEADDR_MSB _MMIO(0x8810)
+
#define HSW_IDICR _MMIO(0x9008)
#define IDIHASHMSK(x)(((x) & 0x3f) << 16)
--
2.34.1
Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available
On Wed, 2023-10-25 at 11:25 +0100, Tvrtko Ursulin wrote:
> On 25/10/2023 11:18, Tvrtko Ursulin wrote:
> >
> > On 23/10/2023 11:33, Luca Coelho wrote:
> > > The uncore code may not always be available (e.g. when we build the
> > > display code with Xe), so we can't always rely on having the uncore's
> > > spinlock.
> > >
> > > To handle this, split the spin_lock/unlock_irqsave/restore() into
> > > spin_lock/unlock() followed by a call to local_irq_save/restore() and
> > > create wrapper functions for locking and unlocking the uncore's
> > > spinlock. In these functions, we have a condition check and only
> > > actually try to lock/unlock the spinlock when I915 is defined, and
> > > thus uncore is available.
> > >
> > > This keeps the ifdefs contained in these new functions and all such
> > > logic inside the display code.
> > >
> > > Signed-off-by: Luca Coelho
> > > ---
> > >
> > > In v2:
> > >
> > > * Renamed uncore_spin_*() to intel_spin_*()
> > > * Corrected the order: save, lock, unlock, restore
> > >
> > > In v3:
> > >
> > > * Undid the change to pass drm_i915_private instead of the lock
> > > itself, since we would have to include i915_drv.h and that pulls
> > > in a truckload of other includes.
> > >
> > > drivers/gpu/drm/i915/display/intel_display.h | 20
> > > drivers/gpu/drm/i915/display/intel_vblank.c | 19 ---
> > > 2 files changed, 32 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> > > b/drivers/gpu/drm/i915/display/intel_display.h
> > > index 0e5dffe8f018..2a33fcc8ce68 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.h
> > > @@ -559,4 +559,24 @@ bool assert_port_valid(struct drm_i915_private
> > > *i915, enum port port);
> > > bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915);
> > > +/*
> > > + * The uncore version of the spin lock functions is used to decide
> > > + * whether we need to lock the uncore lock or not. This is only
> > > + * needed in i915, not in Xe. Keep the decision-making centralized
> > > + * here.
> > > + */
> > > +static inline void intel_spin_lock(spinlock_t *lock)
> > > +{
> > > +#ifdef I915
> > > + spin_lock(lock);
> > > +#endif
> > > +}
> > > +
> > > +static inline void intel_spin_unlock(spinlock_t *lock)
> > > +{
> > > +#ifdef I915
> > > + spin_unlock(lock);
> > > +#endif
> > > +}
> > > +
> > > #endif
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
> > > b/drivers/gpu/drm/i915/display/intel_vblank.c
> > > index 2cec2abf9746..9b482d648762 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> > > @@ -306,7 +306,8 @@ static bool i915_get_crtc_scanoutpos(struct
> > > drm_crtc *_crtc,
> > > * register reads, potentially with preemption disabled, so the
> > > * following code must not block on uncore.lock.
> > > */
> > > - spin_lock_irqsave(_priv->uncore.lock, irqflags);
> > > + local_irq_save(irqflags);
> >
> > Does Xe needs interrupts off?
I'm actually not sure, but this is how it was in the Xe driver code, so
I kept it.
> > > + intel_spin_lock(_priv->uncore.lock);
> >
> > My 2p/c is that intel_spin_lock as a name does not work when it is
> > specifically about the single and specific (uncore) lock. One cannot
> > call intel_spin_lock(some->other->lock) etc.
Right, this was changed when I was passing only dev_priv, but I
couldn't do that wihtout adding i915_drv.h, which was not good
either... But yeah, this is too generic, while the actual case is not.
> > Perhaps call it i915_uncore_lock_irqsave(i915, flags) so it is clear it
> > is only for i915.
I wanted to avoid "i915", since we also call it when the display is
used with xe...
> Or, if the implementation will later gain the #else block for Xe,
> perhaps intel_uncore_lock_...?
But still, uncore doesn't exist in Xe, so this is still not good...
Any other suggestions?
--
Cheers,
Luca.
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Apply notify_guc to all GTs
Hi Nirmoy,
On Wed, Oct 25, 2023 at 12:28:26PM +0200, Nirmoy Das wrote:
> Handle platforms with multiple GTs by iterate over all GTs.
> Add a Fixes commit so this gets propagated for MTL support.
>
> Fixes: 213c43676beb ("drm/i915/mtl: Remove the 'force_probe' requirement for
> Meteor Lake")
> Suggested-by: John Harrison
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Andi Shyti
> Cc: Andrzej Hajda
> Signed-off-by: Nirmoy Das
I wonder when we will manage to add all the for_each_gt's
everywhere they are needed :-)
Thanks for the patch!
Reviewed-by: Andi Shyti
Andi
Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper
On Wed, Oct 25, 2023 at 11:20:25AM +0100, Tvrtko Ursulin wrote: > > On 24/10/2023 13:42, Jani Nikula wrote: > > On Tue, 24 Oct 2023, Andi Shyti wrote: > > > Hi Jani, > > > > > > On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote: > > > > It's tedious to duplicate the container_of() everywhere. Add a helper. > > > > > > > > Also do the logical steps of first getting from struct perf_event to > > > > struct i915_pmu, and then from struct i915_pmu to struct > > > > drm_i915_private if needed, instead of perf_event->i915->pmu. Not all > > > > places even need the i915 pointer. > > > > > > > > Signed-off-by: Jani Nikula > > > > --- > > > > drivers/gpu/drm/i915/i915_pmu.c | 45 +++-- > > > > 1 file changed, 20 insertions(+), 25 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c > > > > b/drivers/gpu/drm/i915/i915_pmu.c > > > > index dcae2fcd8d36..d45b40ec6d47 100644 > > > > --- a/drivers/gpu/drm/i915/i915_pmu.c > > > > +++ b/drivers/gpu/drm/i915/i915_pmu.c > > > > @@ -31,6 +31,11 @@ > > > > static cpumask_t i915_pmu_cpumask; > > > > static unsigned int i915_pmu_target_cpu = -1; > > > > +static struct i915_pmu *event_to_pmu(struct perf_event *event) > > > > > > I would call it perfevent (or perf_event), event is too generic. > > > We have other kind of events, too. > > > > Fair enough. > > Counter argument is that i915_pmu.c consistently names this event (which is > likely lifted from other PMU drivers) so is the proposal to churn it all, or > create an inconsistency? The first that comes to my mind is that the debugger is also using the term "event"... on the other hand there is no debugger in i915. Andi
[Intel-gfx] [PATCH] drm/i915/mtl: Apply notify_guc to all GTs
Handle platforms with multiple GTs by iterate over all GTs.
Add a Fixes commit so this gets propagated for MTL support.
Fixes: 213c43676beb ("drm/i915/mtl: Remove the 'force_probe' requirement for
Meteor Lake")
Suggested-by: John Harrison
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_debugfs_params.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 614bde321589..8bca02025e09 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -38,10 +38,13 @@ static int i915_param_int_open(struct inode *inode, struct
file *file)
static int notify_guc(struct drm_i915_private *i915)
{
- int ret = 0;
+ struct intel_gt *gt;
+ int i, ret = 0;
- if (intel_uc_uses_guc_submission(_gt(i915)->uc))
- ret = intel_guc_global_policies_update(_gt(i915)->uc.guc);
+ for_each_gt(gt, i915, i) {
+ if (intel_uc_uses_guc_submission(>uc))
+ ret = intel_guc_global_policies_update(>uc.guc);
+ }
return ret;
}
--
2.41.0
Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available
On 25/10/2023 11:18, Tvrtko Ursulin wrote:
On 23/10/2023 11:33, Luca Coelho wrote:
The uncore code may not always be available (e.g. when we build the
display code with Xe), so we can't always rely on having the uncore's
spinlock.
To handle this, split the spin_lock/unlock_irqsave/restore() into
spin_lock/unlock() followed by a call to local_irq_save/restore() and
create wrapper functions for locking and unlocking the uncore's
spinlock. In these functions, we have a condition check and only
actually try to lock/unlock the spinlock when I915 is defined, and
thus uncore is available.
This keeps the ifdefs contained in these new functions and all such
logic inside the display code.
Signed-off-by: Luca Coelho
---
In v2:
* Renamed uncore_spin_*() to intel_spin_*()
* Corrected the order: save, lock, unlock, restore
In v3:
* Undid the change to pass drm_i915_private instead of the lock
itself, since we would have to include i915_drv.h and that pulls
in a truckload of other includes.
drivers/gpu/drm/i915/display/intel_display.h | 20
drivers/gpu/drm/i915/display/intel_vblank.c | 19 ---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 0e5dffe8f018..2a33fcc8ce68 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -559,4 +559,24 @@ bool assert_port_valid(struct drm_i915_private
*i915, enum port port);
bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915);
+/*
+ * The uncore version of the spin lock functions is used to decide
+ * whether we need to lock the uncore lock or not. This is only
+ * needed in i915, not in Xe. Keep the decision-making centralized
+ * here.
+ */
+static inline void intel_spin_lock(spinlock_t *lock)
+{
+#ifdef I915
+ spin_lock(lock);
+#endif
+}
+
+static inline void intel_spin_unlock(spinlock_t *lock)
+{
+#ifdef I915
+ spin_unlock(lock);
+#endif
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
b/drivers/gpu/drm/i915/display/intel_vblank.c
index 2cec2abf9746..9b482d648762 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -306,7 +306,8 @@ static bool i915_get_crtc_scanoutpos(struct
drm_crtc *_crtc,
* register reads, potentially with preemption disabled, so the
* following code must not block on uncore.lock.
*/
- spin_lock_irqsave(_priv->uncore.lock, irqflags);
+ local_irq_save(irqflags);
Does Xe needs interrupts off?
+ intel_spin_lock(_priv->uncore.lock);
My 2p/c is that intel_spin_lock as a name does not work when it is
specifically about the single and specific (uncore) lock. One cannot
call intel_spin_lock(some->other->lock) etc.
Perhaps call it i915_uncore_lock_irqsave(i915, flags) so it is clear it
is only for i915.
Or, if the implementation will later gain the #else block for Xe,
perhaps intel_uncore_lock_...?
Regards,
Tvrtko
/* preempt_disable_rt() should go right here in PREEMPT_RT
patchset. */
@@ -374,7 +375,8 @@ static bool i915_get_crtc_scanoutpos(struct
drm_crtc *_crtc,
/* preempt_enable_rt() should go right here in PREEMPT_RT
patchset. */
- spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+ intel_spin_unlock(_priv->uncore.lock);
+ local_irq_restore(irqflags);
/*
* While in vblank, position will be negative
@@ -412,9 +414,13 @@ int intel_get_crtc_scanline(struct intel_crtc *crtc)
unsigned long irqflags;
int position;
- spin_lock_irqsave(_priv->uncore.lock, irqflags);
+ local_irq_save(irqflags);
+ intel_spin_lock(_priv->uncore.lock);
+
position = __intel_get_crtc_scanline(crtc);
- spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+
+ intel_spin_unlock(_priv->uncore.lock);
+ local_irq_restore(irqflags);
return position;
}
@@ -537,7 +543,7 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state,
* Need to audit everything to make sure it's safe.
*/
spin_lock_irqsave(>drm.vblank_time_lock, irqflags);
- spin_lock(>uncore.lock);
+ intel_spin_lock(>uncore.lock);
drm_calc_timestamping_constants(>base, _mode);
@@ -546,7 +552,6 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state,
crtc->mode_flags = mode_flags;
crtc->scanline_offset = intel_crtc_scanline_offset(crtc_state);
-
- spin_unlock(>uncore.lock);
+ intel_spin_unlock(>uncore.lock);
spin_unlock_irqrestore(>drm.vblank_time_lock, irqflags);
}
Re: [Intel-gfx] [PATCH 2/3] drm/i915/pmu: add event_to_pmu() helper
On 24/10/2023 13:42, Jani Nikula wrote:
On Tue, 24 Oct 2023, Andi Shyti wrote:
Hi Jani,
On Mon, Oct 23, 2023 at 06:02:55PM +0300, Jani Nikula wrote:
It's tedious to duplicate the container_of() everywhere. Add a helper.
Also do the logical steps of first getting from struct perf_event to
struct i915_pmu, and then from struct i915_pmu to struct
drm_i915_private if needed, instead of perf_event->i915->pmu. Not all
places even need the i915 pointer.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_pmu.c | 45 +++--
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dcae2fcd8d36..d45b40ec6d47 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -31,6 +31,11 @@
static cpumask_t i915_pmu_cpumask;
static unsigned int i915_pmu_target_cpu = -1;
+static struct i915_pmu *event_to_pmu(struct perf_event *event)
I would call it perfevent (or perf_event), event is too generic.
We have other kind of events, too.
Fair enough.
Counter argument is that i915_pmu.c consistently names this event (which
is likely lifted from other PMU drivers) so is the proposal to churn it
all, or create an inconsistency?
Regards,
Tvrtko
+{
+ return container_of(event->pmu, struct i915_pmu, base);
+}
+
static struct drm_i915_private *pmu_to_i915(struct i915_pmu *pmu)
{
return container_of(pmu, struct drm_i915_private, pmu);
@@ -510,8 +515,8 @@ static enum hrtimer_restart i915_sample(struct hrtimer
*hrtimer)
static void i915_pmu_event_destroy(struct perf_event *event)
{
- struct drm_i915_private *i915 =
- container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = event_to_pmu(event);
+ struct drm_i915_private *i915 = pmu_to_i915(pmu);
perf_event_to_i915() ?
Nah. Most places that need i915 also need pmu. Feels a bit much to add a
helper to combine two helpers.
Thanks for the review.
BR,
Jani.
Andi
Re: [Intel-gfx] [PATCH v3] drm/i915: handle uncore spinlock when not available
On 23/10/2023 11:33, Luca Coelho wrote:
The uncore code may not always be available (e.g. when we build the
display code with Xe), so we can't always rely on having the uncore's
spinlock.
To handle this, split the spin_lock/unlock_irqsave/restore() into
spin_lock/unlock() followed by a call to local_irq_save/restore() and
create wrapper functions for locking and unlocking the uncore's
spinlock. In these functions, we have a condition check and only
actually try to lock/unlock the spinlock when I915 is defined, and
thus uncore is available.
This keeps the ifdefs contained in these new functions and all such
logic inside the display code.
Signed-off-by: Luca Coelho
---
In v2:
* Renamed uncore_spin_*() to intel_spin_*()
* Corrected the order: save, lock, unlock, restore
In v3:
* Undid the change to pass drm_i915_private instead of the lock
itself, since we would have to include i915_drv.h and that pulls
in a truckload of other includes.
drivers/gpu/drm/i915/display/intel_display.h | 20
drivers/gpu/drm/i915/display/intel_vblank.c | 19 ---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 0e5dffe8f018..2a33fcc8ce68 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -559,4 +559,24 @@ bool assert_port_valid(struct drm_i915_private *i915, enum
port port);
bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915);
+/*
+ * The uncore version of the spin lock functions is used to decide
+ * whether we need to lock the uncore lock or not. This is only
+ * needed in i915, not in Xe. Keep the decision-making centralized
+ * here.
+ */
+static inline void intel_spin_lock(spinlock_t *lock)
+{
+#ifdef I915
+ spin_lock(lock);
+#endif
+}
+
+static inline void intel_spin_unlock(spinlock_t *lock)
+{
+#ifdef I915
+ spin_unlock(lock);
+#endif
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
b/drivers/gpu/drm/i915/display/intel_vblank.c
index 2cec2abf9746..9b482d648762 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -306,7 +306,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
* register reads, potentially with preemption disabled, so the
* following code must not block on uncore.lock.
*/
- spin_lock_irqsave(_priv->uncore.lock, irqflags);
+ local_irq_save(irqflags);
Does Xe needs interrupts off?
+ intel_spin_lock(_priv->uncore.lock);
My 2p/c is that intel_spin_lock as a name does not work when it is
specifically about the single and specific (uncore) lock. One cannot
call intel_spin_lock(some->other->lock) etc.
Perhaps call it i915_uncore_lock_irqsave(i915, flags) so it is clear it
is only for i915.
Regards,
Tvrtko
/* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
@@ -374,7 +375,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
/* preempt_enable_rt() should go right here in PREEMPT_RT patchset. */
- spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+ intel_spin_unlock(_priv->uncore.lock);
+ local_irq_restore(irqflags);
/*
* While in vblank, position will be negative
@@ -412,9 +414,13 @@ int intel_get_crtc_scanline(struct intel_crtc *crtc)
unsigned long irqflags;
int position;
- spin_lock_irqsave(_priv->uncore.lock, irqflags);
+ local_irq_save(irqflags);
+ intel_spin_lock(_priv->uncore.lock);
+
position = __intel_get_crtc_scanline(crtc);
- spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+
+ intel_spin_unlock(_priv->uncore.lock);
+ local_irq_restore(irqflags);
return position;
}
@@ -537,7 +543,7 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state,
* Need to audit everything to make sure it's safe.
*/
spin_lock_irqsave(>drm.vblank_time_lock, irqflags);
- spin_lock(>uncore.lock);
+ intel_spin_lock(>uncore.lock);
drm_calc_timestamping_constants(>base, _mode);
@@ -546,7 +552,6 @@ void intel_crtc_update_active_timings(const struct intel_crtc_state *crtc_state,
crtc->mode_flags = mode_flags;
crtc->scanline_offset = intel_crtc_scanline_offset(crtc_state);
-
- spin_unlock(>uncore.lock);
+ intel_spin_unlock(>uncore.lock);
spin_unlock_irqrestore(>drm.vblank_time_lock, irqflags);
}
[Intel-gfx] [PATCH] drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier
Display driver shall read DPCD 00071h[3:1] during configuration
to get PSR setup time. This register provides the setup time
requirement on the VSC SDP entry packet. If setup time cannot be
met with the current timings
(e.g., PSR setup time + other blanking requirements > blanking time),
driver should enable sending VSC SDP one frame earlier before sending
the capture frame.
BSpec: 69895 (PSR Entry Setup Frames 17:16)
Signed-off-by: Mika Kahola
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 35 ---
drivers/gpu/drm/i915/display/intel_psr_regs.h | 2 ++
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 65ea37fe8cff..a0bcab6f2bec 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1710,6 +1710,7 @@ struct intel_psr {
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
+ u8 entry_setup_frames;
};
struct intel_dp {
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 4f1f31fc9529..0acb4edae128 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -592,6 +592,9 @@ static void intel_psr_enable_sink(struct intel_dp *intel_dp)
if (intel_dp->psr.req_psr2_sdp_prior_scanline)
dpcd_val |= DP_PSR_SU_REGION_SCANLINE_CAPTURE;
+ if (intel_dp->psr.entry_setup_frames > 0)
+ dpcd_val |= DP_PSR_FRAME_CAPTURE;
+
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
@@ -690,6 +693,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
if (DISPLAY_VER(dev_priv) >= 8)
val |= EDP_PSR_CRC_ENABLE;
+ if (intel_dp->psr.entry_setup_frames > 0)
+ val |=
EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp->psr.entry_setup_frames);
+
intel_de_rmw(dev_priv, psr_ctl_reg(dev_priv, cpu_transcoder),
~EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK, val);
}
@@ -731,6 +737,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
+ u8 frames_before_su_entry;
u32 val = EDP_PSR2_ENABLE;
val |= EDP_PSR2_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
@@ -741,7 +748,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
val |= EDP_Y_COORDINATE_ENABLE;
- val |= EDP_PSR2_FRAME_BEFORE_SU(max_t(u8,
intel_dp->psr.sink_sync_latency + 1, 2));
+ frames_before_su_entry = max_t(u8,
+ intel_dp->psr.sink_sync_latency + 1,
+ 2);
+ val |= EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry);
val |= intel_psr2_get_tp_time(intel_dp);
if (DISPLAY_VER(dev_priv) >= 12) {
@@ -785,6 +795,14 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (intel_dp->psr.req_psr2_sdp_prior_scanline)
val |= EDP_PSR2_SU_SDP_SCANLINE;
+ /* Entry setup frames must be at least 1 less than frames before SU
entry */
+ if (intel_dp->psr.entry_setup_frames > 0) {
+ val |=
EDP_PSR_ENTRY_SETUP_FRAMES(intel_dp->psr.entry_setup_frames);
+
+ if (intel_dp->psr.entry_setup_frames >= frames_before_su_entry)
+ val |= EDP_PSR2_FRAME_BEFORE_SU(frames_before_su_entry
+ 1);
+ }
+
if (intel_dp->psr.psr2_sel_fetch_enabled) {
u32 tmp;
@@ -1252,10 +1270,17 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay - 1) {
- drm_dbg_kms(_priv->drm,
- "PSR condition failed: PSR setup time (%d us) too
long\n",
- psr_setup_time);
- return;
+ if (DISPLAY_VER(dev_priv) >= 20) {
+ intel_dp->psr.entry_setup_frames = 1;
+ drm_dbg_kms(_priv->drm,
+ "PSR setup entry frames: %d\n",
+ intel_dp->psr.entry_setup_frames);
+ } else {
+ drm_dbg_kms(_priv->drm,
+ "PSR condition failed: PSR setup time (%d
us) too long\n",
+ psr_setup_time);
+ return;
+ }
}
crtc_state->has_psr = true;
diff --git
Re: [Intel-gfx] [PATCH v5 6/7] drm/i915: Implement fbdev client callbacks
Hi Thomas, couple of inline commments/suggestions below.
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Move code from ad-hoc fbdev callbacks into DRM client functions
> and remove the old callbacks. The functions instruct the client
> to poll for changed output or restore the display.
>
> The DRM core calls both, the old callbacks and the new client
> helpers, from the same places. The new functions perform the same
> operation as before, so there's no change in functionality.
>
> Signed-off-by: Thomas Zimmermann
> ---
> .../drm/i915/display/intel_display_driver.c | 1 -
> drivers/gpu/drm/i915/display/intel_fbdev.c | 11 --
> drivers/gpu/drm/i915/display/intel_fbdev.h | 9
> drivers/gpu/drm/i915/i915_driver.c | 22 -
> --
> 4 files changed, 9 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 44b59ac301e69..ffdcddd1943e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -96,7 +96,6 @@ void intel_display_driver_init_hw(struct
> drm_i915_private *i915)
> static const struct drm_mode_config_funcs intel_mode_funcs = {
> .fb_create = intel_user_framebuffer_create,
> .get_format_info = intel_fb_get_format_info,
> - .output_poll_changed = intel_fbdev_output_poll_changed,
> .mode_valid = intel_mode_valid,
> .atomic_check = intel_atomic_check,
> .atomic_commit = intel_atomic_commit,
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index d9e69471a782a..39de61d4e7906 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -638,7 +638,7 @@ void intel_fbdev_set_suspend(struct drm_device
> *dev, int state, bool synchronous
> intel_fbdev_hpd_set_suspend(dev_priv, state);
> }
>
> -void intel_fbdev_output_poll_changed(struct drm_device *dev)
> +static void intel_fbdev_output_poll_changed(struct drm_device *dev)
Now as this isn't drm_mode_config_funcs callback anymore: Maybe you
could return error value/0 ?
> {
> struct intel_fbdev *ifbdev = to_i915(dev)-
> >display.fbdev.fbdev;
> bool send_hpd;
> @@ -657,7 +657,7 @@ void intel_fbdev_output_poll_changed(struct
> drm_device *dev)
> drm_fb_helper_hotplug_event(>helper);
> }
>
> -void intel_fbdev_restore_mode(struct drm_i915_private *dev_priv)
> +static void intel_fbdev_restore_mode(struct drm_i915_private
Similar comment as above. I.e. return error value/0 ?
BR,
Jouni Högander
> *dev_priv)
> {
> struct intel_fbdev *ifbdev = dev_priv->display.fbdev.fbdev;
>
> @@ -681,11 +681,18 @@ static void
> intel_fbdev_client_unregister(struct drm_client_dev *client)
>
> static int intel_fbdev_client_restore(struct drm_client_dev *client)
> {
> + struct drm_i915_private *dev_priv = to_i915(client->dev);
> +
> + intel_fbdev_restore_mode(dev_priv);
> + vga_switcheroo_process_delayed_switch();
> +
> return 0;
> }
>
> static int intel_fbdev_client_hotplug(struct drm_client_dev *client)
> {
> + intel_fbdev_output_poll_changed(client->dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.h
> b/drivers/gpu/drm/i915/display/intel_fbdev.h
> index 04fd523a50232..8c953f102ba22 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.h
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.h
> @@ -19,8 +19,6 @@ void intel_fbdev_initial_config_async(struct
> drm_i915_private *dev_priv);
> void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
> void intel_fbdev_fini(struct drm_i915_private *dev_priv);
> void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
> synchronous);
> -void intel_fbdev_output_poll_changed(struct drm_device *dev);
> -void intel_fbdev_restore_mode(struct drm_i915_private *dev_priv);
> struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev
> *fbdev);
> #else
> static inline int intel_fbdev_init(struct drm_device *dev)
> @@ -44,13 +42,6 @@ static inline void intel_fbdev_set_suspend(struct
> drm_device *dev, int state, bo
> {
> }
>
> -static inline void intel_fbdev_output_poll_changed(struct drm_device
> *dev)
> -{
> -}
> -
> -static inline void intel_fbdev_restore_mode(struct drm_i915_private
> *i915)
> -{
> -}
> static inline struct intel_framebuffer
> *intel_fbdev_framebuffer(struct intel_fbdev *fbdev)
> {
> return NULL;
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index de19197d2e052..86460cd8167d1 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -924,27 +924,6 @@ static int i915_driver_open(struct drm_device
> *dev, struct drm_file *file)
> return 0;
> }
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915: move Makefile display debugfs files next to display
On 10/24/2023 3:04 PM, Jani Nikula wrote: Keep the display build lists together. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index bc785dd89c19..e92682424915 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -95,9 +95,7 @@ i915-$(CONFIG_COMPAT) += \ i915_ioc32.o i915-$(CONFIG_DEBUG_FS) += \ i915_debugfs.o \ - i915_debugfs_params.o \ - display/intel_display_debugfs.o \ - display/intel_pipe_crc.o + i915_debugfs_params.o i915-$(CONFIG_PERF_EVENTS) += \ i915_pmu.o @@ -318,6 +316,9 @@ i915-$(CONFIG_ACPI) += \ display/intel_opregion.o i915-$(CONFIG_DRM_FBDEV_EMULATION) += \ display/intel_fbdev.o +i915-$(CONFIG_DEBUG_FS) += \ + display/intel_display_debugfs.o \ + display/intel_pipe_crc.o From a quick look, I am not sure how this file is related to debugfs. I will try to find out but that is unrelated to this patch so Reviewed-by: Nirmoy Das # modesetting output/encoder code i915-y += \
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix Makefile sort and indent
On 10/24/2023 3:04 PM, Jani Nikula wrote: Unify the line continuations and indents, and sort the build lists. Signed-off-by: Jani Nikula --- Note: This is easiest to review by applying and looking at 'git show -w' Thanks for the hint :) Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/Makefile | 169 ++ 1 file changed, 89 insertions(+), 80 deletions(-) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 88b2bb005014..bc785dd89c19 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -47,33 +47,34 @@ subdir-ccflags-y += -I$(srctree)/$(src) # Please keep these build lists sorted! # core driver code -i915-y += i915_driver.o \ - i915_drm_client.o \ - i915_config.o \ - i915_getparam.o \ - i915_ioctl.o \ - i915_irq.o \ - i915_mitigations.o \ - i915_module.o \ - i915_params.o \ - i915_pci.o \ - i915_scatterlist.o \ - i915_suspend.o \ - i915_switcheroo.o \ - i915_sysfs.o \ - i915_utils.o \ - intel_clock_gating.o \ - intel_device_info.o \ - intel_memory_region.o \ - intel_pcode.o \ - intel_region_ttm.o \ - intel_runtime_pm.o \ - intel_sbi.o \ - intel_step.o \ - intel_uncore.o \ - intel_wakeref.o \ - vlv_sideband.o \ - vlv_suspend.o +i915-y += \ + i915_config.o \ + i915_driver.o \ + i915_drm_client.o \ + i915_getparam.o \ + i915_ioctl.o \ + i915_irq.o \ + i915_mitigations.o \ + i915_module.o \ + i915_params.o \ + i915_pci.o \ + i915_scatterlist.o \ + i915_suspend.o \ + i915_switcheroo.o \ + i915_sysfs.o \ + i915_utils.o \ + intel_clock_gating.o \ + intel_device_info.o \ + intel_memory_region.o \ + intel_pcode.o \ + intel_region_ttm.o \ + intel_runtime_pm.o \ + intel_sbi.o \ + intel_step.o \ + intel_uncore.o \ + intel_wakeref.o \ + vlv_sideband.o \ + vlv_suspend.o # core peripheral code i915-y += \ @@ -90,13 +91,15 @@ i915-y += \ i915_syncmap.o \ i915_user_extensions.o -i915-$(CONFIG_COMPAT) += i915_ioc32.o +i915-$(CONFIG_COMPAT) += \ + i915_ioc32.o i915-$(CONFIG_DEBUG_FS) += \ i915_debugfs.o \ i915_debugfs_params.o \ display/intel_display_debugfs.o \ display/intel_pipe_crc.o -i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o +i915-$(CONFIG_PERF_EVENTS) += \ + i915_pmu.o # "Graphics Technology" (aka we talk to the gpu) gt-y += \ @@ -153,7 +156,8 @@ gt-y += \ gt/sysfs_engines.o # x86 intel-gtt module support -gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o +gt-$(CONFIG_X86) += \ + gt/intel_ggtt_gmch.o # autogenerated null render state gt-y += \ gt/gen6_renderstate.o \ @@ -172,9 +176,9 @@ gem-y += \ gem/i915_gem_domain.o \ gem/i915_gem_execbuffer.o \ gem/i915_gem_internal.o \ - gem/i915_gem_object.o \ gem/i915_gem_lmem.o \ gem/i915_gem_mman.o \ + gem/i915_gem_object.o \ gem/i915_gem_pages.o \ gem/i915_gem_phys.o \ gem/i915_gem_pm.o \ @@ -191,57 +195,61 @@ gem-y += \ gem/i915_gem_wait.o \ gem/i915_gemfs.o i915-y += \ - $(gem-y) \ - i915_active.o \ - i915_cmd_parser.o \ - i915_deps.o \ - i915_gem_evict.o \ - i915_gem_gtt.o \ - i915_gem_ww.o \ - i915_gem.o \ - i915_query.o \ - i915_request.o \ - i915_scheduler.o \ - i915_trace_points.o \ - i915_ttm_buddy_manager.o \ - i915_vma.o \ - i915_vma_resource.o + $(gem-y) \ + i915_active.o \ + i915_cmd_parser.o \ + i915_deps.o \ + i915_gem.o \ + i915_gem_evict.o \ + i915_gem_gtt.o \ + i915_gem_ww.o \ + i915_query.o \ + i915_request.o \ + i915_scheduler.o \ + i915_trace_points.o \ + i915_ttm_buddy_manager.o \ + i915_vma.o \ + i915_vma_resource.o # general-purpose microcontroller (GuC) support i915-y += \ - gt/uc/intel_gsc_fw.o \ - gt/uc/intel_gsc_proxy.o \ - gt/uc/intel_gsc_uc.o \ - gt/uc/intel_gsc_uc_debugfs.o \ - gt/uc/intel_gsc_uc_heci_cmd_submit.o \ - gt/uc/intel_guc.o \ - gt/uc/intel_guc_ads.o \ - gt/uc/intel_guc_capture.o \ - gt/uc/intel_guc_ct.o \ - gt/uc/intel_guc_debugfs.o \ - gt/uc/intel_guc_fw.o \ - gt/uc/intel_guc_hwconfig.o \ - gt/uc/intel_guc_log.o \ - gt/uc/intel_guc_log_debugfs.o \ - gt/uc/intel_guc_rc.o \ - gt/uc/intel_guc_slpc.o \ - gt/uc/intel_guc_submission.o \ - gt/uc/intel_huc.o \ - gt/uc/intel_huc_debugfs.o \ -
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/dsi: Replace check with a (missing) MIPI sequence name
On Tue, Oct 24, 2023 at 06:57:35PM +0300, Andy Shevchenko wrote: > Names of the MIPI sequence steps are sequential and defined, no > need to check for the gaps. However in seq_name the MIPI_SEQ_END > is missing. Add it there, and drop unneeded NULL check in > sequence_name(). > > Signed-off-by: Andy Shevchenko Reviewed-by: Andi Shyti Andi
