[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: stop checking for NULL vma->obj
== Series Details ==
Series: drm/i915: stop checking for NULL vma->obj
URL : https://patchwork.freedesktop.org/series/101054/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11329_full -> Patchwork_22490_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22490_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@drm_import_export@import-close-race-prime:
- {shard-rkl}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/shard-rkl-4/igt@drm_import_exp...@import-close-race-prime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-rkl-5/igt@drm_import_exp...@import-close-race-prime.html
* igt@gem_ctx_shared@q-smoketest@rcs0:
- {shard-rkl}:[PASS][3] -> ([DMESG-WARN][4], [PASS][5])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/shard-rkl-4/igt@gem_ctx_shared@q-smoket...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-rkl-5/igt@gem_ctx_shared@q-smoket...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-rkl-4/igt@gem_ctx_shared@q-smoket...@rcs0.html
* igt@gem_exec_suspend@basic-s3-devices@smem:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-rkl-5/igt@gem_exec_suspend@basic-s3-devi...@smem.html
* igt@gem_linear_blits@interruptible:
- {shard-dg1}:[PASS][7] -> [TIMEOUT][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/shard-dg1-19/igt@gem_linear_bl...@interruptible.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-dg1-13/igt@gem_linear_bl...@interruptible.html
* igt@i915_module_load@reload-with-fault-injection:
- {shard-dg1}:NOTRUN -> [TIMEOUT][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-dg1-19/igt@i915_module_l...@reload-with-fault-injection.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
- {shard-dg1}:NOTRUN -> [FAIL][10] +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-dg1-19/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
* igt@kms_cursor_crc@pipe-c-cursor-256x85-rapid-movement:
- {shard-dg1}:NOTRUN -> [SKIP][11] +15 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-dg1-19/igt@kms_cursor_...@pipe-c-cursor-256x85-rapid-movement.html
* {igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-25}:
- {shard-rkl}:NOTRUN -> [SKIP][12] +1 similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-rkl-2/igt@kms_plane_scal...@downscale-with-pixel-format-factor-0-25.html
Known issues
Here are the changes found in Patchwork_22490_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][13] ([i915#1839])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-tglb3/igt@feature_discov...@display-4x.html
* igt@gem_ctx_sseu@invalid-args:
- shard-tglb: NOTRUN -> [SKIP][14] ([i915#280])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-tglb3/igt@gem_ctx_s...@invalid-args.html
* igt@gem_eio@in-flight-immediate:
- shard-tglb: [PASS][15] -> [TIMEOUT][16] ([i915#3063])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/shard-tglb2/igt@gem_...@in-flight-immediate.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-tglb3/igt@gem_...@in-flight-immediate.html
* igt@gem_exec_capture@pi@bcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][17] ([i915#4547])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-skl9/igt@gem_exec_capture@p...@bcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2842]) +3 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#2842]) +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/shard-glk7/igt@gem_exec_fair@basic-p...@vcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/shard-glk9/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_params@no-vebox:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109283] / [i915#4877])
[21]:
htt
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709
== Series Details == Series: series starting with [v2,1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709 URL : https://patchwork.freedesktop.org/series/101070/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11330 -> Patchwork_22494 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22494 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22494, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/index.html Participating hosts (47 -> 35) -- Additional (1): fi-glk-dsi Missing(13): fi-kbl-soraka fi-bdw-samus shard-tglu bat-dg1-6 bat-dg1-5 bat-dg2-9 fi-bsw-cyan bat-adlp-6 fi-pnv-d510 bat-rpls-2 shard-dg1 bat-jsl-2 bat-jsl-1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22494: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-tgl-1115g4: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html Warnings * igt@i915_pm_rpm@module-reload: - fi-tgl-1115g4: [INCOMPLETE][3] ([i915#1385]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_22494 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#109315]) +17 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html * igt@core_hotunplug@unbind-rebind: - fi-blb-e6850: [PASS][6] -> [FAIL][7] ([i915#3194]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s0@smem: - fi-glk-dsi: NOTRUN -> [DMESG-WARN][8] ([i915#2943]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html * igt@gem_exec_suspend@basic-s3: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][9] ([i915#4547]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-glk-dsi: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-glk-dsi: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-glk-dsi/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][12] -> [INCOMPLETE][13] ([i915#3921]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-glk-dsi: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-glk-dsi/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][15] -> [DMESG-WARN][16] ([i915#295]) +12 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-glk-dsi: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-glk-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_page_flip: - fi-glk-dsi: NOTRUN -> [SKIP][18] ([fdo#109271]) +30 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22494/fi-glk-dsi/igt@kms_ps
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/gmbus: move some local bus variables within loops
== Series Details ==
Series: series starting with [1/2] drm/i915/gmbus: move some local bus
variables within loops
URL : https://patchwork.freedesktop.org/series/101046/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11327_full -> Patchwork_22487_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22487_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@mock@vma:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-rkl-5/igt@i915_selftest@m...@vma.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-rkl-5/igt@i915_selftest@m...@vma.html
*
{igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-75@pipe-b-edp-1-downscale-with-pixel-format}:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-iclb1/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-b-edp-1-downscale-with-pixel-format.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-iclb2/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-b-edp-1-downscale-with-pixel-format.html
* {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-75}:
- {shard-rkl}:NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-rkl-2/igt@kms_plane_scal...@planes-upscale-factor-0-25-downscale-factor-0-75.html
Known issues
Here are the changes found in Patchwork_22487_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][6] ([fdo#109314])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#232])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-tglb7/igt@gem_...@unwedge-stress.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-tglb2/igt@gem_...@unwedge-stress.html
* igt@gem_exec_balancer@parallel:
- shard-tglb: NOTRUN -> [DMESG-WARN][9] ([i915#5076])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-tglb8/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-iclb5/igt@gem_exec_balan...@parallel-balancer.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271]) +39 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-glk9/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +3 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_gttfill@engines@rcs0:
- shard-skl: NOTRUN -> ([SKIP][17], [SKIP][18]) ([fdo#109271]) +5
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-skl2/igt@gem_exec_gttfill@engi...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-skl1/igt@gem_exec_gttfill@engi...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-skl6/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@smem-oom:
- shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/shard-kbl7/i
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709
== Series Details == Series: series starting with [v2,1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709 URL : https://patchwork.freedesktop.org/series/101070/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709
== Series Details == Series: series starting with [v2,1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709 URL : https://patchwork.freedesktop.org/series/101070/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1d33c55682a1 drm/i915/dg2: Add preemption changes for Wa_14015141709 -:45: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #45: FILE: drivers/gpu/drm/i915/i915_drv.h:1399: +#define HAS_PERCTX_PREEMPT_CTRL(i915) \ + ((GRAPHICS_VER(i915) >= 9) && GRAPHICS_VER_FULL(i915) < IP_VER(12, 55)) total: 0 errors, 0 warnings, 1 checks, 17 lines checked 50c227eb227b drm/i915/dg2: Add debugfs to control global preemption setting
[Intel-gfx] [PATCH v2 2/2] drm/i915/dg2: Add debugfs to control global preemption setting
From: Akeem G Abodunrin
Since DG2 and beyond only support global preemption enable/disable (see
Wa_14015141709), userspace no longer has a way to control preemption on
a per-context basis. Preemption is globally enabled by default, but the
UMD teams have requested that we provide a debugfs interface that can be
used to query and adjust the system-wide preemption setting for
development and bug reporting purposes.
v2 (MattR):
- Split debugfs out into a separate patch. (Jani)
- Add the hardware update/query as facilities in intel_gt.c and just
call them from the debugfs code. (Jani)
- Add register to GuC's save/restore list so that the value will
persist across resets. (Tvrtko)
- Place under per-GT debugfs rather than i915 debugfs. (MattR)
- Only register debugfs entries on platforms subject to Wa_14015141709,
and only on platforms that have an RCS engine. (MattR/Tvrtko)
Cc: Matt Roper
Cc: Prathap Kumar Valsan
Cc: John Harrison
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Tvrtko Ursulin
Signed-off-by: Akeem G Abodunrin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 50 ++
drivers/gpu/drm/i915/gt/intel_gt.h | 3 ++
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c | 31 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h| 3 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 +++
5 files changed, 94 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8a2483ccbfb9..90bdebd8d267 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1045,3 +1045,53 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
mutex_unlock(>->tlb_invalidate_lock);
}
+
+/**
+ * intel_gt_get_global_preemption - return whether the global preemption
+ * setting is enabled in hardware
+ * @gt: GT structure
+ *
+ * Returns the hardware's global 'preemption enabled' setting. Only relevant
+ * on newer platforms that lack per-context preemption control (and only on
+ * GTs that have a render engine).
+ *
+ * Returns 1 if preemption is enabled, 0 if disabled.
+ */
+u64 intel_gt_get_global_preemption(struct intel_gt *gt)
+{
+ intel_wakeref_t wakeref;
+ u32 val;
+
+ drm_WARN_ON(>->i915->drm, GRAPHICS_VER_FULL(gt->i915) < IP_VER(12,
55));
+ drm_WARN_ON(>->i915->drm, RCS_MASK(gt) == 0);
+
+ with_intel_runtime_pm(>->i915->runtime_pm, wakeref)
+ val = intel_uncore_read(gt->uncore,
GEN12_VFG_PREEMPTION_CHICKEN);
+
+ return !(val & GEN12_VFG_PREEMPT_CHICKEN_DISABLE);
+}
+
+/**
+ * intel_gt_set_global_preemption - adjust global preemption enabled setting
+ * @gt: GT structure
+ * @val: desired preemption setting
+ *
+ * Enables global preemption if @val is non-zero, otherwise disables it. Only
+ * relevant on newer platforms that lack per-context preemption control (and
+ * only on GTs that have a render engine).
+ *
+ * Returns 1 if preemption is enabled, 0 if disabled.
+ */
+void intel_gt_set_global_preemption(struct intel_gt *gt, u64 val)
+{
+ intel_wakeref_t wakeref;
+ u32 tmp = val ?
+ _MASKED_BIT_DISABLE(GEN12_VFG_PREEMPT_CHICKEN_DISABLE) :
+ _MASKED_BIT_ENABLE(GEN12_VFG_PREEMPT_CHICKEN_DISABLE);
+
+ drm_WARN_ON(>->i915->drm, GRAPHICS_VER_FULL(gt->i915) < IP_VER(12,
55));
+ drm_WARN_ON(>->i915->drm, RCS_MASK(gt) == 0);
+
+ with_intel_runtime_pm(>->i915->runtime_pm, wakeref)
+ intel_uncore_write(gt->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
tmp);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 0f571c8ee22b..63a599a1bf6d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -94,4 +94,7 @@ void intel_gt_watchdog_work(struct work_struct *work);
void intel_gt_invalidate_tlbs(struct intel_gt *gt);
+u64 intel_gt_get_global_preemption(struct intel_gt *gt);
+void intel_gt_set_global_preemption(struct intel_gt *gt, u64 val);
+
#endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index f103664b71d4..d851e3f80877 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -6,6 +6,7 @@
#include
#include "i915_drv.h"
+#include "intel_gt.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
#include "intel_gt_pm_debugfs.h"
@@ -57,13 +58,43 @@ static int __intel_gt_debugfs_reset_store(void *data, u64
val)
DEFINE_SIMPLE_ATTRIBUTE(reset_fops, __intel_gt_debugfs_reset_show,
__intel_gt_debugfs_reset_store, "%llu\n");
+static int i915_global_preemption_enabled_get(void *data, u64 *val)
+{
+ *val = intel_gt_get_global_preemption((struct intel_gt *)data);
+
+ return 0;
+}
+
+static int i915_global_preemption_enabled_set
[Intel-gfx] [PATCH v2 1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709
From: Akeem G Abodunrin
Starting with DG2, preemption can no longer be controlled using userspace
on a per-context basis. Instead, the hardware only allows us to enable or
disable preemption in a global, system-wide basis. Also, we lose the
ability to specify the preemption granularity (such as batch-level vs
command-level vs object-level).
v2 (MattR):
- Move debugfs interface to a separate patch. (Jani)
Cc: Matt Roper
Cc: Prathap Kumar Valsan
Cc: John Harrison
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Tvrtko Ursulin
Signed-off-by: Akeem G Abodunrin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index beca8735bae5..f695a9c96c8d 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2310,7 +2310,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
FF_DOP_CLOCK_GATE_DISABLE);
}
- if (IS_GRAPHICS_VER(i915, 9, 12)) {
+ if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
/*
FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
wa_masked_en(wal,
GEN7_FF_SLICE_CS_CHICKEN1,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 943267393ecb..afefb3bd2714 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1396,6 +1396,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GUC_DEPRIVILEGE(dev_priv) \
(INTEL_INFO(dev_priv)->has_guc_deprivilege)
+#define HAS_PERCTX_PREEMPT_CTRL(i915) \
+ ((GRAPHICS_VER(i915) >= 9) && GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
+
static inline bool run_as_guest(void)
{
return !hypervisor_is_type(X86_HYPER_NATIVE);
--
2.34.1
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
URL : https://patchwork.freedesktop.org/series/101045/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11327_full -> Patchwork_22486_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22486_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_fence@syncobj-timeline-invalid-wait:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-rkl-1/igt@gem_exec_fe...@syncobj-timeline-invalid-wait.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-rkl-5/igt@gem_exec_fe...@syncobj-timeline-invalid-wait.html
*
{igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-rkl-6/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html
Known issues
Here are the changes found in Patchwork_22486_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#232])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-tglb7/igt@gem_...@unwedge-stress.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-tglb5/igt@gem_...@unwedge-stress.html
* igt@gem_exec_balancer@parallel:
- shard-tglb: NOTRUN -> [DMESG-WARN][6] ([i915#5076])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-tglb3/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#4525])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-iclb6/igt@gem_exec_balan...@parallel-balancer.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +39 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-glk2/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar
issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_whisper@basic-queues-all:
- shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-glk5/igt@gem_exec_whis...@basic-queues-all.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-glk8/igt@gem_exec_whis...@basic-queues-all.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-kbl3/igt@gem_lmem_swapp...@heavy-verify-random.html
- shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-skl10/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_pwrite@basic-exhaustion:
- shard-kbl: NOTRUN -> [WARN][18] ([i915#2658])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-kbl1/igt@gem_pwr...@basic-exhaustion.html
* igt@i915_selftest@live@gt_pm:
- shard-skl: NOTRUN -> [DMESG-FAIL][19] ([i915#1886])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/shard-skl1/igt@i915_selftest@live@gt_pm.html
* igt@i915_suspend@forcewake:
- shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/shard-kbl6/igt@i915_susp...@forcewake.html
[21]:
https://
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add CDCLK checks to atomic check phase
== Series Details ==
Series: Add CDCLK checks to atomic check phase
URL : https://patchwork.freedesktop.org/series/101068/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/display/intel_cdclk.o
drivers/gpu/drm/i915/display/intel_cdclk.c: In function ‘bxt_set_cdclk’:
drivers/gpu/drm/i915/display/intel_cdclk.c:1719:14: error: assignment to
‘struct cdclk_steps *’ from incompatible pointer type ‘struct cdclk_step *’
[-Werror=incompatible-pointer-types]
cdclk_steps = new_cdclk_state->steps;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1743:22: error: invalid use of
undefined type ‘struct cdclk_steps’
switch (cdclk_steps[i].action) {
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1743:22: error: dereferencing
pointer to incomplete type ‘struct cdclk_steps’
drivers/gpu/drm/i915/display/intel_cdclk.c:1767:59: error: invalid use of
undefined type ‘struct cdclk_steps’
waveform = cdclk_squash_waveform(dev_priv, cdclk_steps[i].cdclk);
^
In file included from ./arch/x86/include/asm/bug.h:86,
from ./include/linux/bug.h:5,
from ./include/linux/cpumask.h:14,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:22,
from ./arch/x86/include/asm/timex.h:5,
from ./include/linux/timex.h:65,
from ./include/linux/time32.h:13,
from ./include/linux/time.h:60,
from drivers/gpu/drm/i915/display/intel_cdclk.c:24:
drivers/gpu/drm/i915/display/intel_cdclk.c:1776:28: error: invalid use of
undefined type ‘struct cdclk_steps’
MISSING_CASE(cdclk_steps[i].action);
^
./include/asm-generic/bug.h:99:17: note: in definition of macro ‘__WARN_printf’
__warn_printk(arg); \
^~~
./drivers/gpu/drm/i915/i915_utils.h:41:25: note: in expansion of macro ‘WARN’
#define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \
^~~~
drivers/gpu/drm/i915/display/intel_cdclk.c:1776:4: note: in expansion of macro
‘MISSING_CASE’
MISSING_CASE(cdclk_steps[i].action);
^~~~
drivers/gpu/drm/i915/display/intel_cdclk.c: In function ‘intel_cdclk_can_crawl’:
drivers/gpu/drm/i915/display/intel_cdclk.c:1973:41: error: initialization of
‘struct cdclk_steps *’ from incompatible pointer type ‘struct cdclk_step *’
[-Werror=incompatible-pointer-types]
struct cdclk_steps *cdclk_transition = b->steps;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1985:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[0].action = INTEL_CDCLK_CRAWL;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1985:18: error: dereferencing
pointer to incomplete type ‘struct cdclk_steps’
drivers/gpu/drm/i915/display/intel_cdclk.c:1986:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[0].cdclk = b->actual.cdclk;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1987:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[1].action = INTEL_CDCLK_NOOP;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:1988:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[1].cdclk = b->actual.cdclk;
^
drivers/gpu/drm/i915/display/intel_cdclk.c: In function ‘intel_cdclk_squash’:
drivers/gpu/drm/i915/display/intel_cdclk.c:2001:41: error: initialization of
‘struct cdclk_steps *’ from incompatible pointer type ‘struct cdclk_step *’
[-Werror=incompatible-pointer-types]
struct cdclk_steps *cdclk_transition = b->steps;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:2011:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[0].action = INTEL_CDCLK_SQUASH;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:2011:18: error: dereferencing
pointer to incomplete type ‘struct cdclk_steps’
drivers/gpu/drm/i915/display/intel_cdclk.c:2012:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[0].cdclk = b->actual.cdclk;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:2013:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[1].action = INTEL_CDCLK_NOOP;
^
drivers/gpu/drm/i915/display/intel_cdclk.c:2014:18: error: invalid use of
undefined type ‘struct cdclk_steps’
cdclk_transition[1].cdclk = b->actual.cdclk;
^
drivers/gpu/drm/i915/display/intel_cdclk.c: In function
‘intel_cdclk_needs_modeset’:
drivers/gpu/drm/i915/display/intel_cdclk.c:2042:19: error: assignme
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: avoid concurrent writes to aux_inv (rev5)
== Series Details == Series: drm/i915: avoid concurrent writes to aux_inv (rev5) URL : https://patchwork.freedesktop.org/series/100772/ State : success == Summary == CI Bug Log - changes from CI_DRM_11330 -> Patchwork_22492 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22492/index.html Participating hosts (46 -> 41) -- Additional (1): fi-glk-dsi Missing(6): fi-kbl-soraka shard-tglu fi-bsw-cyan fi-icl-u2 fi-pnv-d510 fi-bdw-samus Changes --- No changes found Build changes - * IGT: IGT_6364 -> None * Linux: CI_DRM_11330 -> Patchwork_22492 CI-20190529: 20190529 CI_DRM_11330: 68d8cd94c6eaa94aa6bae2e92efbd488523a1a1b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6364: 3523fe577bc22e6512a8de7e60175c8f46cf61d2 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22492: eb286fbe8a6ed532c821b6da358f0b1fa8af7291 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == eb286fbe8a6e drm/i915: avoid concurrent writes to aux_inv == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22492/index.html
[Intel-gfx] [PATCH 5/5] drm/i915/display: Add cdclk checks to atomic check
Checking cdclk conditions during atomic check and preparing
for commit phase so we can have atomic commit as simple
as possible. Add the specific steps to be taken during
cdclk changes, prepare for squashing, crawling and modeset
scenarios.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 111 ++---
1 file changed, 77 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 2278b052d859..3475bfd85f3c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1700,12 +1700,23 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
{
+ struct intel_atomic_state *state;
+ struct intel_cdclk_state *new_cdclk_state;
+ struct cdclk_steps *cdclk_steps;
+ struct intel_cdclk_state *cdclk_state;
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
+ u32 squash_ctl = 0;
u32 val;
u16 waveform;
int clock;
int ret;
+ int i;
+
+ cdclk_state = to_intel_cdclk_state(dev_priv->cdclk.obj.state);
+ state = cdclk_state->base.state;
+ new_cdclk_state = intel_atomic_get_new_cdclk_state(state);
+ cdclk_steps = new_cdclk_state->steps;
/* Inform power controller of upcoming frequency change. */
if (DISPLAY_VER(dev_priv) >= 11)
@@ -1728,45 +1739,48 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->cdclk.hw.vco > 0 && vco > 0)
{
- if (dev_priv->cdclk.hw.vco != vco)
+ for (i = 0; i < MAX_CDCLK_ACTIONS; i++) {
+ switch (cdclk_steps[i].action) {
+ case INTEL_CDCLK_MODESET:
+ if (DISPLAY_VER(dev_priv) >= 11) {
+ if (dev_priv->cdclk.hw.vco != 0 &&
+ dev_priv->cdclk.hw.vco != vco)
+ icl_cdclk_pll_disable(dev_priv);
+
+ if (dev_priv->cdclk.hw.vco != vco)
+ icl_cdclk_pll_enable(dev_priv, vco);
+ } else {
+ if (dev_priv->cdclk.hw.vco != 0 &&
+ dev_priv->cdclk.hw.vco != vco)
+ bxt_de_pll_disable(dev_priv);
+
+ if (dev_priv->cdclk.hw.vco != vco)
+ bxt_de_pll_enable(dev_priv, vco);
+ }
+ clock = cdclk;
+ break;
+ case INTEL_CDCLK_CRAWL:
adlp_cdclk_pll_crawl(dev_priv, vco);
- } else if (DISPLAY_VER(dev_priv) >= 11) {
- if (dev_priv->cdclk.hw.vco != 0 &&
- dev_priv->cdclk.hw.vco != vco)
- icl_cdclk_pll_disable(dev_priv);
-
- if (dev_priv->cdclk.hw.vco != vco)
- icl_cdclk_pll_enable(dev_priv, vco);
- } else {
- if (dev_priv->cdclk.hw.vco != 0 &&
- dev_priv->cdclk.hw.vco != vco)
- bxt_de_pll_disable(dev_priv);
-
- if (dev_priv->cdclk.hw.vco != vco)
- bxt_de_pll_enable(dev_priv, vco);
- }
-
- waveform = cdclk_squash_waveform(dev_priv, cdclk);
-
- if (waveform)
- clock = vco / 2;
- else
- clock = cdclk;
-
- if (has_cdclk_squasher(dev_priv)) {
- u32 squash_ctl = 0;
-
- if (waveform)
+ clock = cdclk;
+ break;
+ case INTEL_CDCLK_SQUASH:
+ waveform = cdclk_squash_waveform(dev_priv,
cdclk_steps[i].cdclk);
+ clock = vco / 2;
squash_ctl = CDCLK_SQUASH_ENABLE |
- CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
-
- intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
+ CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
+ intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
+ break;
+ case INTEL_CDCLK_NOOP:
+ break;
+ default:
+ MISSING_CASE(cdclk_steps[i].action);
+ break;
+ }
}
val = bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) |
- bxt_cdclk_cd2x_pipe(dev_priv, pipe) |
- skl_cdclk_decimal(cdclk);
+ bxt_cdclk_cd2x_pipe(dev_priv, pipe) |
+ skl_cdclk_decimal(cdclk);
/*
* Disable SSA Precharge w
[Intel-gfx] [PATCH 4/5] drm/i915/display: Add drm_i915_private to intel_cdclk_needs_modeset()
The change is to be able to have access to the in-flight state.
Changing this one functions, trickles the change to
intel_cdclk_changed()
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 22 ++-
drivers/gpu/drm/i915/display/intel_cdclk.h| 3 ++-
.../drm/i915/display/intel_display_power.c| 2 +-
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 840d611197cf..2278b052d859 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2003,7 +2003,8 @@ static bool intel_cdclk_squash(struct drm_i915_private
*dev_priv,
* True if changing between the two CDCLK configurations
* requires all pipes to be off, false if not.
*/
-bool intel_cdclk_needs_modeset(const struct intel_cdclk_config *a,
+bool intel_cdclk_needs_modeset(struct drm_i915_private *i915,
+ const struct intel_cdclk_config *a,
const struct intel_cdclk_config *b)
{
return a->cdclk != b->cdclk ||
@@ -2053,10 +2054,11 @@ static bool intel_cdclk_can_cd2x_update(struct
drm_i915_private *dev_priv,
* Returns:
* True if the CDCLK configurations don't match, false if they do.
*/
-static bool intel_cdclk_changed(const struct intel_cdclk_config *a,
+static bool intel_cdclk_changed(struct drm_i915_private *i915,
+ const struct intel_cdclk_config *a,
const struct intel_cdclk_config *b)
{
- return intel_cdclk_needs_modeset(a, b) ||
+ return intel_cdclk_needs_modeset(i915, a, b) ||
a->voltage_level != b->voltage_level;
}
@@ -2085,7 +2087,7 @@ static void intel_set_cdclk(struct drm_i915_private
*dev_priv,
{
struct intel_encoder *encoder;
- if (!intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_config))
+ if (!intel_cdclk_changed(dev_priv, &dev_priv->cdclk.hw, cdclk_config))
return;
if (drm_WARN_ON_ONCE(&dev_priv->drm, !dev_priv->cdclk_funcs->set_cdclk))
@@ -2132,7 +2134,7 @@ static void intel_set_cdclk(struct drm_i915_private
*dev_priv,
intel_audio_cdclk_change_post(dev_priv);
if (drm_WARN(&dev_priv->drm,
-intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_config),
+intel_cdclk_changed(dev_priv, &dev_priv->cdclk.hw,
cdclk_config),
"cdclk state doesn't match!\n")) {
intel_cdclk_dump_config(dev_priv, &dev_priv->cdclk.hw, "[hw
state]");
intel_cdclk_dump_config(dev_priv, cdclk_config, "[sw state]");
@@ -2156,7 +2158,7 @@ intel_set_cdclk_pre_plane_update(struct
intel_atomic_state *state)
intel_atomic_get_new_cdclk_state(state);
enum pipe pipe = new_cdclk_state->pipe;
- if (!intel_cdclk_changed(&old_cdclk_state->actual,
+ if (!intel_cdclk_changed(dev_priv, &old_cdclk_state->actual,
&new_cdclk_state->actual))
return;
@@ -2185,7 +2187,7 @@ intel_set_cdclk_post_plane_update(struct
intel_atomic_state *state)
intel_atomic_get_new_cdclk_state(state);
enum pipe pipe = new_cdclk_state->pipe;
- if (!intel_cdclk_changed(&old_cdclk_state->actual,
+ if (!intel_cdclk_changed(dev_priv, &old_cdclk_state->actual,
&new_cdclk_state->actual))
return;
@@ -2739,7 +2741,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
*state)
if (ret)
return ret;
- if (intel_cdclk_changed(&old_cdclk_state->actual,
+ if (intel_cdclk_changed(dev_priv, &old_cdclk_state->actual,
&new_cdclk_state->actual)) {
/*
* Also serialize commits across all crtcs
@@ -2750,7 +2752,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
*state)
return ret;
} else if (old_cdclk_state->active_pipes !=
new_cdclk_state->active_pipes ||
old_cdclk_state->force_min_cdclk !=
new_cdclk_state->force_min_cdclk ||
- intel_cdclk_changed(&old_cdclk_state->logical,
+ intel_cdclk_changed(dev_priv, &old_cdclk_state->logical,
&new_cdclk_state->logical)) {
ret = intel_atomic_lock_global_state(&new_cdclk_state->base);
if (ret)
@@ -2793,7 +2795,7 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
*state)
drm_dbg_kms(&dev_priv->drm,
"Can change cdclk cd2x divider with pipe %c
active\n",
pipe_name(pipe));
- } else if (intel_cdclk_needs_modeset(&old_cdclk_state->actual,
+ } else if (intel_cdclk_needs_modeset(dev_priv, &old_cdclk_state->actual,
[Intel-gfx] [PATCH 3/5] drm/i915/display: s/intel_cdclk_can_crawl/intel_cdclk_crawl
Apart from checking if crawling can be performed,
accommodate accessing in-flight cdclk state for any changes
that are needed during commit phase.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 1f879af15d87..840d611197cf 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1952,8 +1952,8 @@ void intel_cdclk_uninit_hw(struct drm_i915_private *i915)
}
static bool intel_cdclk_can_crawl(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_config *a,
- const struct intel_cdclk_config *b)
+ const struct intel_cdclk_state *a,
+ struct intel_cdclk_state *b)
{
int a_div, b_div;
@@ -1964,13 +1964,13 @@ static bool intel_cdclk_can_crawl(struct
drm_i915_private *dev_priv,
* The vco and cd2x divider will change independently
* from each, so we disallow cd2x change when crawling.
*/
- a_div = DIV_ROUND_CLOSEST(a->vco, a->cdclk);
- b_div = DIV_ROUND_CLOSEST(b->vco, b->cdclk);
+ a_div = DIV_ROUND_CLOSEST(a->actual.vco, a->actual.cdclk);
+ b_div = DIV_ROUND_CLOSEST(b->actual.vco, b->actual.cdclk);
- return a->vco != 0 && b->vco != 0 &&
- a->vco != b->vco &&
+ return a->actual.vco != 0 && b->actual.vco != 0 &&
+ a->actual.vco != b->actual.vco &&
a_div == b_div &&
- a->ref == b->ref;
+ a->actual.ref == b->actual.ref;
}
static bool intel_cdclk_squash(struct drm_i915_private *dev_priv,
@@ -2783,8 +2783,8 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
*state)
drm_dbg_kms(&dev_priv->drm,
"Can change cdclk via squasher\n");
} else if (intel_cdclk_can_crawl(dev_priv,
-&old_cdclk_state->actual,
-&new_cdclk_state->actual)) {
+old_cdclk_state,
+new_cdclk_state)) {
drm_dbg_kms(&dev_priv->drm,
"Can change cdclk via crawl\n");
} else if (pipe != INVALID_PIPE) {
--
2.25.1
[Intel-gfx] [PATCH 2/5] drm/i915/display: s/intel_cdclk_can_squash/intel_cdclk_squash
Apart from checking if squashing can be performed,
accommodate accessing in-flight cdclk state for any changes
that are needed during commit phase.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index fda8b701..1f879af15d87 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1973,10 +1973,11 @@ static bool intel_cdclk_can_crawl(struct
drm_i915_private *dev_priv,
a->ref == b->ref;
}
-static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_config *a,
- const struct intel_cdclk_config *b)
+static bool intel_cdclk_squash(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_state *a,
+ struct intel_cdclk_state *b)
{
+
/*
* FIXME should store a bit more state in intel_cdclk_config
* to differentiate squasher vs. cd2x divider properly. For
@@ -1986,10 +1987,10 @@ static bool intel_cdclk_can_squash(struct
drm_i915_private *dev_priv,
if (!has_cdclk_squasher(dev_priv))
return false;
- return a->cdclk != b->cdclk &&
- a->vco != 0 &&
- a->vco == b->vco &&
- a->ref == b->ref;
+ return a->actual.cdclk != b->actual.cdclk &&
+ a->actual.vco != 0 &&
+ a->actual.vco == b->actual.vco &&
+ a->actual.ref == b->actual.ref;
}
/**
@@ -2776,9 +2777,9 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
*state)
pipe = INVALID_PIPE;
}
- if (intel_cdclk_can_squash(dev_priv,
- &old_cdclk_state->actual,
- &new_cdclk_state->actual)) {
+ if (intel_cdclk_squash(dev_priv,
+ old_cdclk_state,
+ new_cdclk_state)) {
drm_dbg_kms(&dev_priv->drm,
"Can change cdclk via squasher\n");
} else if (intel_cdclk_can_crawl(dev_priv,
--
2.25.1
[Intel-gfx] [PATCH 1/5] drm/i915/display: Add CDCLK actions to intel_cdclk_state
This is a prep patch for what the rest of the series does.
Add existing actions that change cdclk - squash, crawl, modeset to
intel_cdclk_state so we have access to the cdclk values
that are in transition.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
b/drivers/gpu/drm/i915/display/intel_cdclk.h
index df66f66fbad0..06d7f9f0b253 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -15,6 +15,14 @@ struct drm_i915_private;
struct intel_atomic_state;
struct intel_crtc_state;
+enum cdclk_actions {
+ INTEL_CDCLK_MODESET = 0,
+ INTEL_CDCLK_SQUASH,
+ INTEL_CDCLK_CRAWL,
+ INTEL_CDCLK_NOOP,
+ MAX_CDCLK_ACTIONS
+};
+
struct intel_cdclk_config {
unsigned int cdclk, vco, ref, bypass;
u8 voltage_level;
@@ -49,6 +57,11 @@ struct intel_cdclk_state {
/* bitmask of active pipes */
u8 active_pipes;
+
+ struct cdclk_step {
+ enum cdclk_actions action;
+ u32 cdclk;
+ } steps[MAX_CDCLK_ACTIONS];
};
int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state);
--
2.25.1
[Intel-gfx] [PATCH 0/5] Add CDCLK checks to atomic check phase
This version splits the original patch into simpler units. The intention is to check for squashing, crawling conditions at atomic check phase and prepare for commit phase. This basically means the in-flight cdclk state is available. intel_cdclk_can_squash(), intel_cdclk_can_crawl() and intel_cdclk_needs_modeset() have changes to accommodate this. Cc: Stanislav Lisovskiy Anusha Srivatsa (5): drm/i915/display: Add CDCLK actions to intel_cdclk_state drm/i915/display: s/intel_cdclk_can_squash/intel_cdclk_squash drm/i915/display: s/intel_cdclk_can_crawl/intel_cdclk_crawl drm/i915/display: Add drm_i915_private to intel_cdclk_needs_modeset() drm/i915/display: Add cdclk checks to atomic check drivers/gpu/drm/i915/display/intel_cdclk.c| 172 +++--- drivers/gpu/drm/i915/display/intel_cdclk.h| 16 +- .../drm/i915/display/intel_display_power.c| 2 +- 3 files changed, 125 insertions(+), 65 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add preemption changes for Wa_14015141709
On Fri, Mar 04, 2022 at 12:13:12PM +0200, Jani Nikula wrote:
> On Thu, 03 Mar 2022, Matt Roper wrote:
> > From: Akeem G Abodunrin
> >
> > Starting with DG2, preemption can no longer be controlled using userspace
> > on a per-context basis. Instead, the hardware only allows us to enable or
> > disable preemption in a global, system-wide basis. Also, we lose the
> > ability to specify the preemption granularity (such as batch-level vs
> > command-level vs object-level).
> >
> > As a result of this - for debugging purposes, this patch adds debugfs
> > interface to configure (disable/enable) preemption globally.
> >
> > Jira: VLK-27831
>
> Please remove internal Jira references.
>
> > Cc: Matt Roper
> > Cc: Prathap Kumar Valsan
> > Cc: John Harrison
> > Cc: Joonas Lahtinen
> > Signed-off-by: Akeem G Abodunrin
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 50 +
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > 4 files changed, 57 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 19cd34f24263..21ede1887b9f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -468,6 +468,9 @@
> > #define VF_PREEMPTION _MMIO(0x83a4)
> > #define PREEMPTION_VERTEX_COUNT REG_GENMASK(15, 0)
> >
> > +#define GEN12_VFG_PREEMPTION_CHICKEN _MMIO(0x83b4)
> > +#define GEN12_VFG_PREEMPT_CHICKEN_DISABLEREG_BIT(8)
> > +
> > #define GEN8_RC6_CTX_INFO _MMIO(0x8504)
> >
> > #define GEN12_SQCM _MMIO(0x8724)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index c014b40d2e9f..18dc82f29776 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -2310,7 +2310,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> > struct i915_wa_list *wal)
> > FF_DOP_CLOCK_GATE_DISABLE);
> > }
> >
> > - if (IS_GRAPHICS_VER(i915, 9, 12)) {
> > + if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
>
> Adding HAS_PERCTX_PREEMPT_CTRL(i915) and using it is a separate change
> from the debugfs. Please split it up.
>
> > /*
> > FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
> > wa_masked_en(wal,
> > GEN7_FF_SLICE_CS_CHICKEN1,
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 747fe9f41e1f..40e6e17e2950 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -571,6 +571,55 @@ static int i915_wa_registers(struct seq_file *m, void
> > *unused)
> > return 0;
> > }
> >
> > +static void i915_global_preemption_config(struct drm_i915_private *i915,
> > + u32 val)
> > +{
> > + const u32 bit = GEN12_VFG_PREEMPT_CHICKEN_DISABLE;
>
> We rarely use const for locals, and usually only if the function is big.
>
> I'd probably use:
>
> u32 tmp = val ?
> _MASKED_BIT_DISABLE(GEN12_VFG_PREEMPT_CHICKEN_DISABLE) :
> _MASKED_BIT_ENABLE(GEN12_VFG_PREEMPT_CHICKEN_DISABLE);
>
> To have just one intel_uncore_write().
>
> > +
> > + if (val)
> > + intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
> > + _MASKED_BIT_DISABLE(bit));
> > + else
> > + intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
> > + _MASKED_BIT_ENABLE(bit));
>
> We really shouldn't be adding new direct low-level register access in
> i915_debugfs.c.
>
> Please define an interface for this and add the functionality to a
> suitable place, and then call the functions from here.
>
> > +}
> > +
> > +static int i915_global_preempt_support_get(void *data, u64 *val)
> > +{
> > + struct drm_i915_private *i915 = data;
> > + intel_wakeref_t wakeref;
> > + u32 curr_status = 0;
> > +
> > + if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
> > + return -EINVAL;
> > +
> > + with_intel_runtime_pm(&i915->runtime_pm, wakeref)
> > + curr_status = intel_uncore_read(&i915->uncore,
> > + GEN12_VFG_PREEMPTION_CHICKEN);
> > + *val = (curr_status & GEN12_VFG_PREEMPT_CHICKEN_DISABLE) ? 0 : 1;
> > +
> > + return 0;
> > +}
> > +
> > +static int i915_global_preempt_support_set(void *data, u64 val)
> > +{
> > + struct drm_i915_private *i915 = data;
> > + intel_wakeref_t wakeref;
> > +
> > + if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
> > + return -EINVAL;
> >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: avoid concurrent writes to aux_inv (rev5)
== Series Details == Series: drm/i915: avoid concurrent writes to aux_inv (rev5) URL : https://patchwork.freedesktop.org/series/100772/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: avoid concurrent writes to aux_inv (rev5)
== Series Details == Series: drm/i915: avoid concurrent writes to aux_inv (rev5) URL : https://patchwork.freedesktop.org/series/100772/ State : warning == Summary == $ dim checkpatch origin/drm-tip eb286fbe8a6e drm/i915: avoid concurrent writes to aux_inv -:198: CHECK:BRACES: Unbalanced braces around else statement #198: FILE: drivers/gpu/drm/i915/gt/gen8_engine_cs.c:323: + } else total: 0 errors, 0 warnings, 1 checks, 213 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: rework the error handling in *_dpll_params
== Series Details == Series: drm/i915: rework the error handling in *_dpll_params URL : https://patchwork.freedesktop.org/series/101062/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11330 -> Patchwork_22491 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22491 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22491, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/index.html Participating hosts (45 -> 43) -- Additional (1): fi-glk-dsi Missing(3): fi-bsw-cyan fi-bdw-samus fi-kbl-8809g Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22491: ### IGT changes ### Possible regressions * igt@i915_module_load@reload: - fi-tgl-1115g4: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-tgl-1115g4/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-tgl-1115g4/igt@i915_module_l...@reload.html Warnings * igt@i915_pm_rpm@module-reload: - fi-tgl-1115g4: [INCOMPLETE][3] ([i915#1385]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_22491 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271]) +21 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html - fi-glk-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-glk-dsi: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-glk-dsi/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][10] -> [INCOMPLETE][11] ([i915#3921]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-glk-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-glk-dsi/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-glk-dsi: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-glk-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_page_flip: - fi-glk-dsi: NOTRUN -> [SKIP][16] ([fdo#109271]) +30 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-glk-dsi/igt@kms_psr@primary_page_flip.html Possible fixes * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [INCOMPLETE][17] ([i915#4547]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11330/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22491/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@i915_pm_rps@basic-api: - bat-dg1-
[Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With this patch, auxiliary table invalidation is done only for the
engine executing the request. And the mmio address for the aux_inv
register is set after the engine instance becomes certain.
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 9 +++
drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 9 +++
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 61 ---
.../drm/i915/gt/intel_execlists_submission.c | 35 +++
drivers/gpu/drm/i915/i915_request.h | 2 +
5 files changed, 82 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 1c82caf525c3..0ec4986e4805 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen2 */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -123,6 +126,9 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen4 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -138,6 +144,9 @@ int gen4_emit_flush_vcs(struct i915_request *rq, u32 mode)
*cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen4 vcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
index 5e65550b4dfb..efe51c4662fe 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -137,6 +137,9 @@ int gen6_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen6 */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -208,6 +211,9 @@ static int mi_flush_dw(struct i915_request *rq, u32 flags)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen6 */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -347,6 +353,9 @@ int gen7_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen7 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index b1b9c3fd7bf9..b6374cf53314 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -73,6 +73,9 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen8 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -106,6 +109,9 @@ int gen8_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* value */
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen8 xcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -157,6 +163,9 @@ int gen11_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
}
+ /* hsdes: 1809175790. No fixup needed for gen11 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -165,30 +174,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
-{
- static const i915_reg_t vd[] = {
- GEN12_VD0_AUX_NV,
- GEN12_VD1_AUX_NV,
- GEN12_VD2_AUX_NV,
- GEN12_VD3_AUX_NV,
- };
-
- static const i915_reg_t ve[] = {
- GEN12_VE0_AUX_NV,
- GEN12_VE1_AUX_NV,
- };
-
- if (engine->class == VIDEO_DECODE_CLASS)
- return vd[engine->instance];
-
- if (engine->class == VIDEO_ENHANCEMENT_CLASS)
- return ve[engine->instance];
-
- GEM_BUG_ON("unknown aux_inv reg\n");
- return INVALID_MMIO_REG;
-}
-
static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
@@ -274,6 +259,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
[Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With this patch, auxiliary table invalidation is done only for the
engine executing the request. And the mmio address for the aux_inv
register is set after the engine instance becomes certain.
Signed-off-by: Chris Wilson
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 9 +++
drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 9 +++
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 61 ---
.../drm/i915/gt/intel_execlists_submission.c | 35 +++
drivers/gpu/drm/i915/i915_request.h | 2 +
5 files changed, 82 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 1c82caf525c3..0ec4986e4805 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen2 */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -123,6 +126,9 @@ int gen4_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen4 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -138,6 +144,9 @@ int gen4_emit_flush_vcs(struct i915_request *rq, u32 mode)
*cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen4 vcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
index 5e65550b4dfb..aceb571c8212 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -137,6 +137,9 @@ int gen6_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen6 */
+rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -208,6 +211,9 @@ static int mi_flush_dw(struct i915_request *rq, u32 flags)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen6 */
+rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -347,6 +353,9 @@ int gen7_emit_flush_rcs(struct i915_request *rq, u32 mode)
*cs++ = 0;
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen7 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index b1b9c3fd7bf9..b6374cf53314 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -73,6 +73,9 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen8 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -106,6 +109,9 @@ int gen8_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* value */
intel_ring_advance(rq, cs);
+ /* hsdes: 1809175790. No fixup needed for gen8 xcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -157,6 +163,9 @@ int gen11_emit_flush_rcs(struct i915_request *rq, u32 mode)
intel_ring_advance(rq, cs);
}
+ /* hsdes: 1809175790. No fixup needed for gen11 rcs */
+ rq->aux_inv_fixup = NULL;
+
return 0;
}
@@ -165,30 +174,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
-{
- static const i915_reg_t vd[] = {
- GEN12_VD0_AUX_NV,
- GEN12_VD1_AUX_NV,
- GEN12_VD2_AUX_NV,
- GEN12_VD3_AUX_NV,
- };
-
- static const i915_reg_t ve[] = {
- GEN12_VE0_AUX_NV,
- GEN12_VE1_AUX_NV,
- };
-
- if (engine->class == VIDEO_DECODE_CLASS)
- return vd[engine->instance];
-
- if (engine->class == VIDEO_ENHANCEMENT_CLASS)
- return ve[engine->instance];
-
- GEM_BUG_ON("unknown aux_inv reg\n");
- return INVALID_MMIO_REG;
-}
-
static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
{
*cs++ = MI_LOAD_REGISTER_IMM(1);
@@ -274,6 +259,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for use dynamic-debug under drm.debug api (rev2)
On Tue, Mar 1, 2022 at 1:57 PM Patchwork
wrote:
>
> == Series Details ==
>
> Series: use dynamic-debug under drm.debug api (rev2)
> URL : https://patchwork.freedesktop.org/series/100289/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> c2ed9cc02d9c dyndbg: fix static_branch manipulation
> a8f6c71f283e dyndbg: add class_id field and query support
> -:141: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible
> side-effects?
> #141: FILE: include/linux/dynamic_debug.h:142:
> +#define __dynamic_func_call_cls(id, cls, fmt, func, ...) do { \
> + DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\
> + if (DYNAMIC_DEBUG_BRANCH(id)) \
> + func(&id, ##__VA_ARGS__); \
> } while (0)
>
> -:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible
> side-effects?
> #151: FILE: include/linux/dynamic_debug.h:148:
> +#define __dynamic_func_call_no_desc_cls(id, cls, fmt, func, ...) do { \
> + DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\
> + if (DYNAMIC_DEBUG_BRANCH(id)) \
> + func(__VA_ARGS__); \
> } while (0)
>
Can I get a pass on this ?
the usual approach doesnt work:
+ typeof(id) id = (id); \
it appears to be due to the outer / wrapping macro inserting the
__UNIQUE_ID(ddebug)
which gets expanded 2x, giving:
| ^~~~
/home/jimc/projects/lx/linux.git/include/linux/compiler-gcc.h:42:45:
note: previous definition of ‘__UNIQUE_ID_ddebug437’ with type ‘int’
42 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_,
prefix), __COUNTER__)
| ^~~~
/home/jimc/projects/lx/linux.git/include/linux/dynamic_debug.h:230:20:
note: in definition of macro ‘__dynamic_func_call_cls’
230 | typeof(id) id = (id); \
Moreover, these 2 macros imitate existing macros,
which would suffer the same WARNING.
My macro-fu is insufficient,
can anyone suggest a clean way to fix this warning ?
tia
Jim
Re: [Intel-gfx] [PATCH] drm/i915: rework the error handling in *_dpll_params
On Fri, Mar 04, 2022 at 11:11:54PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 04, 2022 at 01:03:55PM -0800, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > Clang static analysis reports this issue
> > intel_dpll.c:472:31: warning: The left operand of '-'
> > is a garbage value [core.UndefinedBinaryOperatorResult]
> > this_err = abs(clock.dot - target);
> > ~ ^
> >
> > In a loop clock.dot is set on successful call to
> > i9xx_calc_dpll_params(). If the call fails, the later
> > *is_valid() will use the previous loop's clock.dot.
>
> I don't think this can happen. intel_pll_is_valid() validates
> all the dividers first and bails out if they are junk.
Hmm. That said, there is actually a case to be made for fully
initializing the struct, and even removing the WARN. If the
BIOS (or whatever was doing stuff before i915 takes over)
has misprogrammed the DPLL then we could potentially have
garbage dividers on our hands, and during readout we'd just
blindly call *_calc_dpll_params() on them.
So I'm thinking something along the lines of
clock->vco = ? DIV_ROUND_CLOSEST(...) : 0;
clock->dot = ? DIV_ROUND_CLOSEST(...) : 0;
might be what we should do here.
To make it a bit less ugly a small helper function might
be in order. intel_pll_div() perhaps?
>
> >
> > The *_dpll_params functions return an arithmetic statement
> > with the clock.dot as the variable. Change the error handler
> > to set clock.dot to 0 and jump to the return statement.
> >
> > Fixes: dccbea3b0704 ("drm/i915: calculate the port clock rate along with
> > other PLL params")
> > Signed-off-by: Tom Rix
> > ---
> > drivers/gpu/drm/i915/display/intel_dpll.c | 32 ++-
> > 1 file changed, 20 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
> > b/drivers/gpu/drm/i915/display/intel_dpll.c
> > index 0ae37fdbf2a5b..ba7cada704288 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> > @@ -309,11 +309,13 @@ int pnv_calc_dpll_params(int refclk, struct dpll
> > *clock)
> > {
> > clock->m = clock->m2 + 2;
> > clock->p = clock->p1 * clock->p2;
> > - if (WARN_ON(clock->n == 0 || clock->p == 0))
> > - return 0;
> > + if (WARN_ON(clock->n == 0 || clock->p == 0)) {
> > + clock->dot = 0;
> > + goto end;
> > + }
> > clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
> > clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> > -
> > +end:
> > return clock->dot;
> > }
> >
> > @@ -326,11 +328,13 @@ int i9xx_calc_dpll_params(int refclk, struct dpll
> > *clock)
> > {
> > clock->m = i9xx_dpll_compute_m(clock);
> > clock->p = clock->p1 * clock->p2;
> > - if (WARN_ON(clock->n + 2 == 0 || clock->p == 0))
> > - return 0;
> > + if (WARN_ON(clock->n + 2 == 0 || clock->p == 0)) {
> > + clock->dot = 0;
> > + goto end;
> > + }
> > clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2);
> > clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> > -
> > +end:
> > return clock->dot;
> > }
> >
> > @@ -338,11 +342,13 @@ int vlv_calc_dpll_params(int refclk, struct dpll
> > *clock)
> > {
> > clock->m = clock->m1 * clock->m2;
> > clock->p = clock->p1 * clock->p2;
> > - if (WARN_ON(clock->n == 0 || clock->p == 0))
> > - return 0;
> > + if (WARN_ON(clock->n == 0 || clock->p == 0)) {
> > + clock->dot = 0;
> > + goto end;
> > + }
> > clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
> > clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> > -
> > +end:
> > return clock->dot / 5;
> > }
> >
> > @@ -350,12 +356,14 @@ int chv_calc_dpll_params(int refclk, struct dpll
> > *clock)
> > {
> > clock->m = clock->m1 * clock->m2;
> > clock->p = clock->p1 * clock->p2;
> > - if (WARN_ON(clock->n == 0 || clock->p == 0))
> > - return 0;
> > + if (WARN_ON(clock->n == 0 || clock->p == 0)) {
> > + clock->dot = 0;
> > + goto end;
> > + }
> > clock->vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock->m),
> >clock->n << 22);
> > clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> > -
> > +end:
> > return clock->dot / 5;
> > }
> >
> > --
> > 2.26.3
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] drm/i915: rework the error handling in *_dpll_params
On Fri, Mar 04, 2022 at 01:03:55PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this issue
> intel_dpll.c:472:31: warning: The left operand of '-'
> is a garbage value [core.UndefinedBinaryOperatorResult]
> this_err = abs(clock.dot - target);
> ~ ^
>
> In a loop clock.dot is set on successful call to
> i9xx_calc_dpll_params(). If the call fails, the later
> *is_valid() will use the previous loop's clock.dot.
I don't think this can happen. intel_pll_is_valid() validates
all the dividers first and bails out if they are junk.
>
> The *_dpll_params functions return an arithmetic statement
> with the clock.dot as the variable. Change the error handler
> to set clock.dot to 0 and jump to the return statement.
>
> Fixes: dccbea3b0704 ("drm/i915: calculate the port clock rate along with
> other PLL params")
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/i915/display/intel_dpll.c | 32 ++-
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
> b/drivers/gpu/drm/i915/display/intel_dpll.c
> index 0ae37fdbf2a5b..ba7cada704288 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> @@ -309,11 +309,13 @@ int pnv_calc_dpll_params(int refclk, struct dpll *clock)
> {
> clock->m = clock->m2 + 2;
> clock->p = clock->p1 * clock->p2;
> - if (WARN_ON(clock->n == 0 || clock->p == 0))
> - return 0;
> + if (WARN_ON(clock->n == 0 || clock->p == 0)) {
> + clock->dot = 0;
> + goto end;
> + }
> clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> -
> +end:
> return clock->dot;
> }
>
> @@ -326,11 +328,13 @@ int i9xx_calc_dpll_params(int refclk, struct dpll
> *clock)
> {
> clock->m = i9xx_dpll_compute_m(clock);
> clock->p = clock->p1 * clock->p2;
> - if (WARN_ON(clock->n + 2 == 0 || clock->p == 0))
> - return 0;
> + if (WARN_ON(clock->n + 2 == 0 || clock->p == 0)) {
> + clock->dot = 0;
> + goto end;
> + }
> clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> -
> +end:
> return clock->dot;
> }
>
> @@ -338,11 +342,13 @@ int vlv_calc_dpll_params(int refclk, struct dpll *clock)
> {
> clock->m = clock->m1 * clock->m2;
> clock->p = clock->p1 * clock->p2;
> - if (WARN_ON(clock->n == 0 || clock->p == 0))
> - return 0;
> + if (WARN_ON(clock->n == 0 || clock->p == 0)) {
> + clock->dot = 0;
> + goto end;
> + }
> clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> -
> +end:
> return clock->dot / 5;
> }
>
> @@ -350,12 +356,14 @@ int chv_calc_dpll_params(int refclk, struct dpll *clock)
> {
> clock->m = clock->m1 * clock->m2;
> clock->p = clock->p1 * clock->p2;
> - if (WARN_ON(clock->n == 0 || clock->p == 0))
> - return 0;
> + if (WARN_ON(clock->n == 0 || clock->p == 0)) {
> + clock->dot = 0;
> + goto end;
> + }
> clock->vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock->m),
> clock->n << 22);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
> -
> +end:
> return clock->dot / 5;
> }
>
> --
> 2.26.3
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH] drm/i915: rework the error handling in *_dpll_params
From: Tom Rix
Clang static analysis reports this issue
intel_dpll.c:472:31: warning: The left operand of '-'
is a garbage value [core.UndefinedBinaryOperatorResult]
this_err = abs(clock.dot - target);
~ ^
In a loop clock.dot is set on successful call to
i9xx_calc_dpll_params(). If the call fails, the later
*is_valid() will use the previous loop's clock.dot.
The *_dpll_params functions return an arithmetic statement
with the clock.dot as the variable. Change the error handler
to set clock.dot to 0 and jump to the return statement.
Fixes: dccbea3b0704 ("drm/i915: calculate the port clock rate along with other
PLL params")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/i915/display/intel_dpll.c | 32 ++-
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 0ae37fdbf2a5b..ba7cada704288 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -309,11 +309,13 @@ int pnv_calc_dpll_params(int refclk, struct dpll *clock)
{
clock->m = clock->m2 + 2;
clock->p = clock->p1 * clock->p2;
- if (WARN_ON(clock->n == 0 || clock->p == 0))
- return 0;
+ if (WARN_ON(clock->n == 0 || clock->p == 0)) {
+ clock->dot = 0;
+ goto end;
+ }
clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
-
+end:
return clock->dot;
}
@@ -326,11 +328,13 @@ int i9xx_calc_dpll_params(int refclk, struct dpll *clock)
{
clock->m = i9xx_dpll_compute_m(clock);
clock->p = clock->p1 * clock->p2;
- if (WARN_ON(clock->n + 2 == 0 || clock->p == 0))
- return 0;
+ if (WARN_ON(clock->n + 2 == 0 || clock->p == 0)) {
+ clock->dot = 0;
+ goto end;
+ }
clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2);
clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
-
+end:
return clock->dot;
}
@@ -338,11 +342,13 @@ int vlv_calc_dpll_params(int refclk, struct dpll *clock)
{
clock->m = clock->m1 * clock->m2;
clock->p = clock->p1 * clock->p2;
- if (WARN_ON(clock->n == 0 || clock->p == 0))
- return 0;
+ if (WARN_ON(clock->n == 0 || clock->p == 0)) {
+ clock->dot = 0;
+ goto end;
+ }
clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
-
+end:
return clock->dot / 5;
}
@@ -350,12 +356,14 @@ int chv_calc_dpll_params(int refclk, struct dpll *clock)
{
clock->m = clock->m1 * clock->m2;
clock->p = clock->p1 * clock->p2;
- if (WARN_ON(clock->n == 0 || clock->p == 0))
- return 0;
+ if (WARN_ON(clock->n == 0 || clock->p == 0)) {
+ clock->dot = 0;
+ goto end;
+ }
clock->vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock->m),
clock->n << 22);
clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
-
+end:
return clock->dot / 5;
}
--
2.26.3
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Suraj On 3/4/2022 6:16 AM, Kandpal, Suraj wrote: Hi, Hi, Hi Abhinav, Hi Laurent Ok sure, I can take this up but I need to understand the proposal a little bit more before proceeding on this. So we will discuss this in another email where we specifically talk about the connector changes. Also, I am willing to take this up once the encoder part is done and merged so that atleast we keep moving on that as MSM WB implementation can proceed with that first. Hi Jani and Suraj Any concerns with splitting up the series into encoder and connector OR re- arranging them? Let me know if you can do this OR I can also split this up keeping Suraj's name in the Co-developed by tag. I was actually thinking of floating a new patch series with both encoder and connector pointer changes but with a change in initialization functions wherein we allocate a connector and encoder incase the driver doesn’t have its own this should minimize the effect on other drivers already using current drm writeback framework and also allow i915 to create its own connector. I was proposing to split up the encoder and connector because the comments from Laurent meant we were in agreement about the encoder but not about the connector. I am afraid another attempt with the similar idea is only going to stall the series again and hence i gave this option. Eventually its upto Laurent and the other maintainers to guide us forward on this as this series has been stalled for weeks now. I thought that Laurent was quite strict about the connector. So I'd suggest targeting drm_writeback_connector with an optionally created encoder and the builtin connector In that case even if we target that i915 will not be able to move forward with its implementation of writeback as builtin connector does not work for us right now as explained earlier, optionally creating encoder and connector will help everyone move forward and once done we can actually sit and work on how to side step this issue using Laurent's suggestion This is up to Laurent & other DRM maintainers to decide whether this approach would be accepted or not. So far unfortunately I have mostly seen the pushback and a strong suggestion to stop treating each drm_connector as i915_connector. I haven't checked the exact details, but IMO adding a branch if the connector's type is DRM_CONNECTOR_VIRTUAL should be doable. Bringing in the change where we don’t treat each drm_connector as an intel_connector or even adding a branch which checks if drm_connector is DRM_CONNECTOR_VIRTUAL and conditionally cast it to intel_connector is quite a lot of work for i915. That's why I was suggesting if for now we could move forward with optionally creating both encoder and connector minimizing affects on other drivers as well as allowing us to move forward. What do you think, Launrent? We can work on Laurent's suggestion but that would first require the initial RFC patches and then a rework from both of our drivers side to see if they gel well with our current code which will take a considerable amount of time. We can for now however float the patch series up which minimally affects the current drivers and also allows i915 and msm to move forward with its writeback implementation off course with a proper documentation stating new drivers shouldn't try to make their own connectors and encoders and that drm_writeback will do that for them. Once that's done and merged we can work with Laurent on his proposal to improve the drm writeback framework so that this issue can be side stepped entirely in future. For now I would like to keep the encoder and connector pointer changes together. -- With best wishes Dmitry Best Regards, Suraj Kandpal
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: stop checking for NULL vma->obj
== Series Details ==
Series: drm/i915: stop checking for NULL vma->obj
URL : https://patchwork.freedesktop.org/series/101054/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11329 -> Patchwork_22490
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/index.html
Participating hosts (44 -> 41)
--
Missing(3): fi-bsw-cyan shard-tglu fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22490 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#3921])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@gem_wait@wait@all:
- {bat-jsl-2}:[FAIL][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/bat-jsl-2/igt@gem_wait@w...@all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/bat-jsl-2/igt@gem_wait@w...@all.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [FAIL][5] ([i915#4032]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/bat-dg1-5/igt@i915_pm_...@basic-api.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][7] ([i915#4494] / [i915#4957]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [FAIL][9] ([i915#4547]) -> [INCOMPLETE][10]
([i915#4547])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4032]: https://gitlab.freedesktop.org/drm/intel/issues/4032
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5087]: https://gitlab.freedesktop.org/drm/intel/issues/5087
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-
* Linux: CI_DRM_11329 -> Patchwork_22490
CI-20190529: 20190529
CI_DRM_11329: ec4c2d8a8b77ef304b5f4d5badb03a84f0b18ce5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6364: 3523fe577bc22e6512a8de7e60175c8f46cf61d2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22490: e09ec7ec1180f14cb9bb5f9f9ea6c6e3e7dbb662 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e09ec7ec1180 drm/i915: stop checking for NULL vma->obj
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22490/index.html
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration
On 3/4/2022 03:59, Jani Nikula wrote:
On Thu, 24 Feb 2022, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as a check for
context registration, use the GuC id instead (being the thing that
actually gets registered with the GuC).
Also, rename the set/clear/query helper functions for context id
mappings to better reflect their purpose and to differentiate from
other registration related helper functions.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
1 file changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b3a429a92c0d..7fb889e14995 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -514,31 +514,20 @@ static inline bool guc_submission_initialized(struct
intel_guc *guc)
return !!guc->lrc_desc_pool_vaddr;
}
-static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)
+static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)
{
- if (likely(guc_submission_initialized(guc))) {
- struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
- unsigned long flags;
-
- memset(desc, 0, sizeof(*desc));
+ struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
- /*
-* xarray API doesn't have xa_erase_irqsave wrapper, so calling
-* the lower level functions directly.
-*/
- xa_lock_irqsave(&guc->context_lookup, flags);
- __xa_erase(&guc->context_lookup, id);
- xa_unlock_irqrestore(&guc->context_lookup, flags);
- }
+ memset(desc, 0, sizeof(*desc));
}
-static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)
+static inline bool ctx_id_mapped(struct intel_guc *guc, u32 id)
{
return __get_context(guc, id);
}
-static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
- struct intel_context *ce)
+static inline void set_ctx_id_mapping(struct intel_guc *guc, u32 id,
+ struct intel_context *ce)
{
unsigned long flags;
@@ -551,6 +540,24 @@ static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
xa_unlock_irqrestore(&guc->context_lookup, flags);
}
+static inline void clr_ctx_id_mapping(struct intel_guc *guc, u32 id)
+{
+ unsigned long flags;
+
+ if (unlikely(!guc_submission_initialized(guc)))
+ return;
+
+ _reset_lrc_desc(guc, id);
+
+ /*
+* xarray API doesn't have xa_erase_irqsave wrapper, so calling
+* the lower level functions directly.
+*/
+ xa_lock_irqsave(&guc->context_lookup, flags);
+ __xa_erase(&guc->context_lookup, id);
+ xa_unlock_irqrestore(&guc->context_lookup, flags);
+}
There are a plethora of static inlines in the guc .c files, and this
adds more. How about just letting the compiler decide what's the best
course of action, inline or not? I think hand rolling the inline is a
micro optimization that you'd need to justify i.e. show that you're
doing a better job than the compiler.
The main downsides to using inlines are that you'll miss compiler
warnings for unused functions, and it sets an example for people to
start using inline more, while they should be an exception.
BR,
Jani.
PS. I also don't much like the likely/unlikely annotations, but that's
another can of worms.
Technically, this patch isn't adding any new ones. It is just reworking
existing functions in their existing style. So it basically comes under
your last point of people just following the prevailing style because
it's already there.
I can add a task to the clean-up backlog to remove all mention of
inline. Not sure why you think the (un)likely tags are bad? Again, I
have no particular view either way.
John.
+
static void decr_outstanding_submission_g2h(struct intel_guc *guc)
{
if (atomic_dec_and_test(&guc->outstanding_submission_g2h))
@@ -795,7 +802,7 @@ static int __guc_wq_item_append(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(&ce->guc_id.ref));
GEM_BUG_ON(context_guc_id_invalid(ce));
GEM_BUG_ON(context_wait_for_deregister_to_register(ce));
- GEM_BUG_ON(!lrc_desc_registered(ce_to_guc(ce), ce->guc_id.id));
+ GEM_BUG_ON(!ctx_id_mapped(ce_to_guc(ce), ce->guc_id.id));
/* Insert NOOP if this work queue item will wrap the tail pointer. */
if (wqi_size > wq_space_until_wrap(ce)) {
@@ -923,7 +930,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
if (submit) {
struct intel_context *ce = request_to_scheduling_context(last);
- if (unlikely(!lrc_desc_registered(
[Intel-gfx] ✓ Fi.CI.IGT: success for vm- and vma cleanups (rev2)
== Series Details ==
Series: vm- and vma cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/100945/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11326_full -> Patchwork_22485_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22485_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@api_intel_allocator@fork-simple-stress:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-rkl-2/igt@api_intel_alloca...@fork-simple-stress.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-rkl-5/igt@api_intel_alloca...@fork-simple-stress.html
* igt@api_intel_allocator@fork-simple-stress-signal:
- {shard-dg1}:[PASS][3] -> [TIMEOUT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-dg1-19/igt@api_intel_alloca...@fork-simple-stress-signal.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-dg1-15/igt@api_intel_alloca...@fork-simple-stress-signal.html
* {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-75}:
- {shard-rkl}:NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-rkl-1/igt@kms_plane_scal...@planes-upscale-factor-0-25-downscale-factor-0-75.html
* igt@prime_mmap@test_forked_cpu_write:
- {shard-dg1}:NOTRUN -> [SKIP][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-dg1-13/igt@prime_mmap@test_forked_cpu_write.html
Known issues
Here are the changes found in Patchwork_22485_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][7] ([i915#1839])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-iclb8/igt@feature_discov...@display-2x.html
* igt@gem_exec_balancer@parallel:
- shard-iclb: NOTRUN -> [DMESG-WARN][8] ([i915#5076])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-iclb4/igt@gem_exec_balan...@parallel.html
- shard-tglb: NOTRUN -> [DMESG-WARN][9] ([i915#5076])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-tglb8/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_endless@dispatch@vcs0:
- shard-kbl: [PASS][10] -> [INCOMPLETE][11] ([i915#3778])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-kbl4/igt@gem_exec_endless@dispa...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-kbl7/igt@gem_exec_endless@dispa...@vcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: NOTRUN -> [FAIL][12] ([i915#2846])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-kbl4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842]) +4 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [PASS][18] -> [FAIL][19] ([i915#2842])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][20] -> [FAIL][21] ([i915#2849])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_params@no-bsd:
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#109283])
[22]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: stop checking for NULL vma->obj
== Series Details ==
Series: drm/i915: stop checking for NULL vma->obj
URL : https://patchwork.freedesktop.org/series/101054/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e09ec7ec1180 drm/i915: stop checking for NULL vma->obj
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e6e1a304d759 ("drm/i915: vma is
always backed by an object.")'
#9:
This is no longer possible since e6e1a304d759 ("drm/i915: vma is always
total: 1 errors, 0 warnings, 0 checks, 35 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for Some more bits for small BAR enabling
== Series Details ==
Series: Some more bits for small BAR enabling
URL : https://patchwork.freedesktop.org/series/101052/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11329 -> Patchwork_22489
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22489 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22489, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/index.html
Participating hosts (44 -> 43)
--
Additional (3): fi-tgl-1115g4 fi-icl-u2 fi-pnv-d510
Missing(4): fi-bsw-cyan fi-bdw-samus shard-tglu fi-skl-6600u
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22489:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@module-reload:
- fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
* igt@kms_addfb_basic@too-wide:
- fi-tgl-1115g4: NOTRUN -> [DMESG-WARN][2] +87 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-tgl-1115g4/igt@kms_addfb_ba...@too-wide.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@workarounds:
- {bat-adlp-6}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_22489 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][5] ([fdo#109315]) +17 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@core_hotunplug@unbind-rebind:
- fi-pnv-d510:NOTRUN -> [FAIL][6] ([i915#3194])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-pnv-d510/igt@core_hotunp...@unbind-rebind.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][8] ([i915#2190])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@verify-random:
- fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#4613]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([i915#1155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][12] ([i915#3921])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][13] -> [INCOMPLETE][14] ([i915#3921])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11329/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22489/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- f
Re: [Intel-gfx] [PATCH 7/8] drm/i915: fixup the initial fb base on DG1
On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote:
> The offset we get looks to be the exact start of DSM, but the
> inital_plane_vma expects the address to be relative.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> .../drm/i915/display/intel_plane_initial.c| 22 +++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index f797fcef18fc..b39d3a8dfe45 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -56,10 +56,24 @@ initial_plane_vma(struct drm_i915_private *i915,
> if (!mem || plane_config->size == 0)
> return NULL;
>
> - base = round_down(plane_config->base,
> - I915_GTT_MIN_ALIGNMENT);
> - size = round_up(plane_config->base + plane_config->size,
> - mem->min_page_size);
> + base = plane_config->base;
> + if (IS_DGFX(i915)) {
> + /*
> + * On discrete the base address should be somewhere in LMEM, but
> + * depending on the size of LMEM the base address might
> + * intersect with the start of DSM, like on DG1, in which case
> + * we need the relative address. In such cases we might also
> + * need to choose between inital fb vs fbc, if space is limited.
> + *
> + * On future discrete HW, like DG2, we should be able to just
> + * allocate directly from LMEM, due to larger LMEM size.
> + */
> + if (base >= i915->dsm.start)
> + base -= i915->dsm.start;
Subsequent code expects the object to actually be inside stolen.
If that is not the case we should just give up.
The fact that we fail to confirm any of that on integrated
parts has always bugged me, but not enough to actually do
anything about it. Such a check would be somewhat more involved
since we'd have to look at the PTEs. But on discrete sounds like
we can get away with a trivial check.
> + }
> +
> + size = roundup(base + plane_config->size, mem->min_page_size);
> + base = round_down(base, I915_GTT_MIN_ALIGNMENT);
> size -= base;
>
> /*
> --
> 2.34.1
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Some more bits for small BAR enabling
== Series Details == Series: Some more bits for small BAR enabling URL : https://patchwork.freedesktop.org/series/101052/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Some more bits for small BAR enabling
== Series Details == Series: Some more bits for small BAR enabling URL : https://patchwork.freedesktop.org/series/101052/ State : warning == Summary == $ dim checkpatch origin/drm-tip a3f0e7b2e0d0 drm/i915/lmem: don't treat small BAR as an error 2cdb743c5a4e drm/i915/stolen: don't treat small BAR as an error 74db3d383272 drm/i915: add i915_gem_object_create_region_at() 3f5470e8098d drm/i915/buddy: tweak CONTIGUOUS rounding 80375509e058 drm/i915/ttm: wire up the object offset 28a20a817e9c drm/i915/display: Check mappable aperture when pinning preallocated vma 4d5d41ab2df8 drm/i915: fixup the initial fb base on DG1 -:34: WARNING:TYPO_SPELLING: 'inital' may be misspelled - perhaps 'initial'? #34: FILE: drivers/gpu/drm/i915/display/intel_plane_initial.c:66: +* need to choose between inital fb vs fbc, if space is limited. ^^ total: 0 errors, 1 warnings, 0 checks, 28 lines checked b9bdff2b6be6 drm/i915: fixup the initial fb on DG2
Re: [Intel-gfx] [PATCH] drm/i915: stop checking for NULL vma->obj
On Fri, 2022-03-04 at 17:42 +, Matthew Auld wrote:
> This is no longer possible since e6e1a304d759 ("drm/i915: vma is
> always
> backed by an object.").
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
LGTM.
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/i915_vma.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c
> b/drivers/gpu/drm/i915/i915_vma.c
> index 94fcdb7bd21d..7acfbbc63d17 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -515,21 +515,18 @@ int i915_vma_bind(struct i915_vma *vma,
> if (!work->vma_res->bi.pages_rsgt)
> work->pinned = i915_gem_object_get(vma->obj);
> } else {
> - if (vma->obj) {
> - ret = i915_gem_object_wait_moving_fence(vma-
> >obj, true);
> - if (ret) {
> - i915_vma_resource_free(vma-
> >resource);
> - vma->resource = NULL;
> + ret = i915_gem_object_wait_moving_fence(vma->obj,
> true);
> + if (ret) {
> + i915_vma_resource_free(vma->resource);
> + vma->resource = NULL;
>
> - return ret;
> - }
> + return ret;
> }
> vma->ops->bind_vma(vma->vm, NULL, vma->resource,
> cache_level,
> bind_flags);
> }
>
> - if (vma->obj)
> - set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
> + set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
>
> atomic_or(bind_flags, &vma->flags);
> return 0;
> @@ -1360,7 +1357,7 @@ int i915_vma_pin_ww(struct i915_vma *vma,
> struct i915_gem_ww_ctx *ww,
> if (flags & PIN_GLOBAL)
> wakeref = intel_runtime_pm_get(&vma->vm->i915-
> >runtime_pm);
>
> - moving = vma->obj ? i915_gem_object_get_moving_fence(vma-
> >obj) : NULL;
> + moving = i915_gem_object_get_moving_fence(vma->obj);
> if (flags & vma->vm->bind_async_flags || moving) {
> /* lock VM */
> err = i915_vm_lock_objects(vma->vm, ww);
[Intel-gfx] [PATCH] drm/i915: stop checking for NULL vma->obj
This is no longer possible since e6e1a304d759 ("drm/i915: vma is always
backed by an object.").
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 94fcdb7bd21d..7acfbbc63d17 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -515,21 +515,18 @@ int i915_vma_bind(struct i915_vma *vma,
if (!work->vma_res->bi.pages_rsgt)
work->pinned = i915_gem_object_get(vma->obj);
} else {
- if (vma->obj) {
- ret = i915_gem_object_wait_moving_fence(vma->obj, true);
- if (ret) {
- i915_vma_resource_free(vma->resource);
- vma->resource = NULL;
+ ret = i915_gem_object_wait_moving_fence(vma->obj, true);
+ if (ret) {
+ i915_vma_resource_free(vma->resource);
+ vma->resource = NULL;
- return ret;
- }
+ return ret;
}
vma->ops->bind_vma(vma->vm, NULL, vma->resource, cache_level,
bind_flags);
}
- if (vma->obj)
- set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
+ set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
atomic_or(bind_flags, &vma->flags);
return 0;
@@ -1360,7 +1357,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
if (flags & PIN_GLOBAL)
wakeref = intel_runtime_pm_get(&vma->vm->i915->runtime_pm);
- moving = vma->obj ? i915_gem_object_get_moving_fence(vma->obj) : NULL;
+ moving = i915_gem_object_get_moving_fence(vma->obj);
if (flags & vma->vm->bind_async_flags || moving) {
/* lock VM */
err = i915_vm_lock_objects(vma->vm, ww);
--
2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/gtt: reduce overzealous alignment constraints for GGTT
On 3/3/22 11:02, Matthew Auld wrote:
Currently this will enforce both 2M alignment and padding for any LMEM
pages inserted into the GGTT. However, this was only meant to be applied
to the compact-pt layout with the ppGTT. For the GGTT we can reduce the
alignment and padding to 64K.
Bspec: 45015
Fixes: 87bd701ee268 ("drm/i915: enforce min GTT alignment for discrete cards")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Robert Beckett
Cc: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 4bcdfcab3642..a5f5b2dda332 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -234,7 +234,8 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
ARRAY_SIZE(vm->min_alignment));
- if (HAS_64K_PAGES(vm->i915) && NEEDS_COMPACT_PT(vm->i915)) {
+ if (HAS_64K_PAGES(vm->i915) && NEEDS_COMPACT_PT(vm->i915) &&
+ subclass == VM_CLASS_PPGTT) {
vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_2M;
vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] =
I915_GTT_PAGE_SIZE_2M;
} else if (HAS_64K_PAGES(vm->i915)) {
Re: [Intel-gfx] [CI 1/2] drm/i915/fbdev: fixup setting screen_size
On 3/4/22 10:59, Matthew Auld wrote: Since we are actually mapping the object and not the vma, when dealing with LMEM, we should be careful and use the backing store size here, since the vma->node.size could have all kinds of funny padding constraints, which could result in us writing to OOB address. v2(Chris): - Prefer vma->size here, which should be the backing store size. Some more rework is needed here to stop using node.size in some other places. Signed-off-by: Matthew Auld Cc: Stanislav Lisovskiy Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/display/intel_fbdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c index 2cd62a187df3..221336178991 100644 --- a/drivers/gpu/drm/i915/display/intel_fbdev.c +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c @@ -279,7 +279,7 @@ static int intelfb_create(struct drm_fb_helper *helper, /* Our framebuffer is the entirety of fbdev's system memory */ info->fix.smem_start = (unsigned long)(ggtt->gmadr.start + vma->node.start); - info->fix.smem_len = vma->node.size; + info->fix.smem_len = vma->size; } vaddr = i915_vma_pin_iomap(vma); @@ -290,7 +290,7 @@ static int intelfb_create(struct drm_fb_helper *helper, goto out_unpin; } info->screen_base = vaddr; - info->screen_size = vma->node.size; + info->screen_size = vma->size; drm_fb_helper_fill_info(info, &ifbdev->helper, sizes);
Re: [Intel-gfx] [CI 2/2] drm/i915: limit the async bind to bind_async_flags
On 04/03/2022 16:41, Thomas Hellström wrote:
On Fri, 2022-03-04 at 09:59 +, Matthew Auld wrote:
If the vm doesn't request async binding, like for example with the
dpt,
then we should be able to skip the async path and avoid calling
i915_vm_lock_objects() altogether. Currently if we have a moving
fence
set for the BO(even though it might have signalled), we still take
the
async patch regardless of the bind_async setting, and then later
still
end up just doing i915_gem_object_wait_moving_fence() anyway.
Alternatively we would need to add dummy scratch object which can be
locked, just for the dpt.
Suggested-by: Thomas Hellström
Signed-off-by: Matthew Auld
Cc: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 94fcdb7bd21d..4d4d3659c938 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1360,8 +1360,7 @@ int i915_vma_pin_ww(struct i915_vma *vma,
struct i915_gem_ww_ctx *ww,
if (flags & PIN_GLOBAL)
wakeref = intel_runtime_pm_get(&vma->vm->i915-
runtime_pm);
- moving = vma->obj ?
Is there a chance that "moving" will be used uninitialized later?
It looks to be initialised with NULL further up.
i915_gem_object_get_moving_fence(vma->obj) : NULL;
- if (flags & vma->vm->bind_async_flags || moving) {
+ if (flags & vma->vm->bind_async_flags) {
/* lock VM */
err = i915_vm_lock_objects(vma->vm, ww);
if (err)
@@ -1375,6 +1374,7 @@ int i915_vma_pin_ww(struct i915_vma *vma,
struct i915_gem_ww_ctx *ww,
work->vm = i915_vm_get(vma->vm);
+ moving = vma->obj ?
i915_gem_object_get_moving_fence(vma->obj) : NULL;
IIRC, with Maarten's recent changes, vma->obj is always non-NULL.
Yup, a number of these seem to have crept back in. I was going to send a
follow up patch to fix all of them at once.
Otherwise LGTM.
Reviewed-by: Thomas Hellström
Thanks.
dma_fence_work_chain(&work->base, moving);
/* Allocate enough page directories to used PTE */
/Thomas
[Intel-gfx] [PATCH 8/8] drm/i915: fixup the initial fb on DG2
On DG2+ the initial fb shouldn't be placed anywhere close to DSM, and so
should just be allocated directly from LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_plane_initial.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index b39d3a8dfe45..5a3baeb620a6 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -68,8 +68,12 @@ initial_plane_vma(struct drm_i915_private *i915,
* On future discrete HW, like DG2, we should be able to just
* allocate directly from LMEM, due to larger LMEM size.
*/
- if (base >= i915->dsm.start)
+ if (base >= i915->dsm.start) {
base -= i915->dsm.start;
+ } else {
+ WARN_ON_ONCE(IS_DG1(i915));
+ mem = i915->mm.regions[INTEL_REGION_LMEM];
+ }
}
size = roundup(base + plane_config->size, mem->min_page_size);
@@ -82,11 +86,11 @@ initial_plane_vma(struct drm_i915_private *i915,
* features.
*/
if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
+ mem == i915->mm.stolen_region &&
size * 2 > i915->stolen_usable_size)
return NULL;
- obj = i915_gem_object_create_region_at(i915->mm.stolen_region,
- base, size, 0);
+ obj = i915_gem_object_create_region_at(mem, base, size, 0);
if (IS_ERR(obj))
return NULL;
--
2.34.1
[Intel-gfx] [PATCH 7/8] drm/i915: fixup the initial fb base on DG1
The offset we get looks to be the exact start of DSM, but the
inital_plane_vma expects the address to be relative.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/display/intel_plane_initial.c| 22 +++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index f797fcef18fc..b39d3a8dfe45 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -56,10 +56,24 @@ initial_plane_vma(struct drm_i915_private *i915,
if (!mem || plane_config->size == 0)
return NULL;
- base = round_down(plane_config->base,
- I915_GTT_MIN_ALIGNMENT);
- size = round_up(plane_config->base + plane_config->size,
- mem->min_page_size);
+ base = plane_config->base;
+ if (IS_DGFX(i915)) {
+ /*
+* On discrete the base address should be somewhere in LMEM, but
+* depending on the size of LMEM the base address might
+* intersect with the start of DSM, like on DG1, in which case
+* we need the relative address. In such cases we might also
+* need to choose between inital fb vs fbc, if space is limited.
+*
+* On future discrete HW, like DG2, we should be able to just
+* allocate directly from LMEM, due to larger LMEM size.
+*/
+ if (base >= i915->dsm.start)
+ base -= i915->dsm.start;
+ }
+
+ size = roundup(base + plane_config->size, mem->min_page_size);
+ base = round_down(base, I915_GTT_MIN_ALIGNMENT);
size -= base;
/*
--
2.34.1
[Intel-gfx] [PATCH 6/8] drm/i915/display: Check mappable aperture when pinning preallocated vma
From: CQ Tang When system does not have mappable aperture, ggtt->mappable_end=0. In this case if we pass PIN_MAPPABLE when pinning vma, the pinning code will return -ENOSPC. So conditionally set PIN_MAPPABLE if HAS_GMCH(). Suggested-by: Chris P Wilson Signed-off-by: CQ Tang Cc: Radhakrishna Sripada Cc: Ap Kamal Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c index 5227e5b35206..f797fcef18fc 100644 --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c @@ -51,6 +51,7 @@ initial_plane_vma(struct drm_i915_private *i915, struct drm_i915_gem_object *obj; struct i915_vma *vma; u32 base, size; + u64 pinctl; if (!mem || plane_config->size == 0) return NULL; @@ -101,7 +102,10 @@ initial_plane_vma(struct drm_i915_private *i915, if (IS_ERR(vma)) goto err_obj; - if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base)) + pinctl = PIN_GLOBAL | PIN_OFFSET_FIXED | base; + if (HAS_GMCH(i915)) + pinctl |= PIN_MAPPABLE; + if (i915_vma_pin(vma, 0, 0, pinctl)) goto err_obj; if (i915_gem_object_is_tiled(obj) && -- 2.34.1
[Intel-gfx] [PATCH 4/8] drm/i915/buddy: tweak CONTIGUOUS rounding
If this is an actual range allocation, and not some bias thing then the
resultant allocation will already be naturally contiguous without
needing any power-of-two rounding.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 129f668f21ff..8e4e3f72c1ef 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -71,7 +71,8 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
GEM_BUG_ON(min_page_size < mm->chunk_size);
- if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ if (place->fpfn + bman_res->base.num_pages != place->lpfn &&
+ place->flags & TTM_PL_FLAG_CONTIGUOUS) {
unsigned long pages;
size = roundup_pow_of_two(size);
--
2.34.1
[Intel-gfx] [PATCH 5/8] drm/i915/ttm: wire up the object offset
For the ttm backend we can use existing placements fpfn and lpfn to
force the allocator to place the object at the requested offset,
potentially evicting stuff if the spot is currently occupied.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 18 ++
drivers/gpu/drm/i915/intel_region_ttm.c| 7 ++-
drivers/gpu/drm/i915/intel_region_ttm.h| 1 +
drivers/gpu/drm/i915/selftests/mock_region.c | 3 +++
5 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index fd54eb8f4826..2c88bdb8ff7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -631,6 +631,8 @@ struct drm_i915_gem_object {
struct drm_mm_node *stolen;
+ resource_size_t bo_offset;
+
unsigned long scratch;
u64 encode;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5e543ed867a2..e4a06fcf741a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -126,6 +126,8 @@ i915_ttm_select_tt_caching(const struct drm_i915_gem_object
*obj)
static void
i915_ttm_place_from_region(const struct intel_memory_region *mr,
struct ttm_place *place,
+ resource_size_t offset,
+ resource_size_t size,
unsigned int flags)
{
memset(place, 0, sizeof(*place));
@@ -133,7 +135,10 @@ i915_ttm_place_from_region(const struct
intel_memory_region *mr,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place->flags |= TTM_PL_FLAG_CONTIGUOUS;
- if (mr->io_size && mr->io_size < mr->total) {
+ if (offset != I915_BO_INVALID_OFFSET) {
+ place->fpfn = offset >> PAGE_SHIFT;
+ place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+ } else if (mr->io_size && mr->io_size < mr->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place->flags |= TTM_PL_FLAG_TOPDOWN;
} else {
@@ -155,12 +160,14 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
placement->num_placement = 1;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
- obj->mm.region, requested, flags);
+ obj->mm.region, requested, obj->bo_offset,
+ obj->base.size, flags);
/* Cache this on object? */
placement->num_busy_placement = num_allowed;
for (i = 0; i < placement->num_busy_placement; ++i)
- i915_ttm_place_from_region(obj->mm.placements[i], busy + i,
flags);
+ i915_ttm_place_from_region(obj->mm.placements[i], busy + i,
+ obj->bo_offset, obj->base.size,
flags);
if (num_allowed == 0) {
*busy = *requested;
@@ -802,7 +809,8 @@ static int __i915_ttm_migrate(struct drm_i915_gem_object
*obj,
struct ttm_placement placement;
int ret;
- i915_ttm_place_from_region(mr, &requested, flags);
+ i915_ttm_place_from_region(mr, &requested, obj->bo_offset,
+ obj->base.size, flags);
placement.num_placement = 1;
placement.num_busy_placement = 1;
placement.placement = &requested;
@@ -1159,6 +1167,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
drm_gem_private_object_init(&i915->drm, &obj->base, size);
i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
+ obj->bo_offset = offset;
+
/* Don't put on a region list until we're either locked or fully
initialized. */
obj->mm.region = mem;
INIT_LIST_HEAD(&obj->mm.region_link);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 737ef3f4ab54..62ff77445b01 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -12,6 +12,7 @@
#include "intel_region_ttm.h"
+#include "gem/i915_gem_region.h"
#include "gem/i915_gem_ttm.h" /* For the funcs/ops export only */
/**
* DOC: TTM support structure
@@ -191,6 +192,7 @@ intel_region_ttm_resource_to_rsgt(struct
intel_memory_region *mem,
*/
struct ttm_resource *
intel_region_ttm_resource_alloc(struct intel_memory_region *mem,
+ resource_size_t offset,
resource_size_t size,
unsigned int flags)
{
@@ -202,7 +204,10 @@ intel_region_ttm_resource_alloc(struct intel_memory_region
*mem,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
[Intel-gfx] [PATCH 3/8] drm/i915: add i915_gem_object_create_region_at()
Add a generic interface for allocating an object at some specific
offset, and convert stolen over. Later we will want to hook this up to
different backends.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/display/intel_plane_initial.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 42 --
drivers/gpu/drm/i915/gem/i915_gem_region.h| 7 ++
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 82 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 4 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 1 +
drivers/gpu/drm/i915/gt/intel_rc6.c | 8 +-
drivers/gpu/drm/i915/intel_memory_region.h| 1 +
drivers/gpu/drm/i915/selftests/mock_region.c | 1 +
12 files changed, 80 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index e207d12286b5..5227e5b35206 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -3,6 +3,7 @@
* Copyright © 2021 Intel Corporation
*/
+#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "intel_atomic_plane.h"
#include "intel_display.h"
@@ -69,7 +70,8 @@ initial_plane_vma(struct drm_i915_private *i915,
size * 2 > i915->stolen_usable_size)
return NULL;
- obj = i915_gem_object_create_stolen_for_preallocated(i915, base, size);
+ obj = i915_gem_object_create_region_at(i915->mm.stolen_region,
+ base, size, 0);
if (IS_ERR(obj))
return NULL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index c6eb023d3d86..5802692ea604 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -123,7 +123,7 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
*/
flags = I915_BO_ALLOC_USER;
- ret = mr->ops->init_object(mr, obj, size, 0, flags);
+ ret = mr->ops->init_object(mr, obj, I915_BO_INVALID_OFFSET, size, 0,
flags);
if (ret)
goto object_free;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 6cf94469d5a8..460a6924e611 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -27,11 +27,12 @@ void i915_gem_object_release_memory_region(struct
drm_i915_gem_object *obj)
mutex_unlock(&mem->objects.lock);
}
-struct drm_i915_gem_object *
-i915_gem_object_create_region(struct intel_memory_region *mem,
- resource_size_t size,
- resource_size_t page_size,
- unsigned int flags)
+static struct drm_i915_gem_object *
+__i915_gem_object_create_region(struct intel_memory_region *mem,
+ resource_size_t offset,
+ resource_size_t size,
+ resource_size_t page_size,
+ unsigned int flags)
{
struct drm_i915_gem_object *obj;
resource_size_t default_page_size;
@@ -83,7 +84,7 @@ i915_gem_object_create_region(struct intel_memory_region *mem,
if (default_page_size < mem->min_page_size)
flags |= I915_BO_ALLOC_PM_EARLY;
- err = mem->ops->init_object(mem, obj, size, page_size, flags);
+ err = mem->ops->init_object(mem, obj, offset, size, page_size, flags);
if (err)
goto err_object_free;
@@ -95,6 +96,35 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
return ERR_PTR(err);
}
+struct drm_i915_gem_object *
+i915_gem_object_create_region(struct intel_memory_region *mem,
+ resource_size_t size,
+ resource_size_t page_size,
+ unsigned int flags)
+{
+ return __i915_gem_object_create_region(mem, I915_BO_INVALID_OFFSET,
+ size, page_size, flags);
+}
+
+struct drm_i915_gem_object *
+i915_gem_object_create_region_at(struct intel_memory_region *mem,
+resource_size_t offset,
+resource_size_t size,
+unsigned int flags)
+{
+ GEM_BUG_ON(offset == I915_BO_INVALID_OFFSET);
+
+ if (GEM_WARN_ON(!IS_ALIGNED(size, mem->min_page_size)) ||
+ GEM_WARN_ON(!IS_ALIGNED(offset, mem->min_page_size)))
+ return ERR_PTR(-EINVAL);
+
+ if (range_overflows(offset, size, resource_size(&mem->region)))
+ return ERR_PTR(-EINVAL);
+
+ return __i915_
[Intel-gfx] [PATCH 2/8] drm/i915/stolen: don't treat small BAR as an error
From: Akeem G Abodunrin
On client platforms with reduced LMEM BAR, we should be able to continue
with driver load with reduced io_size. Instead of using the BAR size to
determine the how large stolen should be, we should instead use the
ADDR_RANGE register to figure this out(at least on platforms like DG2).
For simplicity we don't attempt to support partially mappable stolen.
Signed-off-by: Akeem G Abodunrin
Co-developed-by: Matthew Auld
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 49 --
drivers/gpu/drm/i915/i915_reg.h| 3 ++
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 0bf8f61134af..c9ad4f8c4eaf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -12,6 +12,8 @@
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_region_lmem.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
#include "i915_reg.h"
@@ -750,9 +752,9 @@ static int init_stolen_lmem(struct intel_memory_region *mem)
if (GEM_WARN_ON(resource_size(&mem->region) == 0))
return -ENODEV;
- if (!io_mapping_init_wc(&mem->iomap,
- mem->io_start,
- mem->io_size))
+ if (mem->io_size && !io_mapping_init_wc(&mem->iomap,
+ mem->io_start,
+ mem->io_size))
return -EIO;
/*
@@ -773,7 +775,8 @@ static int init_stolen_lmem(struct intel_memory_region *mem)
static int release_stolen_lmem(struct intel_memory_region *mem)
{
- io_mapping_fini(&mem->iomap);
+ if (mem->io_size)
+ io_mapping_fini(&mem->iomap);
i915_gem_cleanup_stolen(mem->i915);
return 0;
}
@@ -790,25 +793,44 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
{
struct intel_uncore *uncore = &i915->uncore;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ resource_size_t dsm_size, dsm_base, lmem_size;
struct intel_memory_region *mem;
+ resource_size_t io_start, io_size;
resource_size_t min_page_size;
- resource_size_t io_start;
- resource_size_t lmem_size;
- u64 lmem_base;
- lmem_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
- if (GEM_WARN_ON(lmem_base >= pci_resource_len(pdev, 2)))
+ if (WARN_ON_ONCE(instance))
return ERR_PTR(-ENODEV);
- lmem_size = pci_resource_len(pdev, 2) - lmem_base;
- io_start = pci_resource_start(pdev, 2) + lmem_base;
+ /* Use DSM base address instead for stolen memory */
+ dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
+ if (IS_DG1(uncore->i915)) {
+ lmem_size = pci_resource_len(pdev, 2);
+ } else {
+ resource_size_t lmem_range;
+
+ lmem_range = intel_gt_read_register(&i915->gt0,
XEHPSDV_TILE0_ADDR_RANGE) & 0x;
+ lmem_size = lmem_range >> XEHPSDV_TILE_LMEM_RANGE_SHIFT;
+ lmem_size *= SZ_1G;
+ }
+
+ dsm_size = lmem_size - dsm_base;
+ if (pci_resource_len(pdev, 2) < lmem_size) {
+ if (GEM_WARN_ON(IS_DG1(uncore->i915)))
+ return ERR_PTR(-ENODEV);
+
+ io_start = 0;
+ io_size = 0;
+ } else {
+ io_start = pci_resource_start(pdev, 2) + dsm_base;
+ io_size = dsm_size;
+ }
min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K :
I915_GTT_PAGE_SIZE_4K;
- mem = intel_memory_region_create(i915, lmem_base, lmem_size,
+ mem = intel_memory_region_create(i915, dsm_base, dsm_size,
min_page_size,
-io_start, lmem_size,
+io_start, io_size,
type, instance,
&i915_region_stolen_lmem_ops);
if (IS_ERR(mem))
@@ -822,6 +844,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
drm_dbg(&i915->drm, "Stolen Local memory IO start: %pa\n",
&mem->io_start);
+ drm_dbg(&i915->drm, "Stolen Local DSM base: %pa\n", &dsm_base);
intel_memory_region_set_name(mem, "stolen-local");
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 70484f6f2b8b..8ce2eaa002fa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8466,6 +8466,9 @@ enum skl_power_gate {
#define SGGI_DIS REG_BIT(15)
#define SGR_DIS REG_BIT(13)
+#define XE
[Intel-gfx] [PATCH 1/8] drm/i915/lmem: don't treat small BAR as an error
Just pass along the probed io_size. The backend should be able to utilize the entire range here, even if some of it is non-mappable. It does leave open with what to do with stolen local-memory. Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c b/drivers/gpu/drm/i915/gt/intel_region_lmem.c index 6cecfdae07ad..783d81072c3b 100644 --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c @@ -93,6 +93,7 @@ static struct intel_memory_region *setup_lmem(struct intel_gt *gt) struct intel_memory_region *mem; resource_size_t min_page_size; resource_size_t io_start; + resource_size_t io_size; resource_size_t lmem_size; int err; @@ -124,7 +125,8 @@ static struct intel_memory_region *setup_lmem(struct intel_gt *gt) io_start = pci_resource_start(pdev, 2); - if (GEM_WARN_ON(lmem_size > pci_resource_len(pdev, 2))) + io_size = min(pci_resource_len(pdev, 2), lmem_size); + if (!io_size) return ERR_PTR(-ENODEV); min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K : @@ -134,7 +136,7 @@ static struct intel_memory_region *setup_lmem(struct intel_gt *gt) lmem_size, min_page_size, io_start, -lmem_size, +io_size, INTEL_MEMORY_LOCAL, 0, &intel_region_lmem_ops); -- 2.34.1
[Intel-gfx] [PATCH 0/8] Some more bits for small BAR enabling
The leftover bits around dealing with stolen-local memory + small BAR, plus some related fixes. -- 2.34.1
Re: [Intel-gfx] [CI 2/2] drm/i915: limit the async bind to bind_async_flags
On Fri, 2022-03-04 at 09:59 +, Matthew Auld wrote:
> If the vm doesn't request async binding, like for example with the
> dpt,
> then we should be able to skip the async path and avoid calling
> i915_vm_lock_objects() altogether. Currently if we have a moving
> fence
> set for the BO(even though it might have signalled), we still take
> the
> async patch regardless of the bind_async setting, and then later
> still
> end up just doing i915_gem_object_wait_moving_fence() anyway.
>
> Alternatively we would need to add dummy scratch object which can be
> locked, just for the dpt.
>
> Suggested-by: Thomas Hellström
> Signed-off-by: Matthew Auld
> Cc: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/i915_vma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c
> b/drivers/gpu/drm/i915/i915_vma.c
> index 94fcdb7bd21d..4d4d3659c938 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -1360,8 +1360,7 @@ int i915_vma_pin_ww(struct i915_vma *vma,
> struct i915_gem_ww_ctx *ww,
> if (flags & PIN_GLOBAL)
> wakeref = intel_runtime_pm_get(&vma->vm->i915-
> >runtime_pm);
>
> - moving = vma->obj ?
Is there a chance that "moving" will be used uninitialized later?
> i915_gem_object_get_moving_fence(vma->obj) : NULL;
> - if (flags & vma->vm->bind_async_flags || moving) {
> + if (flags & vma->vm->bind_async_flags) {
> /* lock VM */
> err = i915_vm_lock_objects(vma->vm, ww);
> if (err)
> @@ -1375,6 +1374,7 @@ int i915_vma_pin_ww(struct i915_vma *vma,
> struct i915_gem_ww_ctx *ww,
>
> work->vm = i915_vm_get(vma->vm);
>
> + moving = vma->obj ?
> i915_gem_object_get_moving_fence(vma->obj) : NULL;
IIRC, with Maarten's recent changes, vma->obj is always non-NULL.
Otherwise LGTM.
Reviewed-by: Thomas Hellström
> dma_fence_work_chain(&work->base, moving);
>
> /* Allocate enough page directories to used PTE */
/Thomas
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Bump DMC to v2.16 on ADL-P (rev2)
On Fri, Mar 04, 2022 at 12:08:43PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Bump DMC to v2.16 on ADL-P (rev2)
> URL : https://patchwork.freedesktop.org/series/100666/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22480_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Applied to drm-intel-next; thanks for the patch and review.
Matt
>
>
>
> Participating hosts (13 -> 13)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_22480_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@api_intel_allocator@fork-simple-stress-signal:
> - {shard-dg1}:[PASS][1] -> [TIMEOUT][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-dg1-15/igt@api_intel_alloca...@fork-simple-stress-signal.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-dg1-16/igt@api_intel_alloca...@fork-simple-stress-signal.html
>
> * igt@gem_exec_fence@invalid-fence-array:
> - {shard-rkl}:[PASS][3] -> [INCOMPLETE][4] +1 similar issue
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-rkl-1/igt@gem_exec_fe...@invalid-fence-array.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-rkl-5/igt@gem_exec_fe...@invalid-fence-array.html
>
> *
> {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale}:
> - shard-iclb: [PASS][5] -> [SKIP][6] +2 similar issues
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
>
> * igt@prime_mmap@test_forked:
> - {shard-dg1}:NOTRUN -> [SKIP][7] +1 similar issue
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-dg1-19/igt@prime_mmap@test_forked.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_22480_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-apl: ([PASS][8], [PASS][9], [PASS][10], [PASS][11],
> [PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17],
> [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23],
> [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
> [PASS][30], [PASS][31], [PASS][32]) ([i915#4386]) -> ([PASS][33], [PASS][34],
> [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40],
> [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46],
> [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
> [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
>[23]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
>[24]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
>[25]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
>[26]:
> https://intel-gfx-ci.01.org/tree/drm-ti
Re: [Intel-gfx] [igt-dev] [PATCH v2 i-g-t] lib/intel_mmio: Fix mmapped resources not unmapped on fini
Hi Kamil,
Thanks for review.
On Friday, 4 March 2022 16:14:05 CET Kamil Konieczny wrote:
> Hi Janusz,
>
> Dnia 2022-03-01 at 15:07:55 +0100, Janusz Krzysztofik napisał(a):
> > Commit 5f3cfa485eb4 ("lib: Use safe wrappers around libpciaccess
> > initialization functions") took care of not leaking memory allocated by
> > pci_system_init() but didn't take care of users potentially attempting to
> > reinitialize global data maintained by libpciaccess. For example,
> > intel_register_access_init() mmaps device's PCI BAR0 resource with
> > pci_device_map_range() but intel_register_access_fini() doesn't unmap it
> > and next call to intel_register_access_init() fails on attempt to mmap it
> > again with pci_device_map_range().
> -- ^
> imho you can cut here, no need to repeat it twice.
OK
> >
> > Fix it, and also provide intel_mmio_umap_*() counterparts to public
> -- ^
> s/umap/unmap/
Thanks.
> > functions intel_mmio_use_pci_bar() and intel_mmio_use_dump_file().
> >
> > v2: apply last minute fixes, cached but unfortunately not committed before
> > sending
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > lib/intel_io.h | 4 +++
> > lib/intel_mmio.c | 67 ++--
> > 2 files changed, 63 insertions(+), 8 deletions(-)
> >
> > diff --git a/lib/intel_io.h b/lib/intel_io.h
> > index 1cfe4fb6b9..ea2649d9bc 100644
> > --- a/lib/intel_io.h
> > +++ b/lib/intel_io.h
> > @@ -49,6 +49,8 @@ struct intel_register_map {
> >
> > struct intel_mmio_data {
> > void *igt_mmio;
> > + size_t mmio_size;
> > + struct pci_device *dev;
> > struct intel_register_map map;
> > uint32_t pci_device_id;
> > int key;
> > @@ -57,7 +59,9 @@ struct intel_mmio_data {
> >
> > void intel_mmio_use_pci_bar(struct intel_mmio_data *mmio_data,
> > struct pci_device *pci_dev);
> > +void intel_mmio_unmap_pci_bar(struct intel_mmio_data *mmio_data);
> > void intel_mmio_use_dump_file(struct intel_mmio_data *mmio_data, char
> > *file);
> > +void intel_mmio_unmap_dump_file(struct intel_mmio_data *mmio_data);
> >
> > int intel_register_access_init(struct intel_mmio_data *mmio_data,
> >struct pci_device *pci_dev, int safe, int fd);
> > diff --git a/lib/intel_mmio.c b/lib/intel_mmio.c
> > index 667a69f5aa..cb8f9db2e5 100644
> > --- a/lib/intel_mmio.c
> > +++ b/lib/intel_mmio.c
> > @@ -82,6 +82,8 @@ void *igt_global_mmio;
> > * Sets also up mmio_data->igt_mmio to point at the data contained
> > * in @file. This allows the same code to get reused for dumping and
> > decoding
> > * from running hardware as from register dumps.
> > + *
> > + * Users are expected to call intel_mmio_unmap_dump_file() after use.
> > */
> > void
> > intel_mmio_use_dump_file(struct intel_mmio_data *mmio_data, char *file)
> > @@ -99,11 +101,29 @@ intel_mmio_use_dump_file(struct intel_mmio_data
> > *mmio_data, char *file)
>
> imho at beginning of this function there should be check
> that igt_global_mmio == NULL, and the same check should be at
> other init functions.
No, what I think needs to be fixed are users who are still using
igt_global_mmio while they should use the value they passed as the mmio
argument to intel_mmio_use_*() or intel_register_access_init(), and that
global variable should be dropped. But first of all, that's not related to
the issue this patch is trying to fix, then out of scope of this patch.
> Looks like we cannot mmap two different pcie cards at the same
> time with this lib.
We can, if we just ignore that depreciated global variable, I believe.
> > igt_fail_on_f(mmio_data->igt_mmio == MAP_FAILED,
> > "Couldn't mmap %s\n", file);
> >
> > + mmio_data->mmio_size = st.st_size;
> > igt_global_mmio = mmio_data->igt_mmio;
> >
> > close(fd);
> > }
> >
> > +/**
> > + * intel_mmio_unmap_dump_file:
> > + * @mmio_data: mmio structure for IO operations
> > + *
> > + * Unmaps a dump file mmapped with intel_mmio_use_dump_file()
> > + */
> > +void intel_mmio_unmap_dump_file(struct intel_mmio_data *mmio_data)
> > +{
> > + if (igt_warn_on_f(!mmio_data->mmio_size || mmio_data->dev,
> > + "test bug: argument doesn't point to struct
> > intel_mmio_data initialized with intel_mmio_use_dump_file()\n"))
>
> Please shorten text for warning, something like: arg was not
> inialized with ...
OK
> Please also add check for null at global var.
>
> > + return;
> > +
> > + igt_global_mmio = NULL;
> > + igt_debug_on(munmap(mmio_data->igt_mmio, mmio_data->mmio_size) < 0);
> > + mmio_data->mmio_size = 0;
> > +}
> > +
> > /**
> > * intel_mmio_use_pci_bar:
> > * @mmio_data: mmio structure for IO operations
> > @@ -112,12 +132,14 @@ intel_mmio_use_dump_file(struct intel_mmio_data
> > *mmio_data, char *file)
> > * Fill a mmio_data stucture with igt_mmio to point at the mmio bar.
> > *
> > * @pci_dev ca
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/xehp: Support platforms with CCS engines but no RCS
On Fri, Mar 04, 2022 at 01:45:31PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/xehp: Support platforms with CCS
> engines but no RCS
> URL : https://patchwork.freedesktop.org/series/101019/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11321_full -> Patchwork_22481_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Patches applied to drm-intel-gt-next; thanks for the reviews.
Matt
>
>
>
> Participating hosts (13 -> 13)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_22481_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@api_intel_allocator@fork-simple-stress-signal:
> - {shard-dg1}:[PASS][1] -> [TIMEOUT][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-12/igt@api_intel_alloca...@fork-simple-stress-signal.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-17/igt@api_intel_alloca...@fork-simple-stress-signal.html
>
> * igt@gem_ctx_sseu@mmap-args:
> - {shard-dg1}:[SKIP][3] ([i915#280]) -> [SKIP][4]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@gem_ctx_s...@mmap-args.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gem_ctx_s...@mmap-args.html
>
> * igt@gem_exec_fence@nb-await:
> - {shard-dg1}:NOTRUN -> [FAIL][5]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gem_exec_fe...@nb-await.html
>
> * igt@gem_exec_reloc@basic-write-cpu-active:
> - {shard-dg1}:[SKIP][6] ([i915#3281]) -> [SKIP][7]
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@gem_exec_re...@basic-write-cpu-active.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gem_exec_re...@basic-write-cpu-active.html
>
> * igt@gen9_exec_parse@allowed-single:
> - {shard-dg1}:[SKIP][8] ([i915#2527]) -> [SKIP][9]
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@gen9_exec_pa...@allowed-single.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gen9_exec_pa...@allowed-single.html
>
> * igt@kms_3d:
> - {shard-dg1}:[PASS][10] -> [SKIP][11] +26 similar issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_3d.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_3d.html
>
> * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0:
> - {shard-dg1}:[PASS][12] -> [FAIL][13] +2 similar issues
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-0.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-0.html
>
> * igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen:
> - {shard-dg1}:[SKIP][14] ([i915#3359]) -> [SKIP][15]
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_cursor_...@pipe-a-cursor-512x512-offscreen.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_cursor_...@pipe-a-cursor-512x512-offscreen.html
>
> *
> {igt@kms_plane_scaling@downscale-with-rotation-factor-0-5@pipe-c-hdmi-a-1-downscale-with-rotation}:
> - {shard-dg1}:[SKIP][16] ([i915#5176]) -> [SKIP][17] +3 similar
> issues
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_plane_scaling@downscale-with-rotation-factor-...@pipe-c-hdmi-a-1-downscale-with-rotation.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_plane_scaling@downscale-with-rotation-factor-...@pipe-c-hdmi-a-1-downscale-with-rotation.html
>
> *
> {igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
> - {shard-rkl}:NOTRUN -> [SKIP][18]
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-rkl-6/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html
>
> * igt@perf_pmu@busy-double-start:
> - {shard-dg1}:NOTRUN -> [SKIP][19] +1 similar issue
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@perf_...@busy-double-start.html
>
> * igt@prime_vgem@basic-read:
> - {shard-dg1}:[SKIP][20] ([i915#3708]) -> [SKIP][21]
>[20]
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev5)
== Series Details ==
Series: drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev5)
URL : https://patchwork.freedesktop.org/series/98801/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11322_full -> Patchwork_22484_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22484_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22484_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22484_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3@smem:
- shard-snb: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-snb5/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/shard-snb6/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-tglb2/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/shard-tglb6/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_schedule@deep@vcs0:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/shard-rkl-5/igt@gem_exec_schedule@d...@vcs0.html
* igt@prime_mmap_coherency@ioctl-errors:
- {shard-dg1}:NOTRUN -> [SKIP][6] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22484/shard-dg1-12/igt@prime_mmap_cohere...@ioctl-errors.html
Known issues
Here are the changes found in Patchwork_22484_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-apl: ([PASS][7], [FAIL][8], [PASS][9], [PASS][10],
[PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16],
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22],
[PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28],
[PASS][29], [PASS][30], [PASS][31]) ([i915#4386]) -> ([PASS][32], [PASS][33],
[PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39],
[PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45],
[PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51],
[PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl7/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl7/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl7/boot.html
[29]:
https://intel-
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gmbus: use to_intel_gmbus() instead of open coding
On Fri, Mar 04, 2022 at 12:14:26PM +0200, Jani Nikula wrote:
> We have a helper for getting at the enclosing gmbus struct from the
> embedded i2c_adapter, use it.
>
> Signed-off-by: Jani Nikula
Series is
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_gmbus.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index 8f26528c3dc7..21281a7bdc17 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -300,9 +300,7 @@ static void set_data(void *data, int state_high)
> static int
> intel_gpio_pre_xfer(struct i2c_adapter *adapter)
> {
> - struct intel_gmbus *bus = container_of(adapter,
> -struct intel_gmbus,
> -adapter);
> + struct intel_gmbus *bus = to_intel_gmbus(adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
>
> intel_gmbus_reset(dev_priv);
> @@ -319,9 +317,7 @@ intel_gpio_pre_xfer(struct i2c_adapter *adapter)
> static void
> intel_gpio_post_xfer(struct i2c_adapter *adapter)
> {
> - struct intel_gmbus *bus = container_of(adapter,
> -struct intel_gmbus,
> -adapter);
> + struct intel_gmbus *bus = to_intel_gmbus(adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
>
> set_data(bus, 1);
> @@ -619,9 +615,7 @@ static int
> do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
> u32 gmbus0_source)
> {
> - struct intel_gmbus *bus = container_of(adapter,
> -struct intel_gmbus,
> -adapter);
> + struct intel_gmbus *bus = to_intel_gmbus(adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
> int i = 0, inc, try = 0;
> int ret = 0;
> @@ -751,8 +745,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg
> *msgs, int num,
> static int
> gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
> {
> - struct intel_gmbus *bus =
> - container_of(adapter, struct intel_gmbus, adapter);
> + struct intel_gmbus *bus = to_intel_gmbus(adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
> intel_wakeref_t wakeref;
> int ret;
> @@ -776,8 +769,7 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg
> *msgs, int num)
>
> int intel_gmbus_output_aksv(struct i2c_adapter *adapter)
> {
> - struct intel_gmbus *bus =
> - container_of(adapter, struct intel_gmbus, adapter);
> + struct intel_gmbus *bus = to_intel_gmbus(adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
> u8 cmd = DRM_HDCP_DDC_AKSV;
> u8 buf[DRM_HDCP_KSV_LEN] = { 0 };
> --
> 2.30.2
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg2: Add preemption changes for Wa_14015141709
== Series Details ==
Series: drm/i915/dg2: Add preemption changes for Wa_14015141709
URL : https://patchwork.freedesktop.org/series/101023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11322_full -> Patchwork_22483_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22483_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
*
{igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-rkl-6/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html
* igt@prime_mmap_coherency@ioctl-errors:
- {shard-dg1}:NOTRUN -> [SKIP][2] +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-dg1-15/igt@prime_mmap_cohere...@ioctl-errors.html
Known issues
Here are the changes found in Patchwork_22483_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-apl: ([PASS][3], [FAIL][4], [PASS][5], [PASS][6],
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26], [PASS][27]) ([i915#4386]) -> ([PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47],
[PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl7/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl7/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl7/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl8/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl8/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl8/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl1/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl2/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl2/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl2/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl3/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22483/shard-apl3/boot.html
[36]:
https://intel-gf
Re: [Intel-gfx] [igt-dev] [PATCH v2 i-g-t] lib/intel_mmio: Fix mmapped resources not unmapped on fini
Hi Janusz,
Dnia 2022-03-01 at 15:07:55 +0100, Janusz Krzysztofik napisał(a):
> Commit 5f3cfa485eb4 ("lib: Use safe wrappers around libpciaccess
> initialization functions") took care of not leaking memory allocated by
> pci_system_init() but didn't take care of users potentially attempting to
> reinitialize global data maintained by libpciaccess. For example,
> intel_register_access_init() mmaps device's PCI BAR0 resource with
> pci_device_map_range() but intel_register_access_fini() doesn't unmap it
> and next call to intel_register_access_init() fails on attempt to mmap it
> again with pci_device_map_range().
-- ^
imho you can cut here, no need to repeat it twice.
>
> Fix it, and also provide intel_mmio_umap_*() counterparts to public
-- ^
s/umap/unmap/
> functions intel_mmio_use_pci_bar() and intel_mmio_use_dump_file().
>
> v2: apply last minute fixes, cached but unfortunately not committed before
> sending
>
> Signed-off-by: Janusz Krzysztofik
> ---
> lib/intel_io.h | 4 +++
> lib/intel_mmio.c | 67 ++--
> 2 files changed, 63 insertions(+), 8 deletions(-)
>
> diff --git a/lib/intel_io.h b/lib/intel_io.h
> index 1cfe4fb6b9..ea2649d9bc 100644
> --- a/lib/intel_io.h
> +++ b/lib/intel_io.h
> @@ -49,6 +49,8 @@ struct intel_register_map {
>
> struct intel_mmio_data {
> void *igt_mmio;
> + size_t mmio_size;
> + struct pci_device *dev;
> struct intel_register_map map;
> uint32_t pci_device_id;
> int key;
> @@ -57,7 +59,9 @@ struct intel_mmio_data {
>
> void intel_mmio_use_pci_bar(struct intel_mmio_data *mmio_data,
> struct pci_device *pci_dev);
> +void intel_mmio_unmap_pci_bar(struct intel_mmio_data *mmio_data);
> void intel_mmio_use_dump_file(struct intel_mmio_data *mmio_data, char *file);
> +void intel_mmio_unmap_dump_file(struct intel_mmio_data *mmio_data);
>
> int intel_register_access_init(struct intel_mmio_data *mmio_data,
> struct pci_device *pci_dev, int safe, int fd);
> diff --git a/lib/intel_mmio.c b/lib/intel_mmio.c
> index 667a69f5aa..cb8f9db2e5 100644
> --- a/lib/intel_mmio.c
> +++ b/lib/intel_mmio.c
> @@ -82,6 +82,8 @@ void *igt_global_mmio;
> * Sets also up mmio_data->igt_mmio to point at the data contained
> * in @file. This allows the same code to get reused for dumping and decoding
> * from running hardware as from register dumps.
> + *
> + * Users are expected to call intel_mmio_unmap_dump_file() after use.
> */
> void
> intel_mmio_use_dump_file(struct intel_mmio_data *mmio_data, char *file)
> @@ -99,11 +101,29 @@ intel_mmio_use_dump_file(struct intel_mmio_data
> *mmio_data, char *file)
imho at beginning of this function there should be check
that igt_global_mmio == NULL, and the same check should be at
other init functions.
Looks like we cannot mmap two different pcie cards at the same
time with this lib.
> igt_fail_on_f(mmio_data->igt_mmio == MAP_FAILED,
> "Couldn't mmap %s\n", file);
>
> + mmio_data->mmio_size = st.st_size;
> igt_global_mmio = mmio_data->igt_mmio;
>
> close(fd);
> }
>
> +/**
> + * intel_mmio_unmap_dump_file:
> + * @mmio_data: mmio structure for IO operations
> + *
> + * Unmaps a dump file mmapped with intel_mmio_use_dump_file()
> + */
> +void intel_mmio_unmap_dump_file(struct intel_mmio_data *mmio_data)
> +{
> + if (igt_warn_on_f(!mmio_data->mmio_size || mmio_data->dev,
> + "test bug: argument doesn't point to struct
> intel_mmio_data initialized with intel_mmio_use_dump_file()\n"))
Please shorten text for warning, something like: arg was not
inialized with ...
Please also add check for null at global var.
> + return;
> +
> + igt_global_mmio = NULL;
> + igt_debug_on(munmap(mmio_data->igt_mmio, mmio_data->mmio_size) < 0);
> + mmio_data->mmio_size = 0;
> +}
> +
> /**
> * intel_mmio_use_pci_bar:
> * @mmio_data: mmio structure for IO operations
> @@ -112,12 +132,14 @@ intel_mmio_use_dump_file(struct intel_mmio_data
> *mmio_data, char *file)
> * Fill a mmio_data stucture with igt_mmio to point at the mmio bar.
> *
> * @pci_dev can be obtained from intel_get_pci_device().
> + *
> + * Users are expected to call intel_mmio_unmap_pci_bar() after use.
> */
> void
> intel_mmio_use_pci_bar(struct intel_mmio_data *mmio_data, struct pci_device
> *pci_dev)
> {
> uint32_t devid, gen;
> - int mmio_bar, mmio_size;
> + int mmio_bar;
Please use this local var and assign it to struct only after
succesfull initialization.
> int error;
>
> memset(mmio_data, 0, sizeof(struct intel_mmio_data));
> @@ -129,22 +151,42 @@ intel_mmio_use_pci_bar(struct intel_mmio_data
> *mmio_data, struct pci_device *pci
>
> gen = intel_gen(devid);
> if (gen < 3)
> - mmio_size = 512*1024;
> + mmio_data->mmio_size = 512*10
Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Make the PIPESC rect relative to the entire bigjoiner area
On Thu, Mar 03, 2022 at 02:41:23PM -0800, Navare, Manasi wrote:
> On Wed, Feb 23, 2022 at 03:13:15PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When using bigjoiner it's useful to know the offset of each
> > individual pipe in the whole set of joined pipes. Let's include
> > that information in our PIPESRC rectangle. With this we can make
> > the plane clipping code blissfully unaware of bigjoiner usage, as
> > all we have to do is remove the pipe's offset from the final plane
> > destination coordinates.
> >
> > v2: Use intel_bigjoiner_num_pipes()
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 7 +++---
> > drivers/gpu/drm/i915/display/intel_cursor.c | 8 ---
> > drivers/gpu/drm/i915/display/intel_display.c | 21 ++
> > drivers/gpu/drm/i915/display/intel_overlay.c | 22 +--
> > 4 files changed, 40 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 3cbf66146da0..92ae4eebc62f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -824,10 +824,6 @@ int intel_atomic_plane_check_clipping(struct
> > intel_plane_state *plane_state,
> > return -ERANGE;
> > }
> >
> > - /* right side of the image is on the slave crtc, adjust dst to match */
> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > - drm_rect_translate(dst, -drm_rect_width(&crtc_state->pipe_src),
> > 0);
> > -
> > /*
> > * FIXME: This might need further adjustment for seamless scaling
> > * with phase information, for the 2p2 and 2p1 scenarios.
> > @@ -844,6 +840,9 @@ int intel_atomic_plane_check_clipping(struct
> > intel_plane_state *plane_state,
> > return -EINVAL;
> > }
> >
> > + /* final plane coordinates will be relative to the plane's pipe */
> > + drm_rect_translate(dst, -clip->x1, -clip->y1);
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index da6cf0515164..9279e2783e7e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -152,9 +152,11 @@ static int intel_check_cursor(struct intel_crtc_state
> > *crtc_state,
> > /* Use the unclipped src/dst rectangles, which we program to hw */
> > plane_state->uapi.src = src;
> > plane_state->uapi.dst = dst;
> > - if (intel_crtc_is_bigjoiner_slave(crtc_state))
> > - drm_rect_translate(&plane_state->uapi.dst,
> > - -drm_rect_width(&crtc_state->pipe_src), 0);
> > +
> > + /* final plane coordinates will be relative to the plane's pipe */
> > + drm_rect_translate(&plane_state->uapi.dst,
> > + -crtc_state->pipe_src.x1,
> > + -crtc_state->pipe_src.y1);
> >
> > ret = intel_cursor_check_surface(plane_state);
> > if (ret)
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 7a09bb33c1eb..a9c15f27b948 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3204,6 +3204,23 @@ static void intel_get_transcoder_timings(struct
> > intel_crtc *crtc,
> > }
> > }
> >
> > +static void intel_bigjoiner_adjust_pipe_src(struct intel_crtc_state
> > *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
> > + enum pipe master_pipe, pipe = crtc->pipe;
> > + int width;
> > +
> > + if (num_pipes < 2)
> > + return;
> > +
> > + master_pipe = bigjoiner_master_pipe(crtc_state);
> > + width = drm_rect_width(&crtc_state->pipe_src);
> > +
> > + drm_rect_translate_to(&crtc_state->pipe_src,
> > + (pipe - master_pipe) * width, 0);
> > +}
> > +
> > static void intel_get_pipe_src_size(struct intel_crtc *crtc,
> > struct intel_crtc_state *pipe_config)
> > {
> > @@ -3216,6 +3233,8 @@ static void intel_get_pipe_src_size(struct intel_crtc
> > *crtc,
> > drm_rect_init(&pipe_config->pipe_src, 0, 0,
> > REG_FIELD_GET(PIPESRC_WIDTH_MASK, tmp) + 1,
> > REG_FIELD_GET(PIPESRC_HEIGHT_MASK, tmp) + 1);
> > +
> > + intel_bigjoiner_adjust_pipe_src(pipe_config);
> > }
> >
> > static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state)
> > @@ -5853,6 +5872,8 @@ intel_modeset_pipe_config_late(struct
> > intel_crtc_state *crtc_state)
> > struct drm_connector *connector;
> > int i;
> >
> > + intel_bigjoiner_adjust_pipe_src(crtc_state);
> > +
> > for_each_new_connector_in_state(&state->base, connector,
> >
[Intel-gfx] ✗ Fi.CI.IGT: failure for Improve anti-pre-emption w/a for compute workloads (rev4)
== Series Details ==
Series: Improve anti-pre-emption w/a for compute workloads (rev4)
URL : https://patchwork.freedesktop.org/series/100428/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11322_full -> Patchwork_22482_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22482_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22482_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22482_full:
### IGT changes ###
Possible regressions
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-upscaling:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-tglb1/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-16bpp-ytile-upscaling.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/shard-tglb8/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-16bpp-ytile-upscaling.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@basic@vcs0:
- {shard-rkl}:NOTRUN -> [DMESG-WARN][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/shard-rkl-5/igt@gem_exec_parallel@ba...@vcs0.html
*
{igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-25@pipe-d-hdmi-a-1-downscale-with-pixel-format}:
- {shard-tglu}: NOTRUN -> [SKIP][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/shard-tglu-5/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-d-hdmi-a-1-downscale-with-pixel-format.html
*
{igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale}:
- shard-iclb: [PASS][5] -> [SKIP][6] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-iclb5/igt@kms_plane_scaling@planes-downscale-factor-...@pipe-a-edp-1-planes-downscale.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/shard-iclb2/igt@kms_plane_scaling@planes-downscale-factor-...@pipe-a-edp-1-planes-downscale.html
* igt@prime_mmap_coherency@ioctl-errors:
- {shard-dg1}:NOTRUN -> [SKIP][7] +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22482/shard-dg1-17/igt@prime_mmap_cohere...@ioctl-errors.html
Known issues
Here are the changes found in Patchwork_22482_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-apl: ([PASS][8], [FAIL][9], [PASS][10], [PASS][11],
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17],
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32]) ([i915#4386]) -> ([PASS][33], [PASS][34],
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40],
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46],
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
[PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl3/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl4/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11322/shard-apl6/boot.html
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi, > > Hi, > > > > Hi Abhinav, > > > > > Hi Laurent > > > > > > > > > > Ok sure, I can take this up but I need to understand the > > > > > proposal a little bit more before proceeding on this. So we will > > > > > discuss this in another email where we specifically talk about the > connector changes. > > > > > > > > > > Also, I am willing to take this up once the encoder part is done > > > > > and merged so that atleast we keep moving on that as MSM WB > > > > > implementation can proceed with that first. > > > > > > > > > > Hi Jani and Suraj > > > > > > > > > > Any concerns with splitting up the series into encoder and > > > > > connector OR re- arranging them? > > > > > > > > > > Let me know if you can do this OR I can also split this up > > > > > keeping Suraj's name in the Co-developed by tag. > > > > I was actually thinking of floating a new patch series with both > > > > encoder and connector pointer changes but with a change in > > > > initialization functions wherein we allocate a connector and > > > > encoder incase the driver doesn’t have its own this should > > > > minimize the effect on other drivers already using current drm > > > > writeback framework and also > > > allow i915 to create its own connector. > > > > > > I thought that Laurent was quite strict about the connector. So I'd > > > suggest targeting drm_writeback_connector with an optionally created > > > encoder and the builtin connector > > In that case even if we target that i915 will not be able to move > > forward with its implementation of writeback as builtin connector does > > not work for us right now as explained earlier, optionally creating > > encoder and connector will help everyone move forward and once done > we > > can actually sit and work on how to side step this issue using > > Laurent's suggestion > > This is up to Laurent & other DRM maintainers to decide whether this > approach would be accepted or not. > So far unfortunately I have mostly seen the pushback and a strong > suggestion to stop treating each drm_connector as i915_connector. > I haven't checked the exact details, but IMO adding a branch if the > connector's type is DRM_CONNECTOR_VIRTUAL should be doable. Bringing in the change where we don’t treat each drm_connector as an intel_connector or even adding a branch which checks if drm_connector is DRM_CONNECTOR_VIRTUAL and conditionally cast it to intel_connector is quite a lot of work for i915. That's why I was suggesting if for now we could move forward with optionally creating both encoder and connector minimizing affects on other drivers as well as allowing us to move forward. What do you think, Launrent? > > > > > > > > We can work on Laurent's suggestion but that would first require > > > > the initial RFC patches and then a rework from both of our drivers > > > > side to see if they gel well with our current code which will take > > > > a considerable amount of time. We can for now however float the > > > > patch series up which minimally affects the current drivers and > > > > also allows > > > > i915 and msm to move forward with its writeback implementation off > > > > course with a proper documentation stating new drivers shouldn't > > > > try to > > > make their own connectors and encoders and that drm_writeback will > > > do that for them. > > > > Once that's done and merged we can work with Laurent on his > > > > proposal to improve the drm writeback framework so that this issue > > > > can be side > > > stepped entirely in future. > > > > For now I would like to keep the encoder and connector pointer > > > > changes > > > together. > > > > > > -- > With best wishes > Dmitry Best Regards, Suraj Kandpal
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/2] drm: Add HPD state to drm_connector_oob_hotplug_event()
== Series Details == Series: series starting with [v2,1/2] drm: Add HPD state to drm_connector_oob_hotplug_event() URL : https://patchwork.freedesktop.org/series/101048/ State : failure == Summary == Applying: drm: Add HPD state to drm_connector_oob_hotplug_event() Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_connector.c M drivers/gpu/drm/i915/display/intel_dp.c M drivers/gpu/drm/i915/i915_drv.h M include/drm/drm_connector.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_connector.h CONFLICT (content): Merge conflict in include/drm/drm_connector.h Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/display/intel_dp.c Auto-merging drivers/gpu/drm/drm_connector.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 drm: Add HPD state to drm_connector_oob_hotplug_event() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH] drm/selftests: fix a shift-out-of-bounds bug
Am 03.03.22 um 21:16 schrieb Arunpravin:
pass the correct size value computed using the max_order.
[ 68.124177][ T1] UBSAN: shift-out-of-bounds in include/linux/log2.h:67:13
[ 68.125333][ T1] shift exponent 4294967295 is too large for 32-bit type 'long
unsigned int'
[ 68.126563][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted
5.17.0-rc2-00311-g39ec47bbfd5d #2
[ 68.127758][ T1] Call Trace:
[ 68.128187][ T1] dump_stack_lvl (lib/dump_stack.c:108)
[ 68.128793][ T1] dump_stack (lib/dump_stack.c:114)
[ 68.129331][ T1] ubsan_epilogue (lib/ubsan.c:152)
[ 68.129958][ T1] __ubsan_handle_shift_out_of_bounds.cold
(arch/x86/include/asm/smap.h:85)
[ 68.130791][ T1] ? drm_block_alloc+0x28/0x80
[ 68.131582][ T1] ? rcu_read_lock_sched_held (kernel/rcu/update.c:125)
[ 68.132215][ T1] ? kmem_cache_alloc (include/trace/events/kmem.h:54
mm/slab.c:3501)
[ 68.132878][ T1] ? mark_free+0x2e/0x80
[ 68.133524][ T1] drm_buddy_init.cold (include/linux/log2.h:67
drivers/gpu/drm/drm_buddy.c:131)
[ 68.134145][ T1] ? test_drm_cmdline_init
(drivers/gpu/drm/selftests/test-drm_buddy.c:87)
[ 68.134770][ T1] igt_buddy_alloc_limit
(drivers/gpu/drm/selftests/test-drm_buddy.c:30)
[ 68.135472][ T1] ? vprintk_default (kernel/printk/printk.c:2257)
[ 68.136057][ T1] ? test_drm_cmdline_init
(drivers/gpu/drm/selftests/test-drm_buddy.c:87)
[ 68.136812][ T1] test_drm_buddy_init
(drivers/gpu/drm/selftests/drm_selftest.c:77
drivers/gpu/drm/selftests/test-drm_buddy.c:95)
[ 68.137475][ T1] do_one_initcall (init/main.c:1300)
[ 68.138111][ T1] ? parse_args (kernel/params.c:609 kernel/params.c:146
kernel/params.c:188)
[ 68.138717][ T1] do_basic_setup (init/main.c:1372 init/main.c:1389
init/main.c:1408)
[ 68.139366][ T1] kernel_init_freeable (init/main.c:1617)
[ 68.140040][ T1] ? rest_init (init/main.c:1494)
[ 68.140634][ T1] kernel_init (init/main.c:1504)
[ 68.141155][ T1] ret_from_fork (arch/x86/entry/entry_32.S:772)
[ 68.141607][ T1]
[ 68.146730][ T1] [ cut here ]
[ 68.147460][ T1] kernel BUG at drivers/gpu/drm/drm_buddy.c:140!
[ 68.148280][ T1] invalid opcode: [#1]
[ 68.148895][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted
5.17.0-rc2-00311-g39ec47bbfd5d #2
[ 68.149896][ T1] EIP: drm_buddy_init (drivers/gpu/drm/drm_buddy.c:140
(discriminator 1))
For more details:
https://lists.01.org/hyperkitty/list/l...@lists.01.org/thread/FDIF3HCILZNN5UQAZMOR7E3MQSMHHKWU/
Signed-off-by: Arunpravin
Reported-by: kernel test robot
Acked-by: Christian König
---
drivers/gpu/drm/selftests/test-drm_buddy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_buddy.c
b/drivers/gpu/drm/selftests/test-drm_buddy.c
index fa997f89522b..913cbd7eae04 100644
--- a/drivers/gpu/drm/selftests/test-drm_buddy.c
+++ b/drivers/gpu/drm/selftests/test-drm_buddy.c
@@ -902,14 +902,13 @@ static int igt_buddy_alloc_range(void *arg)
static int igt_buddy_alloc_limit(void *arg)
{
- u64 end, size = U64_MAX, start = 0;
+ u64 size = U64_MAX, start = 0;
struct drm_buddy_block *block;
unsigned long flags = 0;
LIST_HEAD(allocated);
struct drm_buddy mm;
int err;
- size = end = round_down(size, 4096);
err = drm_buddy_init(&mm, size, PAGE_SIZE);
if (err)
return err;
@@ -921,7 +920,8 @@ static int igt_buddy_alloc_limit(void *arg)
goto out_fini;
}
- err = drm_buddy_alloc_blocks(&mm, start, end, size,
+ size = mm.chunk_size << mm.max_order;
+ err = drm_buddy_alloc_blocks(&mm, start, size, size,
PAGE_SIZE, &allocated, flags);
if (unlikely(err))
base-commit: 6be340ee8f5beae574dae6f5e17a22e67beeff3e
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Thu, 3 Mar 2022 12:18:24 +, Daniel Thompson wrote: > On Thu, Mar 03, 2022 at 03:26:57PM +0800, Xiaomeng Tong wrote: > > On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote: > > > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote: > > > > The problem is the mis-use of iterator outside the loop on exit, and > > > > the iterator will be the HEAD's container_of pointer which pointers > > > > to a type-confused struct. Sidenote: The *mis-use* here refers to > > > > mistakely access to other members of the struct, instead of the > > > > list_head member which acutally is the valid HEAD. > > > > > > The problem is that the HEAD's container_of pointer should never > > > be calculated at all. > > > This is what is fundamentally broken about the current definition. > > > > Yes, the rule is "the HEAD's container_of pointer should never be > > calculated at all outside the loop", but how do you make sure everyone > > follows this rule? > > Your formulation of the rule is correct: never run container_of() on HEAD > pointer. Actually, it is not my rule. My rule is that never access other members of the struct except for the list_head member after the loop, because this is a invalid member after loop exit, but valid for the list_head member which just is HEAD and the lately caculation (&pos->head) seems harmless. I have considered the case that the HEAD's container "pos" is layouted across the max and the min address boundary, which means the address of HEAD is likely 0x60, and the address of pos is likely 0xffe0. It seems ok to caculate pos with: ((type *)(__mptr - offsetof(type, member))); and it seems ok to caculate head outside the loop with: if (&pos->head == &HEAD) return NULL; The only case I can think of with the rule "never run container_of() on HEAD" must be followed is when the first argument (which is &HEAD) passing to container_of() is NULL + some offset, it may lead to the resulting "pos->member" access being a NULL dereference. But maybe the caller can take the responsibility to check if it is NULL, not container_of() itself. Please remind me if i missed somthing, thanks. > > However the rule that is introduced by list_for_each_entry_inside() is > *not* this rule. The rule it introduces is: never access the iterator > variable outside the loop. Sorry for the confusion, indeed, that is two *different* rule. > > Making the iterator NULL on loop exit does follow the rule you proposed > but using a different technique: do not allow HEAD to be stored in the > iterator variable after loop exit. This also makes it impossible to run > container_of() on the HEAD pointer. > It does not. My rule is: never access the iterator variable outside the loop. The "Making the iterator NULL on loop exit" way still leak the pos with NULL outside the loop, may lead to a NULL deference. > > > Everyone makes mistakes, but we can eliminate them all from the beginning > > with the help of compiler which can catch such use-after-loop things. > > Indeed but if we introduce new interfaces then we don't have to worry > about existing usages and silent regressions. Code will have been > written knowing the loop can exit with the iterator set to NULL. Yes, it is more simple and compatible with existing interfaces. Howerver, you should make every developers to remember that "pos will be set NULL on loop exit", which is unreasonable and impossible for *every* single person. Otherwise the mis-use-after-loop will lead to a NULL dereference. But we can kill this problem by declaring iterator inside the loop and the complier will catch it if somebody mis-use-after-loop. > > Sure it is still possible for programmers to make mistakes and > dereference the NULL pointer but C programmers are well training w.r.t. > NULL pointer checking so such mistakes are much less likely than with > the current list_for_each_entry() macro. This risk must be offset > against the way a NULLify approach can lead to more elegant code when we > are doing a list search. > Yes, the NULLify approach is better than the current list_for_each_entry() macro, but i stick with that the list_for_each_entry_inside() way is best and perfect _technically_. Thus, my idea is *better a finger off than always aching*, let's settle this damn problem once and for all, with list_for_each_entry_inside(). -- Xiaomeng Tong
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Fri, 4 Mar 2022 at 13:47, Kandpal, Suraj wrote: > > Hi, > > > Hi Abhinav, > > > > Hi Laurent > > > > > > > > Ok sure, I can take this up but I need to understand the proposal a > > > > little bit more before proceeding on this. So we will discuss this > > > > in another email where we specifically talk about the connector changes. > > > > > > > > Also, I am willing to take this up once the encoder part is done and > > > > merged so that atleast we keep moving on that as MSM WB > > > > implementation can proceed with that first. > > > > > > > > Hi Jani and Suraj > > > > > > > > Any concerns with splitting up the series into encoder and connector > > > > OR re- arranging them? > > > > > > > > Let me know if you can do this OR I can also split this up keeping > > > > Suraj's name in the Co-developed by tag. > > > I was actually thinking of floating a new patch series with both > > > encoder and connector pointer changes but with a change in > > > initialization functions wherein we allocate a connector and encoder > > > incase the driver doesn’t have its own this should minimize the effect > > > on other drivers already using current drm writeback framework and also > > allow i915 to create its own connector. > > > > I thought that Laurent was quite strict about the connector. So I'd suggest > > targeting drm_writeback_connector with an optionally created encoder and > > the builtin connector > In that case even if we target that i915 will not be able to move forward > with its > implementation of writeback as builtin connector does not work for us right > now > as explained earlier, optionally creating encoder and connector will help > everyone > move forward and once done we can actually sit and work on how to side step > this > issue using Laurent's suggestion This is up to Laurent & other DRM maintainers to decide whether this approach would be accepted or not. So far unfortunately I have mostly seen the pushback and a strong suggestion to stop treating each drm_connector as i915_connector. I haven't checked the exact details, but IMO adding a branch if the connector's type is DRM_CONNECTOR_VIRTUAL should be doable. > > > > > We can work on Laurent's suggestion but that would first require the > > > initial RFC patches and then a rework from both of our drivers side to > > > see if they gel well with our current code which will take a > > > considerable amount of time. We can for now however float the patch > > > series up which minimally affects the current drivers and also allows > > > i915 and msm to move forward with its writeback implementation off > > > course with a proper documentation stating new drivers shouldn't try to > > make their own connectors and encoders and that drm_writeback will do > > that for them. > > > Once that's done and merged we can work with Laurent on his proposal > > > to improve the drm writeback framework so that this issue can be side > > stepped entirely in future. > > > For now I would like to keep the encoder and connector pointer changes > > together. > > Best Regards, > Suraj Kandpal -- With best wishes Dmitry
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi, On Fri, 4 Mar 2022 at 12:56, Kandpal, Suraj wrote: > > Hi Abhinav, > > Hi Laurent > > > > Ok sure, I can take this up but I need to understand the proposal a little > > bit > > more before proceeding on this. So we will discuss this in another email > > where we specifically talk about the connector changes. > > > > Also, I am willing to take this up once the encoder part is done and merged > > so that atleast we keep moving on that as MSM WB implementation can > > proceed with that first. > > > > Hi Jani and Suraj > > > > Any concerns with splitting up the series into encoder and connector OR re- > > arranging them? > > > > Let me know if you can do this OR I can also split this up keeping Suraj's > > name in the Co-developed by tag. > I was actually thinking of floating a new patch series with both encoder and > connector pointer changes but with a change in initialization functions > wherein > we allocate a connector and encoder incase the driver doesn’t have its own > this > should minimize the effect on other drivers already using current drm > writeback > framework and also allow i915 to create its own connector. I thought that Laurent was quite strict about the connector. So I'd suggest targeting drm_writeback_connector with an optionally created encoder and the builtin connector > We can work on Laurent's suggestion but that would first require the initial > RFC > patches and then a rework from both of our drivers side to see if they gel > well > with our current code which will take a considerable amount of time. We can > for > now however float the patch series up which minimally affects the current > drivers > and also allows i915 and msm to move forward with its writeback implementation > off course with a proper documentation stating new drivers shouldn't try to > make > their own connectors and encoders and that drm_writeback will do that for > them. > Once that's done and merged we can work with Laurent on his proposal to > improve > the drm writeback framework so that this issue can be side stepped entirely > in future. > For now I would like to keep the encoder and connector pointer changes > together. -- With best wishes Dmitry
[Intel-gfx] [PATCH v2 1/2] drm: Add HPD state to drm_connector_oob_hotplug_event()
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test for unchanged state in the displayport altmode driver
into the i915 driver, to allow other drivers to act upon each update.
Changes in v2:
- Replace bool with drm_connector_hpd_state enum to represent "state" better
- Track old hpd state per encoder in i915
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/drm_connector.c | 6 --
drivers/gpu/drm/i915/display/intel_dp.c | 17 ++---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/usb/typec/altmodes/displayport.c | 10 +++---
include/drm/drm_connector.h | 11 +--
5 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2f..a44f082ebd9d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2825,6 +2825,7 @@ struct drm_connector *drm_connector_find_by_fwnode(struct
fwnode_handle *fwnode)
/**
* drm_connector_oob_hotplug_event - Report out-of-band hotplug event to
connector
* @connector_fwnode: fwnode_handle to report the event on
+ * @hpd_state: hot plug detect logical state
*
* On some hardware a hotplug event notification may come from outside the
display
* driver / device. An example of this is some USB Type-C setups where the
hardware
@@ -2834,7 +2835,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct
fwnode_handle *fwnode)
* This function can be used to report these out-of-band events after obtaining
* a drm_connector reference through calling drm_connector_find_by_fwnode().
*/
-void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
+enum drm_connector_hpd_state hpd_state)
{
struct drm_connector *connector;
@@ -2843,7 +2845,7 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle
*connector_fwnode)
return;
if (connector->funcs->oob_hotplug_event)
- connector->funcs->oob_hotplug_event(connector);
+ connector->funcs->oob_hotplug_event(connector, hpd_state);
drm_connector_put(connector);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1046e7fe310a..a3c9dbae5cee 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4825,15 +4825,26 @@ static int intel_dp_connector_atomic_check(struct
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
}
-static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector,
+ enum drm_connector_hpd_state hpd_state)
{
struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(connector->dev);
+ bool hpd_high = hpd_state == DRM_CONNECTOR_HPD_HIGH;
+ unsigned int hpd_pin = encoder->hpd_pin;
+ bool need_work = false;
spin_lock_irq(&i915->irq_lock);
- i915->hotplug.event_bits |= BIT(encoder->hpd_pin);
+ if (hpd_high != test_bit(hpd_pin,
&i915->hotplug.oob_hotplug_last_state)) {
+ i915->hotplug.event_bits |= BIT(hpd_pin);
+
+ __assign_bit(hpd_pin, &i915->hotplug.oob_hotplug_last_state,
hpd_high);
+ need_work = true;
+ }
spin_unlock_irq(&i915->irq_lock);
- queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
+
+ if (need_work)
+ queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
}
static const struct drm_connector_funcs intel_dp_connector_funcs = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5cfe69b30841..80a4615a38e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -138,6 +138,9 @@ struct i915_hotplug {
/* Whether or not to count short HPD IRQs in HPD storms */
u8 hpd_short_storm_enabled;
+ /* Last state reported by oob_hotplug_event for each encoder */
+ unsigned long oob_hotplug_last_state;
+
/*
* if we get a HPD irq from DP and a HPD irq from non-DP
* the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index c1d8c23baa39..ea9cb1d71fd2 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -59,7 +59,6 @@ struct dp_altmode {
struct typec_displ
[Intel-gfx] [PATCH v2 2/2] drm/msm/dp: Implement oob_hotplug_event()
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module with the
missing logic.
Overall the solution is similar to what's done downstream, but upstream
all the code to disect the HPD notification lives on the calling side of
drm_connector_oob_hotplug_event().
drm_connector_oob_hotplug_event() performs the lookup of the
drm_connector based on fwnode, hence the need to assign the fwnode in
dp_drm_connector_init().
Changes in v2:
- Adopt enum drm_connector_hpd_state
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
drivers/gpu/drm/msm/dp/dp_display.h | 3 +++
drivers/gpu/drm/msm/dp/dp_drm.c | 11 +++
drivers/gpu/drm/msm/dp/dp_hpd.c | 21 +
drivers/gpu/drm/msm/dp/dp_hpd.h | 5 +
5 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 178b774a5fbd..3d9d754a75f3 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -449,6 +449,14 @@ static int dp_display_usbpd_configure_cb(struct device
*dev)
return dp_display_process_hpd_high(dp);
}
+void dp_display_oob_hotplug_event(struct msm_dp *dp_display,
+ enum drm_connector_hpd_state hpd_state)
+{
+ struct dp_display_private *dp = container_of(dp_display, struct
dp_display_private, dp_display);
+
+ dp->usbpd->oob_event(dp->usbpd, hpd_state);
+}
+
static int dp_display_usbpd_disconnect_cb(struct device *dev)
{
struct dp_display_private *dp = dev_get_dp_display_private(dev);
@@ -1296,6 +1304,7 @@ static int dp_display_probe(struct platform_device *pdev)
dp->pdev = pdev;
dp->name = "drm_dp";
dp->dp_display.connector_type = desc->connector_type;
+ dp->dp_display.dev = &pdev->dev;
rc = dp_init_sub_modules(dp);
if (rc) {
diff --git a/drivers/gpu/drm/msm/dp/dp_display.h
b/drivers/gpu/drm/msm/dp/dp_display.h
index 7af2b186d2d9..16658270df2c 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.h
+++ b/drivers/gpu/drm/msm/dp/dp_display.h
@@ -11,6 +11,7 @@
#include "disp/msm_disp_snapshot.h"
struct msm_dp {
+ struct device *dev;
struct drm_device *drm_dev;
struct device *codec_dev;
struct drm_bridge *bridge;
@@ -40,5 +41,7 @@ bool dp_display_check_video_test(struct msm_dp *dp_display);
int dp_display_get_test_bpp(struct msm_dp *dp_display);
void dp_display_signal_audio_start(struct msm_dp *dp_display);
void dp_display_signal_audio_complete(struct msm_dp *dp_display);
+void dp_display_oob_hotplug_event(struct msm_dp *dp_display,
+ enum drm_connector_hpd_state hpd_state);
#endif /* _DP_DISPLAY_H_ */
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 80f59cf99089..76904b1601b1 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -123,6 +123,14 @@ static enum drm_mode_status dp_connector_mode_valid(
return dp_display_validate_mode(dp_disp, mode->clock);
}
+static void dp_oob_hotplug_event(struct drm_connector *connector,
+enum drm_connector_hpd_state hpd_state)
+{
+ struct msm_dp *dp_disp = to_dp_connector(connector)->dp_display;
+
+ dp_display_oob_hotplug_event(dp_disp, hpd_state);
+}
+
static const struct drm_connector_funcs dp_connector_funcs = {
.detect = dp_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -130,6 +138,7 @@ static const struct drm_connector_funcs dp_connector_funcs
= {
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+ .oob_hotplug_event = dp_oob_hotplug_event,
};
static const struct drm_connector_helper_funcs dp_connector_helper_funcs = {
@@ -160,6 +169,8 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display)
if (ret)
return ERR_PTR(ret);
+ connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
+
drm_connector_helper_add(connector, &dp_connector_helper_funcs);
/*
diff --git a/drivers/gpu/drm/msm/dp/dp_hpd.c b/drivers/gpu/drm/msm/dp/dp_hpd.c
index db98a1d431eb..cdb1feea5ebf 100644
--- a/drivers/gpu/drm/msm/dp/dp_hpd.c
+++ b/drivers/gpu/drm/msm/dp/dp_hpd.c
@@ -7,6 +7,8 @@
#include
#include
+#include
+#include
#include "dp_hpd.h"
@@ -45,6 +47,24 @@ int dp_hpd_connect(struct dp_usbpd *dp_usbpd, bool hpd)
return rc;
}
+static void dp_hpd_oob_event(struct dp_usbpd *dp_usbpd,
+enum drm_connector_hpd_state hpd_state)
+{
+ struct dp_hpd_
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/xehp: Support platforms with CCS engines but no RCS
== Series Details ==
Series: series starting with [1/2] drm/i915/xehp: Support platforms with CCS
engines but no RCS
URL : https://patchwork.freedesktop.org/series/101019/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11321_full -> Patchwork_22481_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22481_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@api_intel_allocator@fork-simple-stress-signal:
- {shard-dg1}:[PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-12/igt@api_intel_alloca...@fork-simple-stress-signal.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-17/igt@api_intel_alloca...@fork-simple-stress-signal.html
* igt@gem_ctx_sseu@mmap-args:
- {shard-dg1}:[SKIP][3] ([i915#280]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@gem_ctx_s...@mmap-args.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gem_ctx_s...@mmap-args.html
* igt@gem_exec_fence@nb-await:
- {shard-dg1}:NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gem_exec_fe...@nb-await.html
* igt@gem_exec_reloc@basic-write-cpu-active:
- {shard-dg1}:[SKIP][6] ([i915#3281]) -> [SKIP][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@gem_exec_re...@basic-write-cpu-active.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gem_exec_re...@basic-write-cpu-active.html
* igt@gen9_exec_parse@allowed-single:
- {shard-dg1}:[SKIP][8] ([i915#2527]) -> [SKIP][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@gen9_exec_pa...@allowed-single.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_3d:
- {shard-dg1}:[PASS][10] -> [SKIP][11] +26 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_3d.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_3d.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0:
- {shard-dg1}:[PASS][12] -> [FAIL][13] +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen:
- {shard-dg1}:[SKIP][14] ([i915#3359]) -> [SKIP][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_cursor_...@pipe-a-cursor-512x512-offscreen.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_cursor_...@pipe-a-cursor-512x512-offscreen.html
*
{igt@kms_plane_scaling@downscale-with-rotation-factor-0-5@pipe-c-hdmi-a-1-downscale-with-rotation}:
- {shard-dg1}:[SKIP][16] ([i915#5176]) -> [SKIP][17] +3 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@kms_plane_scaling@downscale-with-rotation-factor-...@pipe-c-hdmi-a-1-downscale-with-rotation.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@kms_plane_scaling@downscale-with-rotation-factor-...@pipe-c-hdmi-a-1-downscale-with-rotation.html
*
{igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][18]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-rkl-6/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-...@pipe-a-edp-1-planes-upscale-downscale.html
* igt@perf_pmu@busy-double-start:
- {shard-dg1}:NOTRUN -> [SKIP][19] +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@perf_...@busy-double-start.html
* igt@prime_vgem@basic-read:
- {shard-dg1}:[SKIP][20] ([i915#3708]) -> [SKIP][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11321/shard-dg1-16/igt@prime_v...@basic-read.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22481/shard-dg1-13/igt@prime_v...@basic-read.html
Known issues
Here are the changes found in Patchwork_22481_full that come from known
issues:
### IGT changes ###
Issues hi
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gmbus: move some local bus variables within loops
== Series Details ==
Series: series starting with [1/2] drm/i915/gmbus: move some local bus
variables within loops
URL : https://patchwork.freedesktop.org/series/101046/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11327 -> Patchwork_22487
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/index.html
Participating hosts (44 -> 43)
--
Additional (1): fi-icl-u2
Missing(2): fi-bsw-cyan fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22487:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-tgl-dsi}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-tgl-dsi/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_22487 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [PASS][3] -> [INCOMPLETE][4] ([i915#146])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][9] -> [INCOMPLETE][10] ([i915#4418])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][11] -> [INCOMPLETE][12] ([i915#3921])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#109278]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- fi-skl-6600u: NOTRUN -> [SKIP][16] ([fdo#109271]) +2 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][17] ([fdo#109285])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-cfl-8109u: [PASS][18] -> [DMESG-WARN][19] ([i915#295])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22487/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_cr
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts
On 03/03/2022 19:09, John Harrison wrote: Actions: 1) Get a number from compute/OpenCL people for what they say is minimum preempt timeout for default out of the box Linux desktop experience. That would be the one that has been agreed upon by both linux software arch and all UMD teams and has been in use for the past year or more in the internal tree. What has been used in the internal tree is irrelevant when UMD ack is needed for changes which affect upstream shipping platforms like Tigerlake. This does not mean them running some tests and can't be bothered to setup up the machine for the extreme use cases, but workloads average users can realistically be expected to run. Say for instance some image manipulation software which is OpenCL accelerated or similar. How long unpreemptable sections are expected there. Or similar. I am not familiar what all OpenCL accelerated use cases there are on Linux. And this number should be purely about minimum preempt timeout, not considering heartbeats. This is because preempt timeout may kick in sooner than stopped heartbeat if the user workload is low priority. And driver is simply hosed in the intervening six months or more that it takes for the right people to find the time to do this. What is hosed? Driver currently contains a patch which was acked by the compute UMD to disable preemption. If it takes six months for compute UMD to give us a different number which works for the open source stack and typical use cases then what can we do. Right now, it is broken. This patch set improves things. Actual numbers can be refined later as/when some random use case that we hadn't previously thought of pops up. But not fixing the basic problem at all until we have an absolutely perfect for all parties solution is pointless. Not least because there is no perfect solution. No matter what number you pick it is going to be wrong for someone. 2.5s, 7.5s, X.Ys, I really don't care. 2.5s is a number you seem to have picked out of the air totally at random, or maybe based on it being the heartbeat period (except that you keep arguing that basing tP on tH is wrong). 7.5s is a number that has been in active use for a lot of testing for quite some time - KMD CI, UMD CI, E2E, etc. But either way, the initial number is almost irrelevant as long as it is not zero. So can we please just get something merged now as a starting point? 2) Commit message should explain the effect on the worst case time until engine reset. 3) OpenCL/compute should ack the change publicly as well since they acked the disabling of preemption. This patch set has already been publicly acked by the compute team. See the 'acked-by' tag. I can't find the reply which contained the ack on the mailing list - do you have a msg-id or an archive link? Also, ack needs to be against the the fixed timeout patch and not one dependent on the heartbeat interval. 4) I really want overflows_type in the first patch. In the final GuC assignment? Only if it is a BUG_ON. If we get a failure there it is an internal driver error and cannot be corrected for. It is too late for any plausible range check action. If you can find a test which exercises setting insane values to the relevant timeouts and so would hit the problem in our CI then BUG_ON is fine. Otherwise I think BUG_ON is too anti-social and prefer drm_warn or drm_WARN_ON. I don't think adding a test is strictly necessary, if we don't already have one, given how unlikely this is too be hit, but if you insist on a BUG_ON instead of a flavour of a warn then I think we need one so we can catch in CI 100% of the time. And if you mean in the the actual helper function with the rest of the clamping then you are bleeding internal GuC API structure details into non-GuC code. Plus the test would be right next to the 'if (size < In my other reply I exactly described that would be a downside and that I prefer checks at the assignment sites. Also regarding this comment in the relevant patch: + /* +* NB: The GuC API only supports 32bit values. However, the limit is further +* reduced due to internal calculations which would otherwise overflow. +*/ I would suggest clarifying this as "The GuC API only supports timeouts up to U32_MAX micro-seconds. However, ...". Given the function at hand deals in milliseconds explicitly calling out that additional scaling factor makes sense I think. Big picture - it's really still very simple. Public ack for a fixed number and a warn on is not really a lot to ask. Regards, Tvrtko
[Intel-gfx] ✓ Fi.CI.IGT: success for Bump DMC to v2.16 on ADL-P (rev2)
== Series Details ==
Series: Bump DMC to v2.16 on ADL-P (rev2)
URL : https://patchwork.freedesktop.org/series/100666/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22480_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22480_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@api_intel_allocator@fork-simple-stress-signal:
- {shard-dg1}:[PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-dg1-15/igt@api_intel_alloca...@fork-simple-stress-signal.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-dg1-16/igt@api_intel_alloca...@fork-simple-stress-signal.html
* igt@gem_exec_fence@invalid-fence-array:
- {shard-rkl}:[PASS][3] -> [INCOMPLETE][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-rkl-1/igt@gem_exec_fe...@invalid-fence-array.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-rkl-5/igt@gem_exec_fe...@invalid-fence-array.html
*
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale}:
- shard-iclb: [PASS][5] -> [SKIP][6] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
* igt@prime_mmap@test_forked:
- {shard-dg1}:NOTRUN -> [SKIP][7] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22480/shard-dg1-19/igt@prime_mmap@test_forked.html
Known issues
Here are the changes found in Patchwork_22480_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-apl: ([PASS][8], [PASS][9], [PASS][10], [PASS][11],
[PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17],
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32]) ([i915#4386]) -> ([PASS][33], [PASS][34],
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40],
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46],
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
[PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
URL : https://patchwork.freedesktop.org/series/101045/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11327 -> Patchwork_22486
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/index.html
Participating hosts (44 -> 43)
--
Additional (1): fi-pnv-d510
Missing(2): fi-bsw-cyan fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22486:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {bat-dg2-9}:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@workarounds:
- {bat-adlp-6}: [PASS][2] -> [DMESG-WARN][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-dg2-9}:NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/bat-dg2-9/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- {bat-dg2-9}:NOTRUN -> [DMESG-WARN][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/bat-dg2-9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-write:
- {bat-dg2-9}:NOTRUN -> [SKIP][6] +16 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/bat-dg2-9/igt@prime_v...@basic-write.html
Known issues
Here are the changes found in Patchwork_22486 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#109315]) +17
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271]) +21 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-bdw-5557u/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][12] -> [INCOMPLETE][13] ([i915#2940])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][14] -> [INCOMPLETE][15] ([i915#3921])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11327/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#533])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22486/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][19] ([i915#146] / [i915#])
[19]:
https://intel-gfx-ci.01.org/
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration
On Thu, 24 Feb 2022, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The LRC descriptor pool is going away. So, stop using it as a check for
> context registration, use the GuC id instead (being the thing that
> actually gets registered with the GuC).
>
> Also, rename the set/clear/query helper functions for context id
> mappings to better reflect their purpose and to differentiate from
> other registration related helper functions.
>
> Signed-off-by: John Harrison
> Reviewed-by: Daniele Ceraolo Spurio
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
> 1 file changed, 38 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index b3a429a92c0d..7fb889e14995 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -514,31 +514,20 @@ static inline bool guc_submission_initialized(struct
> intel_guc *guc)
> return !!guc->lrc_desc_pool_vaddr;
> }
>
> -static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)
> +static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)
> {
> - if (likely(guc_submission_initialized(guc))) {
> - struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
> - unsigned long flags;
> -
> - memset(desc, 0, sizeof(*desc));
> + struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
>
> - /*
> - * xarray API doesn't have xa_erase_irqsave wrapper, so calling
> - * the lower level functions directly.
> - */
> - xa_lock_irqsave(&guc->context_lookup, flags);
> - __xa_erase(&guc->context_lookup, id);
> - xa_unlock_irqrestore(&guc->context_lookup, flags);
> - }
> + memset(desc, 0, sizeof(*desc));
> }
>
> -static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)
> +static inline bool ctx_id_mapped(struct intel_guc *guc, u32 id)
> {
> return __get_context(guc, id);
> }
>
> -static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
> -struct intel_context *ce)
> +static inline void set_ctx_id_mapping(struct intel_guc *guc, u32 id,
> + struct intel_context *ce)
> {
> unsigned long flags;
>
> @@ -551,6 +540,24 @@ static inline void set_lrc_desc_registered(struct
> intel_guc *guc, u32 id,
> xa_unlock_irqrestore(&guc->context_lookup, flags);
> }
>
> +static inline void clr_ctx_id_mapping(struct intel_guc *guc, u32 id)
> +{
> + unsigned long flags;
> +
> + if (unlikely(!guc_submission_initialized(guc)))
> + return;
> +
> + _reset_lrc_desc(guc, id);
> +
> + /*
> + * xarray API doesn't have xa_erase_irqsave wrapper, so calling
> + * the lower level functions directly.
> + */
> + xa_lock_irqsave(&guc->context_lookup, flags);
> + __xa_erase(&guc->context_lookup, id);
> + xa_unlock_irqrestore(&guc->context_lookup, flags);
> +}
There are a plethora of static inlines in the guc .c files, and this
adds more. How about just letting the compiler decide what's the best
course of action, inline or not? I think hand rolling the inline is a
micro optimization that you'd need to justify i.e. show that you're
doing a better job than the compiler.
The main downsides to using inlines are that you'll miss compiler
warnings for unused functions, and it sets an example for people to
start using inline more, while they should be an exception.
BR,
Jani.
PS. I also don't much like the likely/unlikely annotations, but that's
another can of worms.
> +
> static void decr_outstanding_submission_g2h(struct intel_guc *guc)
> {
> if (atomic_dec_and_test(&guc->outstanding_submission_g2h))
> @@ -795,7 +802,7 @@ static int __guc_wq_item_append(struct i915_request *rq)
> GEM_BUG_ON(!atomic_read(&ce->guc_id.ref));
> GEM_BUG_ON(context_guc_id_invalid(ce));
> GEM_BUG_ON(context_wait_for_deregister_to_register(ce));
> - GEM_BUG_ON(!lrc_desc_registered(ce_to_guc(ce), ce->guc_id.id));
> + GEM_BUG_ON(!ctx_id_mapped(ce_to_guc(ce), ce->guc_id.id));
>
> /* Insert NOOP if this work queue item will wrap the tail pointer. */
> if (wqi_size > wq_space_until_wrap(ce)) {
> @@ -923,7 +930,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
> if (submit) {
> struct intel_context *ce = request_to_scheduling_context(last);
>
> - if (unlikely(!lrc_desc_registered(guc, ce->guc_id.id) &&
> + if (unlikely(!ctx_id_mapped(guc, ce->guc_id.id) &&
>!intel_context_is_banned(ce))) {
> ret = guc_lrc_desc_pin(ce, false);
> if (unlikely(ret == -EPIPE)) {
> @@ -1897,7 +1904,7 @@ static bool need_tasklet(struct intel_guc *guc, struct
>
Re: [Intel-gfx] [PATCH 08/11] drm/i915: Replace bxt_clk_div with struct dpll
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> bxt_clk_div is basically the same as struct dpll. Just use the latter.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 50 ++-
> 1 file changed, 16 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 4a82e630cbec..58e9d5960bc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2080,75 +2080,57 @@ static bool bxt_ddi_pll_get_hw_state(struct
> drm_i915_private *dev_priv,
> return ret;
> }
>
> -/* bxt clock parameters */
> -struct bxt_clk_div {
> - int clock;
> - u32 p1;
> - u32 p2;
> - u32 m2;
> - u32 n;
> -
> - int vco;
> -};
> -
> /* pre-calculated values for DP linkrates */
> -static const struct bxt_clk_div bxt_dp_clk_val[] = {
> - { .clock = 162000, .p1 = 4, .p2 = 2, .n = 1,
> +static const struct dpll bxt_dp_clk_val[] = {
> + { .dot = 162000, .p1 = 4, .p2 = 2, .n = 1,
> .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> - { .clock = 27, .p1 = 4, .p2 = 1, .n = 1,
> + { .dot = 27, .p1 = 4, .p2 = 1, .n = 1,
> .m2 = 0x6c0 /* .m2_int = 27, m2_frac = 0 */ },
> - { .clock = 54, .p1 = 2, .p2 = 1, .n = 1,
> + { .dot = 54, .p1 = 2, .p2 = 1, .n = 1,
> .m2 = 0x6c0 /* .m2_int = 27, m2_frac = 0 */ },
> - { .clock = 216000, .p1 = 3, .p2 = 2, .n = 1,
> + { .dot = 216000, .p1 = 3, .p2 = 2, .n = 1,
> .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> - { .clock = 243000, .p1 = 4, .p2 = 1, .n = 1,
> + { .dot = 243000, .p1 = 4, .p2 = 1, .n = 1,
> .m2 = 0x613 /* .m2_int = 24, m2_frac = 1258291 */ },
> - { .clock = 324000, .p1 = 4, .p2 = 1, .n = 1,
> + { .dot = 324000, .p1 = 4, .p2 = 1, .n = 1,
> .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> - { .clock = 432000, .p1 = 3, .p2 = 1, .n = 1,
> + { .dot = 432000, .p1 = 3, .p2 = 1, .n = 1,
> .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> };
>
> static bool
> bxt_ddi_hdmi_pll_dividers(struct intel_crtc_state *crtc_state,
> - struct bxt_clk_div *clk_div)
> + struct dpll *clk_div)
> {
> struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct dpll best_clock;
>
> /* Calculate HDMI div */
> /*
>* FIXME: tie the following calculation into
>* i9xx_crtc_compute_clock
>*/
> - if (!bxt_find_best_dpll(crtc_state, &best_clock)) {
> + if (!bxt_find_best_dpll(crtc_state, clk_div)) {
> drm_dbg(&i915->drm, "no PLL dividers found for clock %d pipe
> %c\n",
> crtc_state->port_clock,
> pipe_name(crtc->pipe));
> return false;
> }
>
> - clk_div->p1 = best_clock.p1;
> - clk_div->p2 = best_clock.p2;
> - drm_WARN_ON(&i915->drm, best_clock.m1 != 2);
> - clk_div->n = best_clock.n;
> - clk_div->m2 = best_clock.m2;
> -
> - clk_div->vco = best_clock.vco;
> + drm_WARN_ON(&i915->drm, clk_div->m1 != 2);
>
> return true;
> }
>
> static void bxt_ddi_dp_pll_dividers(struct intel_crtc_state *crtc_state,
> - struct bxt_clk_div *clk_div)
> + struct dpll *clk_div)
> {
> int clock = crtc_state->port_clock;
> int i;
>
> *clk_div = bxt_dp_clk_val[0];
> for (i = 0; i < ARRAY_SIZE(bxt_dp_clk_val); ++i) {
> - if (bxt_dp_clk_val[i].clock == clock) {
> + if (bxt_dp_clk_val[i].dot == clock) {
> *clk_div = bxt_dp_clk_val[i];
> break;
> }
> @@ -2158,7 +2140,7 @@ static void bxt_ddi_dp_pll_dividers(struct
> intel_crtc_state *crtc_state,
> }
>
> static bool bxt_ddi_set_dpll_hw_state(struct intel_crtc_state *crtc_state,
> - const struct bxt_clk_div *clk_div)
> + const struct dpll *clk_div)
> {
> struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> struct intel_dpll_hw_state *dpll_hw_state = &crtc_state->dpll_hw_state;
> @@ -2230,7 +2212,7 @@ static bool bxt_ddi_set_dpll_hw_state(struct
> intel_crtc_state *crtc_state,
> static bool
> bxt_ddi_dp_set_dpll_hw_state(struct intel_crtc_state *crtc_state)
> {
> - struct bxt_clk_div clk_div = {};
> + struct dpll clk_div = {};
>
> bxt_ddi_dp_pll_dividers(crtc_state, &clk_div);
>
> @@ -2240,7 +,7 @@ bxt_ddi_dp_set_dpll_hw_state(struct intel_crtc_state
> *crtc_state)
> static bool
> bxt_ddi_hdmi_set_dpll_hw_state(struct intel_crtc_
Re: [Intel-gfx] [PATCH 07/11] drm/i915: Store the m2 divider as a whole in bxt_clk_div
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of the pointless m2 int vs. frac split in bxt_clk_div
> and just store the whole divider as one.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 33 +++
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 899aa42a858f..4a82e630cbec 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2085,8 +2085,7 @@ struct bxt_clk_div {
> int clock;
> u32 p1;
> u32 p2;
> - u32 m2_int;
> - u32 m2_frac;
> + u32 m2;
> u32 n;
>
> int vco;
> @@ -2094,13 +2093,20 @@ struct bxt_clk_div {
>
> /* pre-calculated values for DP linkrates */
> static const struct bxt_clk_div bxt_dp_clk_val[] = {
> - { .clock = 162000, .p1 = 4, .p2 = 2, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> - { .clock = 27, .p1 = 4, .p2 = 1, .m2_int = 27, .m2_frac = 0,
> .n = 1, },
> - { .clock = 54, .p1 = 2, .p2 = 1, .m2_int = 27, .m2_frac = 0,
> .n = 1, },
> - { .clock = 216000, .p1 = 3, .p2 = 2, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> - { .clock = 243000, .p1 = 4, .p2 = 1, .m2_int = 24, .m2_frac = 1258291,
> .n = 1, },
> - { .clock = 324000, .p1 = 4, .p2 = 1, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> - { .clock = 432000, .p1 = 3, .p2 = 1, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> + { .clock = 162000, .p1 = 4, .p2 = 2, .n = 1,
> + .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> + { .clock = 27, .p1 = 4, .p2 = 1, .n = 1,
> + .m2 = 0x6c0 /* .m2_int = 27, m2_frac = 0 */ },
> + { .clock = 54, .p1 = 2, .p2 = 1, .n = 1,
> + .m2 = 0x6c0 /* .m2_int = 27, m2_frac = 0 */ },
> + { .clock = 216000, .p1 = 3, .p2 = 2, .n = 1,
> + .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> + { .clock = 243000, .p1 = 4, .p2 = 1, .n = 1,
> + .m2 = 0x613 /* .m2_int = 24, m2_frac = 1258291 */ },
> + { .clock = 324000, .p1 = 4, .p2 = 1, .n = 1,
> + .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
> + { .clock = 432000, .p1 = 3, .p2 = 1, .n = 1,
> + .m2 = 0x81a /* .m2_int = 32, m2_frac = 1677722 */ },
Mmh, I guess here I would've added some macros to construct m2 from
m2_int and m2_frac.
#define M2_INT_SHIFT22
#define M2_FRAC_MASK0x3f
#define M2(int, frac) ((int) << M2_INT_SHIFT) | (frac))
And you get this:
{ .clock = 432000, .p1 = 3, .p2 = 1, .m2 = M2(32, 1677722), .n = 1, },
No need to retain the int/frac in comments. Can also use
REG_FIELD_PREP/GET if you want to over-engineer...
> };
>
> static bool
> @@ -2127,8 +2133,7 @@ bxt_ddi_hdmi_pll_dividers(struct intel_crtc_state
> *crtc_state,
> clk_div->p2 = best_clock.p2;
> drm_WARN_ON(&i915->drm, best_clock.m1 != 2);
> clk_div->n = best_clock.n;
> - clk_div->m2_int = best_clock.m2 >> 22;
> - clk_div->m2_frac = best_clock.m2 & ((1 << 22) - 1);
> + clk_div->m2 = best_clock.m2;
>
> clk_div->vco = best_clock.vco;
>
> @@ -2197,11 +2202,11 @@ static bool bxt_ddi_set_dpll_hw_state(struct
> intel_crtc_state *crtc_state,
> lanestagger = 0x02;
>
> dpll_hw_state->ebb0 = PORT_PLL_P1(clk_div->p1) |
> PORT_PLL_P2(clk_div->p2);
> - dpll_hw_state->pll0 = clk_div->m2_int;
> + dpll_hw_state->pll0 = clk_div->m2 >> 22;
> dpll_hw_state->pll1 = PORT_PLL_N(clk_div->n);
> - dpll_hw_state->pll2 = clk_div->m2_frac;
> + dpll_hw_state->pll2 = clk_div->m2 & 0x3f;
>
> - if (clk_div->m2_frac)
> + if (clk_div->m2 & 0x3f)
> dpll_hw_state->pll3 = PORT_PLL_M2_FRAC_ENABLE;
Also could reuse the shift and mask macros here.
Other than that, the direction seems good.
BR,
Jani.
>
> dpll_hw_state->pll6 = prop_coef | PORT_PLL_INT_COEFF(int_coef);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add preemption changes for Wa_14015141709
On 03/03/2022 22:42, Matt Roper wrote:
From: Akeem G Abodunrin
Starting with DG2, preemption can no longer be controlled using userspace
on a per-context basis. Instead, the hardware only allows us to enable or
disable preemption in a global, system-wide basis. Also, we lose the
ability to specify the preemption granularity (such as batch-level vs
command-level vs object-level).
As a result of this - for debugging purposes, this patch adds debugfs
interface to configure (disable/enable) preemption globally.
Jira: VLK-27831
Cc: Matt Roper
Cc: Prathap Kumar Valsan
Cc: John Harrison
Cc: Joonas Lahtinen
Signed-off-by: Akeem G Abodunrin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 50 +
drivers/gpu/drm/i915/i915_drv.h | 3 ++
4 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 19cd34f24263..21ede1887b9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -468,6 +468,9 @@
#define VF_PREEMPTION _MMIO(0x83a4)
#define PREEMPTION_VERTEX_COUNT REG_GENMASK(15, 0)
+#define GEN12_VFG_PREEMPTION_CHICKEN _MMIO(0x83b4)
+#define GEN12_VFG_PREEMPT_CHICKEN_DISABLEREG_BIT(8)
+
#define GEN8_RC6_CTX_INFO _MMIO(0x8504)
#define GEN12_SQCM_MMIO(0x8724)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index c014b40d2e9f..18dc82f29776 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2310,7 +2310,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
FF_DOP_CLOCK_GATE_DISABLE);
}
- if (IS_GRAPHICS_VER(i915, 9, 12)) {
+ if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
/*
FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
wa_masked_en(wal,
GEN7_FF_SLICE_CS_CHICKEN1,
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 747fe9f41e1f..40e6e17e2950 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -571,6 +571,55 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
return 0;
}
+static void i915_global_preemption_config(struct drm_i915_private *i915,
+ u32 val)
+{
+ const u32 bit = GEN12_VFG_PREEMPT_CHICKEN_DISABLE;
+
+ if (val)
+ intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
+ _MASKED_BIT_DISABLE(bit));
+ else
+ intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
+ _MASKED_BIT_ENABLE(bit));
In addition to what Jani suggested some other questions:
Does this setting survive GT reset?
Would intel_reg read/write work?
Can we not add the debugfs file to start with if register is n/a for a platform?
+}
+
+static int i915_global_preempt_support_get(void *data, u64 *val)
+{
+ struct drm_i915_private *i915 = data;
+ intel_wakeref_t wakeref;
+ u32 curr_status = 0;
+
+ if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
+ return -EINVAL;
What is the purpose of the "< 11" condition here? Because
HAS_PERCTX_PREEMPT_CTRL is defined as starting on Gen9? Is the 11 arbitrary then or has some
deeper meaning?
Regards,
Tvrtko
+
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref)
+ curr_status = intel_uncore_read(&i915->uncore,
+ GEN12_VFG_PREEMPTION_CHICKEN);
+ *val = (curr_status & GEN12_VFG_PREEMPT_CHICKEN_DISABLE) ? 0 : 1;
+
+ return 0;
+}
+
+static int i915_global_preempt_support_set(void *data, u64 val)
+{
+ struct drm_i915_private *i915 = data;
+ intel_wakeref_t wakeref;
+
+ if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
+ return -EINVAL;
+
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref)
+ i915_global_preemption_config(i915, val);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_global_preempt_support_fops,
+ i915_global_preempt_support_get,
+ i915_global_preempt_support_set,
+ "%lld\n");
+
static int i915_wedged_get(void *data, u64 *val)
{
struct drm_i915_private *i915 = data;
@@ -765,6 +814,7 @@ static const struct i915_debugfs_files {
const struct file_operations *fops;
} i915_debugfs_files[] = {
{"i915_perf_noa_delay", &i915_perf_noa_delay_fops},
+ {"i915_global_preempt_supp
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/fbdev: fixup setting screen_size
URL : https://patchwork.freedesktop.org/series/101016/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22479_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22479_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@gem-execbuf-stress:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-rkl-6/igt@i915_pm_...@gem-execbuf-stress.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/shard-rkl-5/igt@i915_pm_...@gem-execbuf-stress.html
*
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale}:
- shard-iclb: [PASS][3] -> [SKIP][4] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
* igt@prime_mmap@test_forked:
- {shard-dg1}:NOTRUN -> [SKIP][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/shard-dg1-18/igt@prime_mmap@test_forked.html
Known issues
Here are the changes found in Patchwork_22479_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-apl: ([PASS][6], [PASS][7], [PASS][8], [PASS][9],
[PASS][10], [PASS][11], [PASS][12], [FAIL][13], [PASS][14], [PASS][15],
[PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21],
[PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27],
[PASS][28], [PASS][29], [PASS][30]) ([i915#4386]) -> ([PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44],
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
[PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl6/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/shard-apl8/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22479/shard-apl8/boot.html
[33]:
https://inte
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Use designated initializers for bxt_dp_clk_val[]
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use designated initializers to make it clear what is what,
> and to decouple us from the specific ordering of the members.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 8beec5ec72f8..899aa42a858f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2094,13 +2094,13 @@ struct bxt_clk_div {
>
> /* pre-calculated values for DP linkrates */
> static const struct bxt_clk_div bxt_dp_clk_val[] = {
> - { 162000, 4, 2, 32, 1677722, 1 },
> - { 27, 4, 1, 27, 0, 1 },
> - { 54, 2, 1, 27, 0, 1 },
> - { 216000, 3, 2, 32, 1677722, 1 },
> - { 243000, 4, 1, 24, 1258291, 1 },
> - { 324000, 4, 1, 32, 1677722, 1 },
> - { 432000, 3, 1, 32, 1677722, 1 }
> + { .clock = 162000, .p1 = 4, .p2 = 2, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> + { .clock = 27, .p1 = 4, .p2 = 1, .m2_int = 27, .m2_frac = 0,
> .n = 1, },
> + { .clock = 54, .p1 = 2, .p2 = 1, .m2_int = 27, .m2_frac = 0,
> .n = 1, },
> + { .clock = 216000, .p1 = 3, .p2 = 2, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> + { .clock = 243000, .p1 = 4, .p2 = 1, .m2_int = 24, .m2_frac = 1258291,
> .n = 1, },
> + { .clock = 324000, .p1 = 4, .p2 = 1, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> + { .clock = 432000, .p1 = 3, .p2 = 1, .m2_int = 32, .m2_frac = 1677722,
> .n = 1, },
> };
>
> static bool
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Remove bxt m2_frac_en
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the pointless m2_frac_en from bxt_clk_div.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index bc26ebacae12..8beec5ec72f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2087,7 +2087,6 @@ struct bxt_clk_div {
> u32 p2;
> u32 m2_int;
> u32 m2_frac;
> - bool m2_frac_en;
> u32 n;
>
> int vco;
> @@ -2095,13 +2094,13 @@ struct bxt_clk_div {
>
> /* pre-calculated values for DP linkrates */
> static const struct bxt_clk_div bxt_dp_clk_val[] = {
> - { 162000, 4, 2, 32, 1677722, 1, 1 },
> - { 27, 4, 1, 27, 0, 0, 1 },
> - { 54, 2, 1, 27, 0, 0, 1 },
> - { 216000, 3, 2, 32, 1677722, 1, 1 },
> - { 243000, 4, 1, 24, 1258291, 1, 1 },
> - { 324000, 4, 1, 32, 1677722, 1, 1 },
> - { 432000, 3, 1, 32, 1677722, 1, 1 }
> + { 162000, 4, 2, 32, 1677722, 1 },
> + { 27, 4, 1, 27, 0, 1 },
> + { 54, 2, 1, 27, 0, 1 },
> + { 216000, 3, 2, 32, 1677722, 1 },
> + { 243000, 4, 1, 24, 1258291, 1 },
> + { 324000, 4, 1, 32, 1677722, 1 },
> + { 432000, 3, 1, 32, 1677722, 1 }
> };
>
> static bool
> @@ -2130,7 +2129,6 @@ bxt_ddi_hdmi_pll_dividers(struct intel_crtc_state
> *crtc_state,
> clk_div->n = best_clock.n;
> clk_div->m2_int = best_clock.m2 >> 22;
> clk_div->m2_frac = best_clock.m2 & ((1 << 22) - 1);
> - clk_div->m2_frac_en = clk_div->m2_frac != 0;
>
> clk_div->vco = best_clock.vco;
>
> @@ -2203,7 +2201,7 @@ static bool bxt_ddi_set_dpll_hw_state(struct
> intel_crtc_state *crtc_state,
> dpll_hw_state->pll1 = PORT_PLL_N(clk_div->n);
> dpll_hw_state->pll2 = clk_div->m2_frac;
>
> - if (clk_div->m2_frac_en)
> + if (clk_div->m2_frac)
> dpll_hw_state->pll3 = PORT_PLL_M2_FRAC_ENABLE;
>
> dpll_hw_state->pll6 = prop_coef | PORT_PLL_INT_COEFF(int_coef);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Clean up some struct/array initializers
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the simple '= {}' form to initialize empty arrays/structs.
> Also add some missing whitespace.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 4e06c8203aca..bc26ebacae12 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -832,7 +832,7 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
> {
> u64 freq2k;
> unsigned p, n2, r2;
> - struct hsw_wrpll_rnp best = { 0, 0, 0 };
> + struct hsw_wrpll_rnp best = {};
> unsigned budget;
>
> freq2k = clock / 100;
> @@ -1567,8 +1567,8 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> static bool skl_ddi_hdmi_pll_dividers(struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> + struct skl_wrpll_params wrpll_params = {};
> u32 ctrl1, cfgcr1, cfgcr2;
> - struct skl_wrpll_params wrpll_params = { 0, };
>
> /*
>* See comment in intel_dpll_hw_state to understand why we always use 0
> @@ -2095,13 +2095,13 @@ struct bxt_clk_div {
>
> /* pre-calculated values for DP linkrates */
> static const struct bxt_clk_div bxt_dp_clk_val[] = {
> - {162000, 4, 2, 32, 1677722, 1, 1},
> - {27, 4, 1, 27, 0, 0, 1},
> - {54, 2, 1, 27, 0, 0, 1},
> - {216000, 3, 2, 32, 1677722, 1, 1},
> - {243000, 4, 1, 24, 1258291, 1, 1},
> - {324000, 4, 1, 32, 1677722, 1, 1},
> - {432000, 3, 1, 32, 1677722, 1, 1}
> + { 162000, 4, 2, 32, 1677722, 1, 1 },
> + { 27, 4, 1, 27, 0, 0, 1 },
> + { 54, 2, 1, 27, 0, 0, 1 },
> + { 216000, 3, 2, 32, 1677722, 1, 1 },
> + { 243000, 4, 1, 24, 1258291, 1, 1 },
> + { 324000, 4, 1, 32, 1677722, 1, 1 },
> + { 432000, 3, 1, 32, 1677722, 1, 1 }
> };
>
> static bool
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 02/11] drm/i915: Move a bunch of stuff into rodata from the stack
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Toss a bunch if constants into .rodata drom the stack. Also
> shrink the types of some of the arrays to reduce the size.
>
> bloat-o-meter -c intel_dpll_mgr.o:
> add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-86 (-86)
> Function old new delta
> icl_get_dplls 33933372 -21
> skl_get_dpll20692004 -65
> Total: Before=28029, After=27943, chg -0.31%
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Data old new delta
> Total: Before=17, After=17, chg +0.00%
> add/remove: 2/0 grow/shrink: 0/2 up/down: 28/-129 (-101)
> RO Data old new delta
> dco_central_freq - 24 +24
> div1_vals - 4 +4
> odd_dividers 28 7 -21
> even_dividers144 36-108
> Total: Before=3600, After=3499, chg -2.81%
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 24 +--
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 1b1b70f0ff93..4e06c8203aca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -1495,18 +1495,17 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> int ref_clock,
> struct skl_wrpll_params *wrpll_params)
> {
> - u64 afe_clock = clock * 5; /* AFE Clock is 5x Pixel clock */
> - u64 dco_central_freq[3] = { 84ULL,
> - 90ULL,
> - 96ULL };
> - static const int even_dividers[] = { 4, 6, 8, 10, 12, 14, 16, 18, 20,
> - 24, 28, 30, 32, 36, 40, 42, 44,
> - 48, 52, 54, 56, 60, 64, 66, 68,
> - 70, 72, 76, 78, 80, 84, 88, 90,
> - 92, 96, 98 };
> - static const int odd_dividers[] = { 3, 5, 7, 9, 15, 21, 35 };
> + static const u64 dco_central_freq[3] = { 84ULL,
> + 90ULL,
> + 96ULL };
> + static const u8 even_dividers[] = { 4, 6, 8, 10, 12, 14, 16, 18, 20,
> + 24, 28, 30, 32, 36, 40, 42, 44,
> + 48, 52, 54, 56, 60, 64, 66, 68,
> + 70, 72, 76, 78, 80, 84, 88, 90,
> + 92, 96, 98 };
> + static const u8 odd_dividers[] = { 3, 5, 7, 9, 15, 21, 35 };
> static const struct {
> - const int *list;
> + const u8 *list;
> int n_dividers;
> } dividers[] = {
> { even_dividers, ARRAY_SIZE(even_dividers) },
> @@ -1517,6 +1516,7 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> };
> unsigned int dco, d, i;
> unsigned int p0, p1, p2;
> + u64 afe_clock = clock * 5; /* AFE Clock is 5x Pixel clock */
>
> for (d = 0; d < ARRAY_SIZE(dividers); d++) {
> for (dco = 0; dco < ARRAY_SIZE(dco_central_freq); dco++) {
> @@ -2751,8 +2751,8 @@ static bool icl_mg_pll_find_divisors(int clock_khz,
> bool is_dp, bool use_ssc,
>struct intel_dpll_hw_state *state,
>bool is_dkl)
> {
> + static const u8 div1_vals[] = { 7, 5, 3, 2 };
> u32 dco_min_freq, dco_max_freq;
> - int div1_vals[] = {7, 5, 3, 2};
> unsigned int i;
> int div2;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Nuke skl_wrpll_context_init()
On Tue, 01 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We can trivially replace skl_wrpll_context_init() with a single
> designated initializer.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 569903d47aea..1b1b70f0ff93 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -1330,13 +1330,6 @@ struct skl_wrpll_context {
> unsigned int p; /* chosen divider */
> };
>
> -static void skl_wrpll_context_init(struct skl_wrpll_context *ctx)
> -{
> - memset(ctx, 0, sizeof(*ctx));
> -
> - ctx->min_deviation = U64_MAX;
> -}
> -
> /* DCO freq must be within +1%/-6% of the DCO central freq */
> #define SKL_DCO_MAX_PDEVIATION 100
> #define SKL_DCO_MAX_NDEVIATION 600
> @@ -1519,12 +1512,12 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
> { even_dividers, ARRAY_SIZE(even_dividers) },
> { odd_dividers, ARRAY_SIZE(odd_dividers) },
> };
> - struct skl_wrpll_context ctx;
> + struct skl_wrpll_context ctx = {
> + .min_deviation = U64_MAX,
> + };
> unsigned int dco, d, i;
> unsigned int p0, p1, p2;
>
> - skl_wrpll_context_init(&ctx);
> -
> for (d = 0; d < ARRAY_SIZE(dividers); d++) {
> for (dco = 0; dco < ARRAY_SIZE(dco_central_freq); dco++) {
> for (i = 0; i < dividers[d].n_dividers; i++) {
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Move framestart_delay to crtc_state
On Mon, 21 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We need to make framestart_delay dynamic for DRRS on PCH
> ports. To that end move it into the crtc state. As a bonus
> we get state check+dump for it. Will also allow us to get
> rid of the somewhat questionable framestart_delay sanitation
> code.
>
> Signed-off-by: Ville Syrjälä
On the series,
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 40 ++-
> .../drm/i915/display/intel_display_types.h| 2 +
> .../gpu/drm/i915/display/intel_pch_display.c | 15 +++
> drivers/gpu/drm/i915/display/intel_vrr.c | 4 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 -
> 5 files changed, 42 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e2ca70696c05..7e80530b9b00 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1865,7 +1865,7 @@ static void hsw_set_frame_start_delay(const struct
> intel_crtc_state *crtc_state)
>
> val = intel_de_read(dev_priv, reg);
> val &= ~HSW_FRAME_START_DELAY_MASK;
> - val |= HSW_FRAME_START_DELAY(dev_priv->framestart_delay - 1);
> + val |= HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1);
> intel_de_write(dev_priv, reg, val);
> }
>
> @@ -3208,7 +3208,7 @@ static void i9xx_set_pipeconf(const struct
> intel_crtc_state *crtc_state)
>
> pipeconf |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
>
> - pipeconf |= PIPECONF_FRAME_START_DELAY(dev_priv->framestart_delay - 1);
> + pipeconf |= PIPECONF_FRAME_START_DELAY(crtc_state->framestart_delay -
> 1);
>
> intel_de_write(dev_priv, PIPECONF(crtc->pipe), pipeconf);
> intel_de_posting_read(dev_priv, PIPECONF(crtc->pipe));
> @@ -3398,6 +3398,8 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
>
> pipe_config->gamma_mode = REG_FIELD_GET(PIPECONF_GAMMA_MODE_MASK_I9XX,
> tmp);
>
> + pipe_config->framestart_delay =
> REG_FIELD_GET(PIPECONF_FRAME_START_DELAY_MASK, tmp) + 1;
> +
> if (IS_CHERRYVIEW(dev_priv))
> pipe_config->cgm_mode = intel_de_read(dev_priv,
>
> CGM_PIPE_MODE(crtc->pipe));
> @@ -3523,7 +3525,7 @@ static void ilk_set_pipeconf(const struct
> intel_crtc_state *crtc_state)
>
> val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
>
> - val |= PIPECONF_FRAME_START_DELAY(dev_priv->framestart_delay - 1);
> + val |= PIPECONF_FRAME_START_DELAY(crtc_state->framestart_delay - 1);
>
> intel_de_write(dev_priv, PIPECONF(pipe), val);
> intel_de_posting_read(dev_priv, PIPECONF(pipe));
> @@ -3831,6 +3833,8 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
>
> pipe_config->gamma_mode = REG_FIELD_GET(PIPECONF_GAMMA_MODE_MASK_ILK,
> tmp);
>
> + pipe_config->framestart_delay =
> REG_FIELD_GET(PIPECONF_FRAME_START_DELAY_MASK, tmp) + 1;
> +
> pipe_config->csc_mode = intel_de_read(dev_priv,
> PIPE_CSC_MODE(crtc->pipe));
>
> @@ -4266,6 +4270,15 @@ static bool hsw_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->pixel_multiplier = 1;
> }
>
> + if (!transcoder_is_dsi(pipe_config->cpu_transcoder)) {
> + tmp = intel_de_read(dev_priv,
> CHICKEN_TRANS(pipe_config->cpu_transcoder));
> +
> + pipe_config->framestart_delay =
> REG_FIELD_GET(HSW_FRAME_START_DELAY_MASK, tmp) + 1;
> + } else {
> + /* no idea if this is correct */
> + pipe_config->framestart_delay = 1;
> + }
> +
> out:
> intel_display_power_put_all_in_set(dev_priv, &power_domain_set);
>
> @@ -5303,6 +5316,9 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
> &pipe_config->dp_m2_n2);
> }
>
> + drm_dbg_kms(&dev_priv->drm, "framestart delay: %d\n",
> + pipe_config->framestart_delay);
> +
> drm_dbg_kms(&dev_priv->drm,
> "audio: %i, infoframes: %i, infoframes enabled: 0x%x\n",
> pipe_config->has_audio, pipe_config->has_infoframe,
> @@ -5654,6 +5670,8 @@ intel_modeset_pipe_config(struct intel_atomic_state
> *state,
> pipe_config->cpu_transcoder =
> (enum transcoder) to_intel_crtc(crtc)->pipe;
>
> + pipe_config->framestart_delay = 1;
> +
> /*
>* Sanitize sync polarity flags based on requested ones. If neither
>* positive or negative polarity is requested, treat this as meaning
> @@ -6191,6 +6209,8 @@ intel_pipe_config_compare(const struct intel_crtc_state
> *current_config,
>
> PIPE_CONF_CHECK_X(output_types);
>
> + PIPE_CONF_CHECK_I(framestart_delay);
> +
> PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_hdisplay);
> PIPE_CONF_CHE
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi, > > Hi Abhinav, > > > Hi Laurent > > > > > > Ok sure, I can take this up but I need to understand the proposal a > > > little bit more before proceeding on this. So we will discuss this > > > in another email where we specifically talk about the connector changes. > > > > > > Also, I am willing to take this up once the encoder part is done and > > > merged so that atleast we keep moving on that as MSM WB > > > implementation can proceed with that first. > > > > > > Hi Jani and Suraj > > > > > > Any concerns with splitting up the series into encoder and connector > > > OR re- arranging them? > > > > > > Let me know if you can do this OR I can also split this up keeping > > > Suraj's name in the Co-developed by tag. > > I was actually thinking of floating a new patch series with both > > encoder and connector pointer changes but with a change in > > initialization functions wherein we allocate a connector and encoder > > incase the driver doesn’t have its own this should minimize the effect > > on other drivers already using current drm writeback framework and also > allow i915 to create its own connector. > > I thought that Laurent was quite strict about the connector. So I'd suggest > targeting drm_writeback_connector with an optionally created encoder and > the builtin connector In that case even if we target that i915 will not be able to move forward with its implementation of writeback as builtin connector does not work for us right now as explained earlier, optionally creating encoder and connector will help everyone move forward and once done we can actually sit and work on how to side step this issue using Laurent's suggestion > > > We can work on Laurent's suggestion but that would first require the > > initial RFC patches and then a rework from both of our drivers side to > > see if they gel well with our current code which will take a > > considerable amount of time. We can for now however float the patch > > series up which minimally affects the current drivers and also allows > > i915 and msm to move forward with its writeback implementation off > > course with a proper documentation stating new drivers shouldn't try to > make their own connectors and encoders and that drm_writeback will do > that for them. > > Once that's done and merged we can work with Laurent on his proposal > > to improve the drm writeback framework so that this issue can be side > stepped entirely in future. > > For now I would like to keep the encoder and connector pointer changes > together. Best Regards, Suraj Kandpal
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/selftests: fix a shift-out-of-bounds bug
== Series Details ==
Series: drm/selftests: fix a shift-out-of-bounds bug
URL : https://patchwork.freedesktop.org/series/101012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22478_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22478_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@prime_mmap@test_forked:
- {shard-dg1}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-dg1-18/igt@prime_mmap@test_forked.html
Known issues
Here are the changes found in Patchwork_22478_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_sseu@engines:
- shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271]) +5 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-snb6/igt@gem_ctx_s...@engines.html
* igt@gem_exec_balancer@parallel:
- shard-iclb: NOTRUN -> [SKIP][3] ([i915#4525])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-iclb3/igt@gem_exec_balan...@parallel.html
- shard-tglb: NOTRUN -> [DMESG-WARN][4] ([i915#5076])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-tglb8/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][5] ([i915#5076])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-kbl3/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-glk9/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-apl7/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@verify-random:
- shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-skl9/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271]) +35 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-kbl3/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html
* igt@gen9_exec_parse@bb-chained:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#2856])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-iclb5/igt@gen9_exec_pa...@bb-chained.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#454])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb4/igt@i915_pm...@dc6-psr.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-iclb3/igt@i915_pm...@dc6-psr.html
* igt@i915_pm_dc@dc9-dpms:
- shard-iclb: [PASS][19] -> [SKIP][20] ([i915#4281])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb8/igt@i915_pm...@dc9-dpms.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22478/shard-iclb3/igt@i915_pm...@dc9-dpms.html
* igt@i915_suspend@forcewake:
- shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#636])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-skl1/igt@i915_susp...@forcewake.html
Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Set "SF Partial Frame Enable" also on full update
On Fri, 25 Feb 2022, Jouni Högander wrote:
> Currently we are observing occasional screen flickering when
> PSR2 selective fetch is enabled. More specifically glitch seems
> to happen on full frame update when cursor moves to coords
> x = -1 or y = -1.
>
> According to Bspec SF Single full frame should not be set if
> SF Partial Frame Enable is not set. This happened to be true for
> ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADL_P it's
> actually "SF Partial Frame Enable" (Bit 31).
>
> Setting "SF Partial Frame Enable" bit also on full update seems to
> fix screen flickering.
>
> Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
> only if not on ADL_P. Bit 31 has different meaning in ADL_P.
>
> Bspec: 49274
>
> v2: Fix Mihai Harpau email address
> v3: Modify commit message and remove unnecessary comment
>
> Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> default")
> Reported-by: Lyude Paul
> Cc: Mihai Harpau
> Cc: José Roberto de Souza
> Cc: Ville Syrjälä
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077
> Signed-off-by: Jouni Högander
> Reviewed-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 16 ++--
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 2e0b092f4b6b..b6b7bb5be5ae 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1439,6 +1439,13 @@ static inline u32
> man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private
> PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> }
>
> +static inline u32 man_trk_ctl_partial_frame_bit_get(struct drm_i915_private
> *dev_priv)
Generally, please don't use inline in .c files, just let the compiler do
its thing. We won't get warnings if inlines become unused.
Please name struct drm_i915_private * pointers i915 instead of dev_priv
in new code where possible. (We've still got some implicit assumptions
on dev_priv in some register macros unfortunately.)
> +{
> + return IS_ALDERLAKE_P(dev_priv) ?
> +ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
> +PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> +}
> +
> static void psr_force_hw_tracking_exit(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> @@ -1543,7 +1550,13 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> + u32 val = 0;
> +
> + if (!IS_ALDERLAKE_P(dev_priv))
> + val = PSR2_MAN_TRK_CTL_ENABLE;
> +
> + /* SF partial frame enable has to be set even on full update */
> + val |= man_trk_ctl_partial_frame_bit_get(dev_priv);
Not sure if the separate function for this is warranted if you're anyway
including an if (!IS_ALDERLAKE_P(dev_priv)) condition here.
BR,
Jani.
>
> if (full_update) {
> /*
> @@ -1563,7 +1576,6 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> } else {
> drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 ||
> clip->y2 % 4);
>
> - val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 + 1);
> val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 / 4 + 1);
> }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a2f36ef91cec..b347a8921178 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2316,6 +2316,7 @@
> #define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val)
> REG_FIELD_PREP(ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val)
> #define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK
> REG_GENMASK(12, 0)
> #define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(val)
> REG_FIELD_PREP(ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK, val)
> +#define ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE
> REG_BIT(31)
> #define ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME REG_BIT(14)
> #define ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME
> REG_BIT(13)
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 2/2] drm/i915/gmbus: use to_intel_gmbus() instead of open coding
We have a helper for getting at the enclosing gmbus struct from the
embedded i2c_adapter, use it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_gmbus.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 8f26528c3dc7..21281a7bdc17 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -300,9 +300,7 @@ static void set_data(void *data, int state_high)
static int
intel_gpio_pre_xfer(struct i2c_adapter *adapter)
{
- struct intel_gmbus *bus = container_of(adapter,
- struct intel_gmbus,
- adapter);
+ struct intel_gmbus *bus = to_intel_gmbus(adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
intel_gmbus_reset(dev_priv);
@@ -319,9 +317,7 @@ intel_gpio_pre_xfer(struct i2c_adapter *adapter)
static void
intel_gpio_post_xfer(struct i2c_adapter *adapter)
{
- struct intel_gmbus *bus = container_of(adapter,
- struct intel_gmbus,
- adapter);
+ struct intel_gmbus *bus = to_intel_gmbus(adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
set_data(bus, 1);
@@ -619,9 +615,7 @@ static int
do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
u32 gmbus0_source)
{
- struct intel_gmbus *bus = container_of(adapter,
- struct intel_gmbus,
- adapter);
+ struct intel_gmbus *bus = to_intel_gmbus(adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
int i = 0, inc, try = 0;
int ret = 0;
@@ -751,8 +745,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg
*msgs, int num,
static int
gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
{
- struct intel_gmbus *bus =
- container_of(adapter, struct intel_gmbus, adapter);
+ struct intel_gmbus *bus = to_intel_gmbus(adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
intel_wakeref_t wakeref;
int ret;
@@ -776,8 +769,7 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg
*msgs, int num)
int intel_gmbus_output_aksv(struct i2c_adapter *adapter)
{
- struct intel_gmbus *bus =
- container_of(adapter, struct intel_gmbus, adapter);
+ struct intel_gmbus *bus = to_intel_gmbus(adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
u8 cmd = DRM_HDCP_DDC_AKSV;
u8 buf[DRM_HDCP_KSV_LEN] = { 0 };
--
2.30.2
[Intel-gfx] [PATCH 1/2] drm/i915/gmbus: move some local bus variables within loops
Limit the scope.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_gmbus.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 2bb3494b93e2..8f26528c3dc7 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -868,7 +868,6 @@ static const struct i2c_lock_operations gmbus_lock_ops = {
int intel_gmbus_setup(struct drm_i915_private *dev_priv)
{
struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
- struct intel_gmbus *bus;
unsigned int pin;
int ret;
@@ -886,6 +885,7 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
const struct gmbus_pin *gmbus_pin;
+ struct intel_gmbus *bus;
gmbus_pin = get_gmbus_pin(dev_priv, pin);
if (!gmbus_pin)
@@ -978,10 +978,11 @@ bool intel_gmbus_is_forced_bit(struct i2c_adapter
*adapter)
void intel_gmbus_teardown(struct drm_i915_private *dev_priv)
{
- struct intel_gmbus *bus;
unsigned int pin;
for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
+ struct intel_gmbus *bus;
+
bus = dev_priv->gmbus[pin];
if (!bus)
continue;
--
2.30.2
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add preemption changes for Wa_14015141709
On Thu, 03 Mar 2022, Matt Roper wrote:
> From: Akeem G Abodunrin
>
> Starting with DG2, preemption can no longer be controlled using userspace
> on a per-context basis. Instead, the hardware only allows us to enable or
> disable preemption in a global, system-wide basis. Also, we lose the
> ability to specify the preemption granularity (such as batch-level vs
> command-level vs object-level).
>
> As a result of this - for debugging purposes, this patch adds debugfs
> interface to configure (disable/enable) preemption globally.
>
> Jira: VLK-27831
Please remove internal Jira references.
> Cc: Matt Roper
> Cc: Prathap Kumar Valsan
> Cc: John Harrison
> Cc: Joonas Lahtinen
> Signed-off-by: Akeem G Abodunrin
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 50 +
> drivers/gpu/drm/i915/i915_drv.h | 3 ++
> 4 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 19cd34f24263..21ede1887b9f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -468,6 +468,9 @@
> #define VF_PREEMPTION_MMIO(0x83a4)
> #define PREEMPTION_VERTEX_COUNTREG_GENMASK(15, 0)
>
> +#define GEN12_VFG_PREEMPTION_CHICKEN _MMIO(0x83b4)
> +#define GEN12_VFG_PREEMPT_CHICKEN_DISABLE REG_BIT(8)
> +
> #define GEN8_RC6_CTX_INFO_MMIO(0x8504)
>
> #define GEN12_SQCM _MMIO(0x8724)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index c014b40d2e9f..18dc82f29776 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2310,7 +2310,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>FF_DOP_CLOCK_GATE_DISABLE);
> }
>
> - if (IS_GRAPHICS_VER(i915, 9, 12)) {
> + if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
Adding HAS_PERCTX_PREEMPT_CTRL(i915) and using it is a separate change
from the debugfs. Please split it up.
> /*
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
> wa_masked_en(wal,
>GEN7_FF_SLICE_CS_CHICKEN1,
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 747fe9f41e1f..40e6e17e2950 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -571,6 +571,55 @@ static int i915_wa_registers(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static void i915_global_preemption_config(struct drm_i915_private *i915,
> + u32 val)
> +{
> + const u32 bit = GEN12_VFG_PREEMPT_CHICKEN_DISABLE;
We rarely use const for locals, and usually only if the function is big.
I'd probably use:
u32 tmp = val ?
_MASKED_BIT_DISABLE(GEN12_VFG_PREEMPT_CHICKEN_DISABLE) :
_MASKED_BIT_ENABLE(GEN12_VFG_PREEMPT_CHICKEN_DISABLE);
To have just one intel_uncore_write().
> +
> + if (val)
> + intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
> +_MASKED_BIT_DISABLE(bit));
> + else
> + intel_uncore_write(&i915->uncore, GEN12_VFG_PREEMPTION_CHICKEN,
> +_MASKED_BIT_ENABLE(bit));
We really shouldn't be adding new direct low-level register access in
i915_debugfs.c.
Please define an interface for this and add the functionality to a
suitable place, and then call the functions from here.
> +}
> +
> +static int i915_global_preempt_support_get(void *data, u64 *val)
> +{
> + struct drm_i915_private *i915 = data;
> + intel_wakeref_t wakeref;
> + u32 curr_status = 0;
> +
> + if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
> + return -EINVAL;
> +
> + with_intel_runtime_pm(&i915->runtime_pm, wakeref)
> + curr_status = intel_uncore_read(&i915->uncore,
> + GEN12_VFG_PREEMPTION_CHICKEN);
> + *val = (curr_status & GEN12_VFG_PREEMPT_CHICKEN_DISABLE) ? 0 : 1;
> +
> + return 0;
> +}
> +
> +static int i915_global_preempt_support_set(void *data, u64 val)
> +{
> + struct drm_i915_private *i915 = data;
> + intel_wakeref_t wakeref;
> +
> + if (HAS_PERCTX_PREEMPT_CTRL(i915) || GRAPHICS_VER(i915) < 11)
> + return -EINVAL;
> +
> + with_intel_runtime_pm(&i915->runtime_pm, wakeref)
> + i915_global_preemption_config(i915, val);
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_global_preempt_support_fops,
> + i915_global_preempt_suppo
[Intel-gfx] [CI 2/2] drm/i915: limit the async bind to bind_async_flags
If the vm doesn't request async binding, like for example with the dpt,
then we should be able to skip the async path and avoid calling
i915_vm_lock_objects() altogether. Currently if we have a moving fence
set for the BO(even though it might have signalled), we still take the
async patch regardless of the bind_async setting, and then later still
end up just doing i915_gem_object_wait_moving_fence() anyway.
Alternatively we would need to add dummy scratch object which can be
locked, just for the dpt.
Suggested-by: Thomas Hellström
Signed-off-by: Matthew Auld
Cc: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 94fcdb7bd21d..4d4d3659c938 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1360,8 +1360,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
if (flags & PIN_GLOBAL)
wakeref = intel_runtime_pm_get(&vma->vm->i915->runtime_pm);
- moving = vma->obj ? i915_gem_object_get_moving_fence(vma->obj) : NULL;
- if (flags & vma->vm->bind_async_flags || moving) {
+ if (flags & vma->vm->bind_async_flags) {
/* lock VM */
err = i915_vm_lock_objects(vma->vm, ww);
if (err)
@@ -1375,6 +1374,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
work->vm = i915_vm_get(vma->vm);
+ moving = vma->obj ? i915_gem_object_get_moving_fence(vma->obj)
: NULL;
dma_fence_work_chain(&work->base, moving);
/* Allocate enough page directories to used PTE */
--
2.34.1
[Intel-gfx] [CI 1/2] drm/i915/fbdev: fixup setting screen_size
Since we are actually mapping the object and not the vma, when dealing with LMEM, we should be careful and use the backing store size here, since the vma->node.size could have all kinds of funny padding constraints, which could result in us writing to OOB address. v2(Chris): - Prefer vma->size here, which should be the backing store size. Some more rework is needed here to stop using node.size in some other places. Signed-off-by: Matthew Auld Cc: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_fbdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c index 2cd62a187df3..221336178991 100644 --- a/drivers/gpu/drm/i915/display/intel_fbdev.c +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c @@ -279,7 +279,7 @@ static int intelfb_create(struct drm_fb_helper *helper, /* Our framebuffer is the entirety of fbdev's system memory */ info->fix.smem_start = (unsigned long)(ggtt->gmadr.start + vma->node.start); - info->fix.smem_len = vma->node.size; + info->fix.smem_len = vma->size; } vaddr = i915_vma_pin_iomap(vma); @@ -290,7 +290,7 @@ static int intelfb_create(struct drm_fb_helper *helper, goto out_unpin; } info->screen_base = vaddr; - info->screen_size = vma->node.size; + info->screen_size = vma->size; drm_fb_helper_fill_info(info, &ifbdev->helper, sizes); -- 2.34.1
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Hi Abhinav, > Hi Laurent > > Ok sure, I can take this up but I need to understand the proposal a little bit > more before proceeding on this. So we will discuss this in another email > where we specifically talk about the connector changes. > > Also, I am willing to take this up once the encoder part is done and merged > so that atleast we keep moving on that as MSM WB implementation can > proceed with that first. > > Hi Jani and Suraj > > Any concerns with splitting up the series into encoder and connector OR re- > arranging them? > > Let me know if you can do this OR I can also split this up keeping Suraj's > name in the Co-developed by tag. I was actually thinking of floating a new patch series with both encoder and connector pointer changes but with a change in initialization functions wherein we allocate a connector and encoder incase the driver doesn’t have its own this should minimize the effect on other drivers already using current drm writeback framework and also allow i915 to create its own connector. We can work on Laurent's suggestion but that would first require the initial RFC patches and then a rework from both of our drivers side to see if they gel well with our current code which will take a considerable amount of time. We can for now however float the patch series up which minimally affects the current drivers and also allows i915 and msm to move forward with its writeback implementation off course with a proper documentation stating new drivers shouldn't try to make their own connectors and encoders and that drm_writeback will do that for them. Once that's done and merged we can work with Laurent on his proposal to improve the drm writeback framework so that this issue can be side stepped entirely in future. For now I would like to keep the encoder and connector pointer changes together. Best Regards, Suraj Kandpal
Re: [Intel-gfx] [PATCH 4/5] drm/i915/gmbus: alloc intel_gmbus dynamically
On Thu, 03 Mar 2022, Ville Syrjälä wrote:
> On Thu, Mar 03, 2022 at 08:19:30PM +0200, Jani Nikula wrote:
>> Allocate the individual intel_gmbus structs dynamically. This lets us
>> hide struct intel_gmbus inside intel_gmbus.c completely. Also use the
>> cleanup function on the error path to avoid duplication.
>>
>> Leave #include in i915_drv.h for now, as it pulls in a
>> bunch of implicit dependencies.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_gmbus.c | 42 +++---
>> drivers/gpu/drm/i915/i915_drv.h| 14 ++--
>> 2 files changed, 31 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
>> b/drivers/gpu/drm/i915/display/intel_gmbus.c
>> index fd908e524875..2bb3494b93e2 100644
>> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
>> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
>> @@ -38,6 +38,16 @@
>> #include "intel_display_types.h"
>> #include "intel_gmbus.h"
>>
>> +struct intel_gmbus {
>> +struct i2c_adapter adapter;
>> +#define GMBUS_FORCE_BIT_RETRY (1U << 31)
>> +u32 force_bit;
>> +u32 reg0;
>> +i915_reg_t gpio_reg;
>> +struct i2c_algo_bit_data bit_algo;
>> +struct drm_i915_private *dev_priv;
>> +};
>> +
>> struct gmbus_pin {
>> const char *name;
>> enum i915_gpio gpio;
>> @@ -881,7 +891,11 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
>> if (!gmbus_pin)
>> continue;
>>
>> -bus = &dev_priv->gmbus[pin];
>> +bus = kzalloc(sizeof(*bus), GFP_KERNEL);
>> +if (!bus) {
>> +ret = -ENOMEM;
>> +goto err;
>> +}
>>
>> bus->adapter.owner = THIS_MODULE;
>> bus->adapter.class = I2C_CLASS_DDC;
>> @@ -911,8 +925,12 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
>> intel_gpio_setup(bus, GPIO(gmbus_pin->gpio));
>>
>> ret = i2c_add_adapter(&bus->adapter);
>> -if (ret)
>> +if (ret) {
>> +kfree(bus);
>> goto err;
>> +}
>> +
>> +dev_priv->gmbus[pin] = bus;
>> }
>>
>> intel_gmbus_reset(dev_priv);
>> @@ -920,24 +938,19 @@ int intel_gmbus_setup(struct drm_i915_private
>> *dev_priv)
>> return 0;
>>
>> err:
>> -while (pin--) {
>> -if (!intel_gmbus_is_valid_pin(dev_priv, pin))
>> -continue;
>> +intel_gmbus_teardown(dev_priv);
>>
>> -bus = &dev_priv->gmbus[pin];
>> -i2c_del_adapter(&bus->adapter);
>> -}
>> return ret;
>> }
>>
>> struct i2c_adapter *intel_gmbus_get_adapter(struct drm_i915_private
>> *dev_priv,
>> unsigned int pin)
>> {
>> -if (drm_WARN_ON(&dev_priv->drm,
>> -!intel_gmbus_is_valid_pin(dev_priv, pin)))
>> +if (drm_WARN_ON(&dev_priv->drm, pin >= ARRAY_SIZE(dev_priv->gmbus) ||
>> +!dev_priv->gmbus[pin]))
>> return NULL;
>>
>> -return &dev_priv->gmbus[pin].adapter;
>> +return &dev_priv->gmbus[pin]->adapter;
>> }
>>
>> void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
>> @@ -969,10 +982,13 @@ void intel_gmbus_teardown(struct drm_i915_private
>> *dev_priv)
>> unsigned int pin;
>>
>> for (pin = 0; pin < ARRAY_SIZE(dev_priv->gmbus); pin++) {
>> -if (!intel_gmbus_is_valid_pin(dev_priv, pin))
>> +bus = dev_priv->gmbus[pin];
>
> nit: Would like the 'bus' variable to be declared inside the loop.
> Same for intel_gmbus_setup().
Thanks for the review, pushed to din. I'll follow up with a few
cleanups.
BR,
Jani.
>
>> +if (!bus)
>> continue;
>>
>> -bus = &dev_priv->gmbus[pin];
>> i2c_del_adapter(&bus->adapter);
>> +
>> +kfree(bus);
>> +dev_priv->gmbus[pin] = NULL;
>
> I see we don't actually check intel_gmbus_setup() return value at all so
> intel_gmbus_teardown() can get called twice. So this NULLing is essential
> should intel_gmbus_setup() ever fail.
>
> Series is
> Reviewed-by: Ville Syrjälä
>
>> }
>> }
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 457bc1993d19..869a2bda347b 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -35,7 +35,6 @@
>> #include
>>
>> #include
>> -#include
>> #include
>> #include
>>
>> @@ -99,6 +98,7 @@ struct intel_dpll_funcs;
>> struct intel_encoder;
>> struct intel_fbdev;
>> struct intel_fdi_funcs;
>> +struct intel_gmbus;
>> struct intel_hotplug_funcs;
>> struct intel_initial_plane_config;
>> struct intel_limit;
>> @@ -231,16 +231,6 @@ struct i915_drrs {
>> #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
>> #define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
>>
>> -struct intel_gmbus {
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix bandwith related cdclk calculations (rev2)
== Series Details ==
Series: drm/i915: Fix bandwith related cdclk calculations (rev2)
URL : https://patchwork.freedesktop.org/series/98975/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11320_full -> Patchwork_22477_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22477_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_schedule@smoketest-all:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-rkl-2/igt@gem_exec_sched...@smoketest-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/shard-rkl-5/igt@gem_exec_sched...@smoketest-all.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt:
- {shard-rkl}:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/shard-rkl-5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-gtt.html
* {igt@kms_plane_scaling@planes-scaling-unity-scaling}:
- {shard-rkl}:NOTRUN -> [SKIP][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/shard-rkl-5/igt@kms_plane_scal...@planes-scaling-unity-scaling.html
*
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale}:
- shard-iclb: [PASS][5] -> [SKIP][6] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
* igt@prime_mmap@test_forked:
- {shard-dg1}:NOTRUN -> [SKIP][7] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22477/shard-dg1-15/igt@prime_mmap@test_forked.html
Known issues
Here are the changes found in Patchwork_22477_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-apl: ([PASS][8], [PASS][9], [PASS][10], [PASS][11],
[PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17],
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32]) ([i915#4386]) -> ([PASS][33], [PASS][34],
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40],
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46],
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
[PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl1/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl3/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/shard-apl4/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11320/s
[Intel-gfx] ✓ Fi.CI.BAT: success for vm- and vma cleanups (rev2)
== Series Details == Series: vm- and vma cleanups (rev2) URL : https://patchwork.freedesktop.org/series/100945/ State : success == Summary == CI Bug Log - changes from CI_DRM_11326 -> Patchwork_22485 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/index.html Participating hosts (45 -> 44) -- Additional (2): bat-adlp-4 fi-pnv-d510 Missing(3): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus Known issues Here are the changes found in Patchwork_22485 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-rkl-guc: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [PASS][2] -> [INCOMPLETE][3] ([i915#146]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3282]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@gem_tiled_pread_basic.html * igt@i915_pm_rpm@module-reload: - bat-adlp-4: NOTRUN -> [DMESG-WARN][8] ([i915#3576]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@dp-crc-fast: - bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][11] ([fdo#109271]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-adlp-4: NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlp-4: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: NOTRUN -> [FAIL][15] ([i915#4547]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@prime_vgem@basic-fence-read: - bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3291] / [i915#3708]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-userptr: - fi-pnv-d510:NOTRUN -> [SKIP][17] ([fdo#109271]) +57 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/fi-pnv-d510/igt@prime_v...@basic-userptr.html - bat-adlp-4: NOTRUN -> [SKIP][18] ([i915#3301] / [i915#3708]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22485/bat-adlp-4/igt@prime_v...@basic-userptr.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [INCOMPLETE][19] ([i915#4547]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11326/fi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for vm- and vma cleanups (rev2)
== Series Details == Series: vm- and vma cleanups (rev2) URL : https://patchwork.freedesktop.org/series/100945/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH v3 3/3] drm/i915/gem: Remove some unnecessary code
The test for vma should always return true, and when assigning -EBUSY
to ret, the variable should already have that value.
Signed-off-by: Thomas Hellström
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c26110abcc0b..9747924cc57b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -118,6 +118,7 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
unsigned long flags)
{
struct intel_runtime_pm *rpm = &to_i915(obj->base.dev)->runtime_pm;
+ bool vm_trylock = !!(flags & I915_GEM_OBJECT_UNBIND_VM_TRYLOCK);
LIST_HEAD(still_in_list);
intel_wakeref_t wakeref;
struct i915_vma *vma;
@@ -170,26 +171,21 @@ int i915_gem_object_unbind(struct drm_i915_gem_object
*obj,
* and destroy the vma from under us.
*/
- if (vma) {
- bool vm_trylock = !!(flags &
I915_GEM_OBJECT_UNBIND_VM_TRYLOCK);
- ret = -EBUSY;
- if (flags & I915_GEM_OBJECT_UNBIND_ASYNC) {
- assert_object_held(vma->obj);
- ret = i915_vma_unbind_async(vma, vm_trylock);
- }
+ ret = -EBUSY;
+ if (flags & I915_GEM_OBJECT_UNBIND_ASYNC) {
+ assert_object_held(vma->obj);
+ ret = i915_vma_unbind_async(vma, vm_trylock);
+ }
- if (ret == -EBUSY && (flags &
I915_GEM_OBJECT_UNBIND_ACTIVE ||
- !i915_vma_is_active(vma))) {
- if (vm_trylock) {
- if (mutex_trylock(&vma->vm->mutex)) {
- ret = __i915_vma_unbind(vma);
- mutex_unlock(&vma->vm->mutex);
- } else {
- ret = -EBUSY;
- }
- } else {
- ret = i915_vma_unbind(vma);
+ if (ret == -EBUSY && (flags & I915_GEM_OBJECT_UNBIND_ACTIVE ||
+ !i915_vma_is_active(vma))) {
+ if (vm_trylock) {
+ if (mutex_trylock(&vma->vm->mutex)) {
+ ret = __i915_vma_unbind(vma);
+ mutex_unlock(&vma->vm->mutex);
}
+ } else {
+ ret = i915_vma_unbind(vma);
}
}
--
2.34.1
[Intel-gfx] [PATCH v3 2/3] drm/i915: Remove the vma refcount
Now that i915_vma_parked() is taking the object lock on vma destruction,
and the only user of the vma refcount, i915_gem_object_unbind()
also takes the object lock, remove the vma refcount.
v3: Documentation update.
Signed-off-by: Thomas Hellström
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_gem.c | 17 +
drivers/gpu/drm/i915/i915_vma.c | 17 +++--
drivers/gpu/drm/i915/i915_vma.h | 14 --
drivers/gpu/drm/i915/i915_vma_types.h | 1 -
4 files changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dd84ebabb50f..c26110abcc0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -151,14 +151,25 @@ int i915_gem_object_unbind(struct drm_i915_gem_object
*obj,
break;
}
+ /*
+* Requiring the vm destructor to take the object lock
+* before destroying a vma would help us eliminate the
+* i915_vm_tryget() here, AND thus also the barrier stuff
+* at the end. That's an easy fix, but sleeping locks in
+* a kthread should generally be avoided.
+*/
ret = -EAGAIN;
if (!i915_vm_tryget(vma->vm))
break;
- /* Prevent vma being freed by i915_vma_parked as we unbind */
- vma = __i915_vma_get(vma);
spin_unlock(&obj->vma.lock);
+ /*
+* Since i915_vma_parked() takes the object lock
+* before vma destruction, it won't race us here,
+* and destroy the vma from under us.
+*/
+
if (vma) {
bool vm_trylock = !!(flags &
I915_GEM_OBJECT_UNBIND_VM_TRYLOCK);
ret = -EBUSY;
@@ -180,8 +191,6 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
ret = i915_vma_unbind(vma);
}
}
-
- __i915_vma_put(vma);
}
i915_vm_put(vma->vm);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index cfa8a212b4dd..249a38585289 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -122,7 +122,6 @@ vma_create(struct drm_i915_gem_object *obj,
if (vma == NULL)
return ERR_PTR(-ENOMEM);
- kref_init(&vma->ref);
vma->ops = &vm->vma_ops;
vma->obj = obj;
vma->size = obj->base.size;
@@ -1628,15 +1627,6 @@ void i915_vma_reopen(struct i915_vma *vma)
__i915_vma_remove_closed(vma);
}
-void i915_vma_release(struct kref *ref)
-{
- struct i915_vma *vma = container_of(ref, typeof(*vma), ref);
-
- i915_active_fini(&vma->active);
- GEM_WARN_ON(vma->resource);
- i915_vma_free(vma);
-}
-
static void force_unbind(struct i915_vma *vma)
{
if (!drm_mm_node_allocated(&vma->node))
@@ -1665,7 +1655,9 @@ static void release_references(struct i915_vma *vma, bool
vm_ddestroy)
if (vm_ddestroy)
i915_vm_resv_put(vma->vm);
- __i915_vma_put(vma);
+ i915_active_fini(&vma->active);
+ GEM_WARN_ON(vma->resource);
+ i915_vma_free(vma);
}
/**
@@ -1693,9 +1685,6 @@ static void release_references(struct i915_vma *vma, bool
vm_ddestroy)
* - vm->mutex
* - obj->vma.lock
* - gt->closed_lock
- *
- * A vma user can also temporarily keep the vma alive while holding a vma
- * reference.
*/
void i915_vma_destroy_locked(struct i915_vma *vma)
{
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 67ae7341c7e0..6034991d89fe 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -222,20 +222,6 @@ void i915_vma_unlink_ctx(struct i915_vma *vma);
void i915_vma_close(struct i915_vma *vma);
void i915_vma_reopen(struct i915_vma *vma);
-static inline struct i915_vma *__i915_vma_get(struct i915_vma *vma)
-{
- if (kref_get_unless_zero(&vma->ref))
- return vma;
-
- return NULL;
-}
-
-void i915_vma_release(struct kref *ref);
-static inline void __i915_vma_put(struct i915_vma *vma)
-{
- kref_put(&vma->ref, i915_vma_release);
-}
-
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h
b/drivers/gpu/drm/i915/i915_vma_types.h
index eac36be184e5..be6e028c3b57 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -211,7 +211,6 @@ struct i915_vma {
* handles (but same file) for execbuf, i.e. the number of aliases
* that exist in the ctx->handle_vmas LUT for this vma.
*/
- struct kref ref;
atomic
[Intel-gfx] [PATCH v3 0/3] vm- and vma cleanups
The first patch of the series addresses a vm open count bug by removing the vm open count. The second patch removes the vma refcount that is no longer needed; the vma is kept a live by taking the vm refcount and object lock. Finally the last patch removes some unnecessary code. There should be no functional changes. v3: - Documentation fixes - Added R-Bs Thomas Hellström (3): drm/i915: Remove the vm open count drm/i915: Remove the vma refcount drm/i915/gem: Remove some unnecessary code drivers/gpu/drm/i915/display/intel_dpt.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 29 ++- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++ .../gpu/drm/i915/gem/selftests/mock_context.c | 5 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 +++ drivers/gpu/drm/i915/gt/intel_gtt.c | 54 drivers/gpu/drm/i915/gt/intel_gtt.h | 56 drivers/gpu/drm/i915/gt/selftest_execlists.c | 86 +-- drivers/gpu/drm/i915/i915_gem.c | 55 ++-- drivers/gpu/drm/i915/i915_vma.c | 80 ++--- drivers/gpu/drm/i915/i915_vma.h | 14 --- drivers/gpu/drm/i915/i915_vma_resource.c | 2 +- drivers/gpu/drm/i915/i915_vma_resource.h | 6 ++ drivers/gpu/drm/i915/i915_vma_types.h | 8 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- 16 files changed, 222 insertions(+), 217 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v3 1/3] drm/i915: Remove the vm open count
vms are not getting properly closed. Rather than fixing that,
Remove the vm open count and instead rely on the vm refcount.
The vm open count existed solely to break the strong references the
vmas had on the vms. Now instead make those references weak and
ensure vmas are destroyed when the vm is destroyed.
Unfortunately if the vm destructor and the object destructor both
wants to destroy a vma, that may lead to a race in that the vm
destructor just unbinds the vma and leaves the actual vma destruction
to the object destructor. However in order for the object destructor
to ensure the vma is unbound it needs to grab the vm mutex. In order
to keep the vm mutex alive until the object destructor is done with
it, somewhat hackishly grab a vm_resv refcount that is released late
in the vma destruction process, when the vm mutex is no longer needed.
v2: Address review-comments from Niranjana
- Clarify that the struct i915_address_space::skip_pte_rewrite is a hack
and should ideally be replaced in an upcoming patch.
- Remove an unneeded continue in clear_vm_list and update comment.
v3:
- Documentation update
- Commit message formatting
Co-developed-by: Niranjana Vishwanathapura
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Thomas Hellström
Reviewed-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 29 ++-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++
.../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 54
drivers/gpu/drm/i915/gt/intel_gtt.h | 56
drivers/gpu/drm/i915/gt/selftest_execlists.c | 86 +--
drivers/gpu/drm/i915/i915_gem.c | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 63 ++
drivers/gpu/drm/i915/i915_vma_resource.c | 2 +-
drivers/gpu/drm/i915/i915_vma_resource.h | 6 ++
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
15 files changed, 192 insertions(+), 166 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 05dd7dba3a5c..3af4930c1095 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -300,5 +300,5 @@ void intel_dpt_destroy(struct i915_address_space *vm)
{
struct i915_dpt *dpt = i915_vm_to_dpt(vm);
- i915_vm_close(&dpt->vm);
+ i915_vm_put(&dpt->vm);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index bc6d59df064d..fe872e02b395 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1456,8 +1456,6 @@ static void set_closed_name(struct i915_gem_context *ctx)
static void context_close(struct i915_gem_context *ctx)
{
- struct i915_address_space *vm;
-
/* Flush any concurrent set_engines() */
mutex_lock(&ctx->engines_mutex);
unpin_engines(__context_engines_static(ctx));
@@ -1469,19 +1467,6 @@ static void context_close(struct i915_gem_context *ctx)
set_closed_name(ctx);
- vm = ctx->vm;
- if (vm) {
- /* i915_vm_close drops the final reference, which is a bit too
-* early and could result in surprises with concurrent
-* operations racing with thist ctx close. Keep a full reference
-* until the end.
-*/
- i915_vm_get(vm);
- i915_vm_close(vm);
- }
-
- ctx->file_priv = ERR_PTR(-EBADF);
-
/*
* The LUT uses the VMA as a backpointer to unref the object,
* so we need to clear the LUT before we close all the VMA (inside
@@ -1489,6 +1474,8 @@ static void context_close(struct i915_gem_context *ctx)
*/
lut_close(ctx);
+ ctx->file_priv = ERR_PTR(-EBADF);
+
spin_lock(&ctx->i915->gem.contexts.lock);
list_del(&ctx->link);
spin_unlock(&ctx->i915->gem.contexts.lock);
@@ -1587,12 +1574,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
}
vm = &ppgtt->vm;
}
- if (vm) {
- ctx->vm = i915_vm_open(vm);
-
- /* i915_vm_open() takes a reference */
- i915_vm_put(vm);
- }
+ if (vm)
+ ctx->vm = vm;
mutex_init(&ctx->engines_mutex);
if (pc->num_user_engines >= 0) {
@@ -1642,7 +1625,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
free_engines(e);
err_vm:
if (ctx->vm)
- i915_vm_close(ctx->vm);
+ i915_vm_put(ctx->vm);
err_ctx:
kfree(ctx);
return ERR_PTR(err);
@@ -1826
