[Intel-gfx] [PATCH v2 8/8] drm/i915: Rename QGV request/response bits
From: Ville Syrjälä
Name all the ICL_PCODE_SAGV_DE_MEM_SS_CONFIG request/response
bits in a manner that we can actually understand what they're
doing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 18 --
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index b794545ff81d..395e48930b08 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -124,8 +124,8 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
/* bspec says to keep retrying for at least 1 ms */
ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
points_mask,
- ICL_PCODE_POINTS_RESTRICTED_MASK,
- ICL_PCODE_POINTS_RESTRICTED,
+ ICL_PCODE_REP_QGV_MASK |
ADLS_PCODE_REP_PSF_MASK,
+ ICL_PCODE_REP_QGV_SAFE |
ADLS_PCODE_REP_PSF_SAFE,
1);
if (ret < 0) {
@@ -833,7 +833,7 @@ static u16 icl_qgv_points_mask(struct drm_i915_private
*i915)
if (num_psf_gv_points > 0)
psf_points = GENMASK(num_psf_gv_points - 1, 0);
- return ADLS_QGV_PT(qgv_points) | ADLS_PSF_PT(psf_points);
+ return ICL_PCODE_REQ_QGV_PT(qgv_points) |
ADLS_PCODE_REQ_PSF_PT(psf_points);
}
static int intel_bw_check_data_rate(struct intel_atomic_state *state, bool
*changed)
@@ -1000,7 +1000,8 @@ int intel_bw_atomic_check(struct intel_atomic_state
*state)
* actually accepts as a parameter.
*/
new_bw_state->qgv_points_mask =
- ~(ADLS_QGV_PT(qgv_points) | ADLS_PSF_PT(psf_points)) &
+ ~(ICL_PCODE_REQ_QGV_PT(qgv_points) |
+ ADLS_PCODE_REQ_PSF_PT(psf_points)) &
icl_qgv_points_mask(dev_priv);
/*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 48a12f6c19b4..504499fad97d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6720,12 +6720,18 @@
#define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)(((point) <<
16) | (0x1 << 8))
#define ADL_PCODE_MEM_SS_READ_PSF_GV_INFO ((0) | (0x2 << 8))
#define ICL_PCODE_SAGV_DE_MEM_SS_CONFIG 0xe
-#define ICL_PCODE_POINTS_RESTRICTED0x0
-#define ICL_PCODE_POINTS_RESTRICTED_MASK 0xf
-#define ADLS_QGV_PT_MASK REG_GENMASK(7, 0)
-#define ADLS_QGV_PT(x)
REG_FIELD_PREP(ADLS_QGV_PT_MASK, (x))
-#define ADLS_PSF_PT_MASK REG_GENMASK(10, 8)
-#define ADLS_PSF_PT(x)
REG_FIELD_PREP(ADLS_PSF_PT_MASK, (x))
+#define ICL_PCODE_REP_QGV_MASK REG_GENMASK(1, 0)
+#define ICL_PCODE_REP_QGV_SAFE
REG_FIELD_PREP(ICL_PCODE_REP_QGV_MASK, 0)
+#define ICL_PCODE_REP_QGV_POLL
REG_FIELD_PREP(ICL_PCODE_REP_QGV_MASK, 1)
+#define ICL_PCODE_REP_QGV_REJECTED
REG_FIELD_PREP(ICL_PCODE_REP_QGV_MASK, 2)
+#define ADLS_PCODE_REP_PSF_MASKREG_GENMASK(3, 2)
+#define ADLS_PCODE_REP_PSF_SAFE
REG_FIELD_PREP(ADLS_PCODE_REP_PSF_MASK, 0)
+#define ADLS_PCODE_REP_PSF_POLL
REG_FIELD_PREP(ADLS_PCODE_REP_PSF_MASK, 1)
+#define ADLS_PCODE_REP_PSF_REJECTED
REG_FIELD_PREP(ADLS_PCODE_REP_PSF_MASK, 2)
+#define ICL_PCODE_REQ_QGV_PT_MASK REG_GENMASK(7, 0)
+#define ICL_PCODE_REQ_QGV_PT(x)
REG_FIELD_PREP(ICL_PCODE_REQ_QGV_PT_MASK, (x))
+#define ADLS_PCODE_REQ_PSF_PT_MASK REG_GENMASK(10, 8)
+#define ADLS_PCODE_REQ_PSF_PT(x)
REG_FIELD_PREP(ADLS_PCODE_REQ_PSF_PT_MASK, (x))
#define GEN6_PCODE_READ_D_COMP 0x10
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define ICL_PCODE_EXIT_TCCOLD0x12
--
2.34.1
[Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
From: Ville Syrjälä
Don't just mask off all the PSF GV points when SAGV gets disabled.
This should in fact cause the Pcode to reject the request since
at least one PSF point must remain enabled at all times.
Cc: sta...@vger.kernel.org
Cc: Stanislav Lisovskiy
Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index ad1564ca7269..adf58c58513b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -992,7 +992,8 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
* cause.
*/
if (!intel_can_enable_sagv(dev_priv, new_bw_state)) {
- allowed_points = BIT(max_bw_point);
+ allowed_points &= ADLS_PSF_PT_MASK;
+ allowed_points |= BIT(max_bw_point);
drm_dbg_kms(&dev_priv->drm, "No SAGV, using single QGV point
%d\n",
max_bw_point);
}
--
2.34.1
[Intel-gfx] [PATCH v2 4/8] drm/i915: Reject excessive SAGV block time
From: Ville Syrjälä If the mailbox returns an exceesively large SAGV block time let's just reject it. This avoids having to worry about overflows when we add the SAGV block time to the wm0 latency. We shall put the limit arbitrarily at U16_MAX. >65msec latency doesn't really make sense to me in any case. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 36f5bccabf64..166246fa27e4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3716,6 +3716,12 @@ static void intel_sagv_init(struct drm_i915_private *i915) drm_dbg_kms(&i915->drm, "SAGV supported: %s, original SAGV block time: %u us\n", str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us); + /* avoid overflow when adding with wm0 latency/etc. */ + if (drm_WARN(&i915->drm, i915->sagv_block_time_us > U16_MAX, +"Excessive SAGV block time %u, ignoring\n", +i915->sagv_block_time_us)) + i915->sagv_block_time_us = 0; + if (!intel_has_sagv(i915)) i915->sagv_block_time_us = 0; } -- 2.34.1
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Do not re-enable PSR after it was marked as not reliable
On Wed, 2022-03-09 at 13:51 +, Hogander, Jouni wrote:
> Hello Jose,
>
> See my question/comment below.
>
> On Tue, 2022-03-08 at 07:41 -0800, José Roberto de Souza wrote:
> > If a error happens and sink_not_reliable is set, PSR should be
> > disabled
> > for good but that is not happening.
> > It would be disabled by the function handling the PSR error but then
> > on the next fastset it would be enabled again in
> > _intel_psr_post_plane_update().
> > It would only be disabled for good in the next modeset where has_psr
> > will be set false.
>
> How about invalidate/flush? If you get error between
> intel_psr_invalidate and intel_psr_flush psr is activated
> even sink_not_reliable is true?
enabled != activated.
flush and invalidate functions checks if PSR is enabled, if not it returns and
do a thing.
>
> >
> > Fixes: 9ce5884e5139 ("drm/i915/display: Only keep PSR enabled if
> > there is active planes")
> > Reported-by: Khaled Almahallawy
> > Reported-by: Charlton Lin
> > Cc: Jouni Högander
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index bbd581ed08159..cd05e5fdc8ca9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1853,6 +1853,9 @@ static void _intel_psr_post_plane_update(const
> > struct intel_atomic_state *state,
> >
> > mutex_lock(&psr->lock);
> >
> > + if (psr->sink_not_reliable)
> > + continue;
> > +
> > drm_WARN_ON(&dev_priv->drm, psr->enabled &&
> > !crtc_state->active_planes);
> >
> > /* Only enable if there is active planes */
>
> BR,
>
> Jouni Högander
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev5)
== Series Details == Series: drm/i915: Clean up some dpll stuff (rev5) URL : https://patchwork.freedesktop.org/series/100899/ 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] ALSA: hda/i915 - avoid hung task timeout in i915 wait
If kernel is built with hung task detection enabled and
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds,
snd_hdac_i915_init() will trigger the hung task timeout in case i915 is
not available and taint the kernel.
Use wait_for_completion_killable_timeout() for the wait to
avoid this problem.
Co-developed-by: Ramalingam C
Signed-off-by: Ramalingam C
Signed-off-by: Kai Vehmanen
---
sound/hda/hdac_i915.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Changes V2->V3:
- drop the loop and just use
wait_for_completion_killable_timeout() (feedback from Tvrtko Ursulin)
- new approach, so dropped the previous reviewed-by tags
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 454474ac5716..efe810af28c5 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -160,8 +160,8 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
if (!IS_ENABLED(CONFIG_MODULES) ||
!request_module("i915")) {
/* 60s timeout */
-
wait_for_completion_timeout(&acomp->master_bind_complete,
- msecs_to_jiffies(60 *
1000));
+
wait_for_completion_killable_timeout(&acomp->master_bind_complete,
+
msecs_to_jiffies(60 * 1000));
}
}
if (!acomp->ops) {
base-commit: 3a0099a1909dea6022690b0ae496938dd2e5771c
--
2.35.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2)
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2) URL : https://patchwork.freedesktop.org/series/101123/ State : warning == Summary == $ dim checkpatch origin/drm-tip 14d91959f9bf drm/mm: Add an iterator to optimally walk over holes for an allocation (v6) -:160: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects? #160: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + (mode) & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = (mode) & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + (mode) & ~DRM_MM_INSERT_ONCE)) -:160: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mm' - possible side-effects? #160: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + (mode) & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = (mode) & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + (mode) & ~DRM_MM_INSERT_ONCE)) -:160: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'size' - possible side-effects? #160: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + (mode) & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = (mode) & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + (mode) & ~DRM_MM_INSERT_ONCE)) -:160: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mode' - possible side-effects? #160: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + (mode) & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = (mode) & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + (mode) & ~DRM_MM_INSERT_ONCE)) total: 0 errors, 0 warnings, 4 checks, 114 lines checked f39e77441008 drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2)
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2) URL : https://patchwork.freedesktop.org/series/101123/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't just mask off all the PSF GV points when SAGV gets disabled.
> This should in fact cause the Pcode to reject the request since
> at least one PSF point must remain enabled at all times.
Good point, however I think this is not the full fix:
BSpec says:
"At least one GV point of each type must always remain unmasked."
and
"The GV point of each type providing the highest bandwidth
for display must always remain unmasked."
So I guess we should then also choose thr PSF GV point with
the highest bandwidth as well.
Stan
>
> Cc: sta...@vger.kernel.org
> Cc: Stanislav Lisovskiy
> Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index ad1564ca7269..adf58c58513b 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -992,7 +992,8 @@ int intel_bw_atomic_check(struct intel_atomic_state
> *state)
>* cause.
>*/
> if (!intel_can_enable_sagv(dev_priv, new_bw_state)) {
> - allowed_points = BIT(max_bw_point);
> + allowed_points &= ADLS_PSF_PT_MASK;
> + allowed_points |= BIT(max_bw_point);
> drm_dbg_kms(&dev_priv->drm, "No SAGV, using single QGV point
> %d\n",
> max_bw_point);
> }
> --
> 2.34.1
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up some dpll stuff (rev5)
== Series Details == Series: drm/i915: Clean up some dpll stuff (rev5) URL : https://patchwork.freedesktop.org/series/100899/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11346 -> Patchwork_22522 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22522 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22522, 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_22522/index.html Participating hosts (43 -> 36) -- Additional (2): fi-icl-u2 fi-pnv-d510 Missing(9): bat-dg1-6 bat-dg1-5 bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22522: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-bsw-n3050: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-bsw-n3050/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_22522 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_22522/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][5] ([fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#109278]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][7] ([fdo#109285]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_setmode@basic-clone-single-crtc: - fi-icl-u2: NOTRUN -> [SKIP][8] ([i915#3555]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-userptr: - fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +58 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-pnv-d510/igt@prime_v...@basic-userptr.html - fi-icl-u2: NOTRUN -> [SKIP][10] ([i915#3301]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-icl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-glk-j4005: NOTRUN -> [FAIL][11] ([i915#5257] / [k.org#202321]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-glk-j4005/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-blb-e6850: [FAIL][12] ([i915#3194]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22522/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257 [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321 Build changes - * Linux: CI_DRM_11346 -> Patchwork_22522 CI-20190529: 20190
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote: > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Don't just mask off all the PSF GV points when SAGV gets disabled. > > This should in fact cause the Pcode to reject the request since > > at least one PSF point must remain enabled at all times. > > Good point, however I think this is not the full fix: > > BSpec says: > > "At least one GV point of each type must always remain unmasked." > > and > > "The GV point of each type providing the highest bandwidth > for display must always remain unmasked." > > So I guess we should then also choose thr PSF GV point with > the highest bandwidth as well. The spec says PSF GV is fast enough to now stall the display data fetch so we don't need to restrict the PSF points here. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled
On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > For modern platforms the spec explicitly states that a > SAGV block time of zero means that SAGV is not supported. > Let's extend that to all platforms. Supposedly there should > be no systems where this isn't true, and it'll allow us to: > - use the same code regardless of older vs. newer platform > - wm latencies already treat 0 as disabled, so this fits well > with other related code > - make it a bit more clear when SAGV is used vs. not > - avoid overflows from adding U32_MAX with a u16 wm0 latency value > which could cause us to miscalculate the SAGV watermarks on tgl+ > > Cc: sta...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 8ee31c9590a7..40a3094e55ca 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private > *dev_priv) > MISSING_CASE(DISPLAY_VER(dev_priv)); > } > > - /* Default to an unusable block time */ > - dev_priv->sagv_block_time_us = -1; > + dev_priv->sagv_block_time_us = 0; > } > > /* > @@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct > intel_crtc_state *crtc_state, > result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1; > result->enable = true; > > - if (DISPLAY_VER(dev_priv) < 12) > + if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us) > result->can_sagv = latency >= dev_priv->sagv_block_time_us; > } > > @@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct > intel_crtc_state *crtc_state, > struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev); > struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0; > struct skl_wm_level *levels = plane_wm->wm; > - unsigned int latency = dev_priv->wm.skl_latency[0] + > dev_priv->sagv_block_time_us; > + unsigned int latency = 0; > + > + if (dev_priv->sagv_block_time_us) > + latency = dev_priv->sagv_block_time_us + > dev_priv->wm.skl_latency[0]; Should we may be add this to intel_has_sagv? I thought this was supposed to tell, if SAGV is supported or not. Should we just call it hear as well, may be.. Now we kinda making it less obvious. Stan > > skl_compute_plane_wm(crtc_state, plane, 0, latency, >wm_params, &levels[0], > -- > 2.34.1 >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2)
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2) URL : https://patchwork.freedesktop.org/series/101123/ State : success == Summary == CI Bug Log - changes from CI_DRM_11346 -> Patchwork_22523 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/index.html Participating hosts (43 -> 35) -- Additional (1): fi-icl-u2 Missing(9): bat-dg1-6 bat-dg1-5 bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_22523 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][4] -> [DMESG-FAIL][5] ([i915#541]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#4785]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][9] ([fdo#109278]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#109285]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_setmode@basic-clone-single-crtc: - fi-icl-u2: NOTRUN -> [SKIP][11] ([i915#3555]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-userptr: - fi-icl-u2: NOTRUN -> [SKIP][12] ([i915#3301]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-icl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#1436] / [i915#4312]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-hsw-4770/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-blb-e6850: [FAIL][14] ([i915#3194]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Build changes - * Linux: CI_DRM_11346 -> Patchwork_2252
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: SAGV block time fixes (rev2)
== Series Details == Series: drm/i915: SAGV block time fixes (rev2) URL : https://patchwork.freedesktop.org/series/101171/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote: > On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote: > > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Don't just mask off all the PSF GV points when SAGV gets disabled. > > > This should in fact cause the Pcode to reject the request since > > > at least one PSF point must remain enabled at all times. > > > > Good point, however I think this is not the full fix: > > > > BSpec says: > > > > "At least one GV point of each type must always remain unmasked." > > > > and > > > > "The GV point of each type providing the highest bandwidth > > for display must always remain unmasked." > > > > So I guess we should then also choose thr PSF GV point with > > the highest bandwidth as well. > > The spec says PSF GV is fast enough to now stall the display data > fetch so we don't need to restrict the PSF points here. But why it asks to ensure that we have the PSF GV of highest bandwidth to stay always unmasked then? Stan > > -- > Ville Syrjälä > Intel
[Intel-gfx] ✗ Fi.CI.BUILD: failure for ALSA: hda/i915 - avoid hung task timeout in i915 wait (rev3)
== Series Details == Series: ALSA: hda/i915 - avoid hung task timeout in i915 wait (rev3) URL : https://patchwork.freedesktop.org/series/101156/ State : failure == Summary == Applying: ALSA: hda/i915 - avoid hung task timeout in i915 wait Using index info to reconstruct a base tree... M sound/hda/hdac_i915.c Falling back to patching base and 3-way merge... Auto-merging sound/hda/hdac_i915.c CONFLICT (content): Merge conflict in sound/hda/hdac_i915.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 ALSA: hda/i915 - avoid hung task timeout in i915 wait When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: SAGV block time fixes (rev2)
== Series Details ==
Series: drm/i915: SAGV block time fixes (rev2)
URL : https://patchwork.freedesktop.org/series/101171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11346 -> Patchwork_22524
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/index.html
Participating hosts (43 -> 35)
--
Additional (1): fi-pnv-d510
Missing(9): bat-dg1-6 bat-dg1-5 bat-dg2-9 fi-bsw-cyan bat-adlp-6
bat-adlp-4 fi-ctg-p8600 bat-jsl-2 bat-jsl-1
Known issues
Here are the changes found in Patchwork_22524 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][1] ([fdo#109271]) +58 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/fi-pnv-d510/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-blb-e6850: [FAIL][2] ([i915#3194]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][4] ([i915#5127]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-
* Linux: CI_DRM_11346 -> Patchwork_22524
CI-20190529: 20190529
CI_DRM_11346: ab6456d23719e60c20e8cef05a5f322eea134b88 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6373: 82306f1903c0fee8371f43a156d8b63163ca61c1 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22524: 947f302e9d2d4716c0cb2bed715c2b7085535fa9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
947f302e9d2d drm/i915: Rename QGV request/response bits
c745332be423 drm/i915: Unconfuses QGV vs. PSF point masks
a21de1e7d3fd drm/i915: Fix PSF GV point mask when SAGV is not possible
244e37910608 drm/i915: Rename pre-icl SAGV enable/disable functions
5eaafe273039 drm/i915: Reject excessive SAGV block time
e8e1719bfc7d drm/i915: Probe whether SAGV works on pre-icl
bc3dfeda81e4 drm/i915: Rework SAGV block time probing
060166c820c6 drm/i915: Treat SAGV block time 0 as SAGV disabled
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/index.html
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Fix PSF GV point mask when SAGV is not possible
On Wed, Mar 09, 2022 at 09:34:58PM +0200, Lisovskiy, Stanislav wrote: > On Wed, Mar 09, 2022 at 09:08:12PM +0200, Ville Syrjälä wrote: > > On Wed, Mar 09, 2022 at 08:59:59PM +0200, Lisovskiy, Stanislav wrote: > > > On Wed, Mar 09, 2022 at 06:49:46PM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > Don't just mask off all the PSF GV points when SAGV gets disabled. > > > > This should in fact cause the Pcode to reject the request since > > > > at least one PSF point must remain enabled at all times. > > > > > > Good point, however I think this is not the full fix: > > > > > > BSpec says: > > > > > > "At least one GV point of each type must always remain unmasked." > > > > > > and > > > > > > "The GV point of each type providing the highest bandwidth > > > for display must always remain unmasked." > > > > > > So I guess we should then also choose thr PSF GV point with > > > the highest bandwidth as well. > > > > The spec says PSF GV is fast enough to now stall the display data > > fetch so we don't need to restrict the PSF points here. > > But why it asks to ensure that we have the PSF GV of highest bandwidth to > stay always unmasked then? I presume so you don't lock the memory bandwdith to some lower performance point and hurt all the other things that need memory bandwidth. Either that or there is some internal implementation detail that simply doesn't work if you try to permanently run at a lower performance point. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Treat SAGV block time 0 as SAGV disabled
On Wed, Mar 09, 2022 at 09:29:58PM +0200, Lisovskiy, Stanislav wrote: > On Wed, Mar 09, 2022 at 06:49:41PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > For modern platforms the spec explicitly states that a > > SAGV block time of zero means that SAGV is not supported. > > Let's extend that to all platforms. Supposedly there should > > be no systems where this isn't true, and it'll allow us to: > > - use the same code regardless of older vs. newer platform > > - wm latencies already treat 0 as disabled, so this fits well > > with other related code > > - make it a bit more clear when SAGV is used vs. not > > - avoid overflows from adding U32_MAX with a u16 wm0 latency value > > which could cause us to miscalculate the SAGV watermarks on tgl+ > > > > Cc: sta...@vger.kernel.org > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_pm.c | 10 ++ > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 8ee31c9590a7..40a3094e55ca 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -3696,8 +3696,7 @@ skl_setup_sagv_block_time(struct drm_i915_private > > *dev_priv) > > MISSING_CASE(DISPLAY_VER(dev_priv)); > > } > > > > - /* Default to an unusable block time */ > > - dev_priv->sagv_block_time_us = -1; > > + dev_priv->sagv_block_time_us = 0; > > } > > > > /* > > @@ -5644,7 +5643,7 @@ static void skl_compute_plane_wm(const struct > > intel_crtc_state *crtc_state, > > result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1; > > result->enable = true; > > > > - if (DISPLAY_VER(dev_priv) < 12) > > + if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us) > > result->can_sagv = latency >= dev_priv->sagv_block_time_us; > > } > > > > @@ -5677,7 +5676,10 @@ static void tgl_compute_sagv_wm(const struct > > intel_crtc_state *crtc_state, > > struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev); > > struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0; > > struct skl_wm_level *levels = plane_wm->wm; > > - unsigned int latency = dev_priv->wm.skl_latency[0] + > > dev_priv->sagv_block_time_us; > > + unsigned int latency = 0; > > + > > + if (dev_priv->sagv_block_time_us) > > + latency = dev_priv->sagv_block_time_us + > > dev_priv->wm.skl_latency[0]; > > Should we may be add this to intel_has_sagv? I thought this was supposed to > tell, > if SAGV is supported or not. Should we just call it hear as well, may be.. > Now we kinda making it less obvious. We already use intel_has_sagv() to see if we should zero out the block time. I don't think I want to make it a full circle. > > Stan > > > > > skl_compute_plane_wm(crtc_state, plane, 0, latency, > > wm_params, &levels[0], > > -- > > 2.34.1 > > -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow
On 3/8/2022 01:43, Tvrtko Ursulin wrote:
On 03/03/2022 22:37, john.c.harri...@intel.com wrote:
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
then get confused by early timeouts, add limits when setting these
values.
v2: Add helper functins for clamping (review feedback from Tvrtko).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
(v1)
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..8208164c25e7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2218,13 +2218,24 @@ static inline u32
get_children_join_value(struct intel_context *ce,
static void guc_context_policy_init(struct intel_engine_cs *engine,
struct guc_lrc_desc *desc)
{
+ struct drm_device *drm = &engine->i915->drm;
+
desc->policy_flags = 0;
if (engine->flags & I915_ENGINE_WANT_FORCED_PREEMPTION)
desc->policy_flags |=
CONTEXT_POLICY_FLAG_PREEMPT_TO_IDLE;
/* NB: For both of these, zero means disabled. */
+ if (overflows_type(engine->props.timeslice_duration_ms * 1000,
+ desc->execution_quantum))
+ drm_warn_once(drm, "GuC interface cannot support %lums
timeslice!\n",
+ engine->props.timeslice_duration_ms);
desc->execution_quantum = engine->props.timeslice_duration_ms
* 1000;
+
+ if (overflows_type(engine->props.preempt_timeout_ms * 1000,
+ desc->preemption_timeout))
+ drm_warn_once(drm, "GuC interface cannot support %lums
preemption timeout!\n",
+ engine->props.preempt_timeout_ms);
desc->preemption_timeout = engine->props.preempt_timeout_ms *
1000;
}
As previously explained, this is wrong. If the check must be present
then it should be a BUG_ON as it is indicative of an internal driver
failure. There is already a top level helper function for ensuring all
range checks are done and the value is valid. If that is broken then
that is a bug and should have been caught in pre-merge testing or code
review. It is not possible for a bad value to get beyond that helper
function. That is the whole point of the helper. We do not double bag
every other value check in the driver. Once you have passed input
validation, the values are assumed to be correct. Otherwise we would
have every other line of code be a value check! And if somehow a bad
value did make it through, simply printing a once shot warning is
pointless. You are still going to get undefined behaviour potentially
leading to a totally broken system. E.g. your very big timeout has
overflowed and become extremely small, thus no batch buffer can ever
complete because they all get reset before they have even finished the
context switch in. That is a fundamentally broken system.
John.
With that:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gt/intel_engine.h | 6 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 69 +
drivers/gpu/drm/i915/gt/sysfs_engines.c | 25 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 9 +++
4 files changed, 99 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1c0ab05c3c40..d7044c4e526e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -351,4 +351,10 @@ intel_engine_get_hung_context(struct
intel_engine_cs *engine)
return engine->hung_ce;
}
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs
*engine, u64 value);
+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs
*engine, u64 value);
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine,
u64 value);
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64
value);
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs
*engine, u64 value);
+
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7447411a5b26..22e70e4e007c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -442,6 +442,26 @@ static int intel_engine_setup(struct intel_gt
*gt, enum intel_engine_id id,
engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
}
+ /* Cap properties according to any system limits */
+#define CLAMP_PROP(field) \
+ do { \
+ u64 clamp = intel_clamp_##field(engine, engine->props.field); \
+ if (clamp != engine->props.field) { \
+ drm_notice
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Improve long running OCL w/a for GuC submission
On 3/8/2022 01:41, Tvrtko Ursulin wrote: On 03/03/2022 22:37, john.c.harri...@intel.com wrote: From: John Harrison A workaround was added to the driver to allow OpenCL workloads to run 'forever' by disabling pre-emption on the RCS engine for Gen12. It is not totally unbound as the heartbeat will kick in eventually and cause a reset of the hung engine. However, this does not work well in GuC submission mode. In GuC mode, the pre-emption timeout is how GuC detects hung contexts and triggers a per engine reset. Thus, disabling the timeout means also losing all per engine reset ability. A full GT reset will still occur when the heartbeat finally expires, but that is a much more destructive and undesirable mechanism. The purpose of the workaround is actually to give OpenCL tasks longer to reach a pre-emption point after a pre-emption request has been issued. This is necessary because Gen12 does not support mid-thread pre-emption and OpenCL can have long running threads. So, rather than disabling the timeout completely, just set it to a 'long' value. v2: Review feedback from Tvrtko - must hard code the 'long' value instead of determining it algorithmically. So make it an extra CONFIG definition. Also, remove the execlist centric comment from the existing pre-emption timeout CONFIG option given that it applies to more than just execlists. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio (v1) Acked-by: Michal Mrozek --- drivers/gpu/drm/i915/Kconfig.profile | 26 +++ drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 ++-- 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 39328567c200..7cc38d25ee5c 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -57,10 +57,28 @@ config DRM_I915_PREEMPT_TIMEOUT default 640 # milliseconds help How long to wait (in milliseconds) for a preemption event to occur - when submitting a new context via execlists. If the current context - does not hit an arbitration point and yield to HW before the timer - expires, the HW will be reset to allow the more important context - to execute. + when submitting a new context. If the current context does not hit + an arbitration point and yield to HW before the timer expires, the + HW will be reset to allow the more important context to execute. + + This is adjustable via + /sys/class/drm/card?/engine/*/preempt_timeout_ms + + May be 0 to disable the timeout. + + The compiled in default may get overridden at driver probe time on + certain platforms and certain engines which will be reflected in the + sysfs control. + +config DRM_I915_PREEMPT_TIMEOUT_COMPUTE + int "Preempt timeout for compute engines (ms, jiffy granularity)" + default 7500 # milliseconds + help + How long to wait (in milliseconds) for a preemption event to occur + when submitting a new context to a compute capable engine. If the + current context does not hit an arbitration point and yield to HW + before the timer expires, the HW will be reset to allow the more + important context to execute. This is adjustable via /sys/class/drm/card?/engine/*/preempt_timeout_ms diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 4185c7338581..cc0954ad836a 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -438,9 +438,14 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id, engine->props.timeslice_duration_ms = CONFIG_DRM_I915_TIMESLICE_DURATION; - /* Override to uninterruptible for OpenCL workloads. */ + /* + * Mid-thread pre-emption is not available in Gen12. Unfortunately, + * some OpenCL workloads run quite long threads. That means they get + * reset due to not pre-empting in a timely manner. So, bump the + * pre-emption timeout value to be much higher for compute engines. + */ if (GRAPHICS_VER(i915) == 12 && (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE)) - engine->props.preempt_timeout_ms = 0; + engine->props.preempt_timeout_ms = CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE; I wouldn't go as far as adding a config option since as it is it only applies to Gen12 but Kconfig text says nothing about that. And I am not saying you should add a Gen12 specific config option, that would be weird. So IMO just drop it. You were the one arguing that the driver was illegally overriding the user's explicitly chosen settings, including the compile time config options. Just having a hardcoded magic number in the driver is the absolute worst kind of override there is. And technically, the config option is not Gen12 specific. It is actually compute specifi
[Intel-gfx] [PATCH v3 1/8] drm/i915: Store the /5 target clock in struct dpll on vlv/chv
From: Ville Syrjälä
Unify vlv/chv with earlier platforms so that the sturct dpll::dot
represents the /5 clock frequency (ie. DP symbol rate or HDMI
TMDS rate) rather than the *5 fast clock (/2 of the bitrate).
Makes life a little less confusing to get the same number back
in .dot which we fed into the DPLL algorithm.
v2: Actually just include the 5x in the final P divider
Do the same change to the hand rolled gvt code
v3: Missed a few *5 in *_find_best_dpll()
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll.c | 23 ++-
drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 0ae37fdbf2a5..53184154bc5d 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -254,12 +254,12 @@ static const struct intel_limit ilk_limits_dual_lvds_100m
= {
static const struct intel_limit intel_limits_vlv = {
/*
- * These are the data rate limits (measured in fast clocks)
+ * These are based on the data rate limits (measured in fast clocks)
* since those are the strictest limits we have. The fast
* clock and actual rate limits are more relaxed, so checking
* them would make no difference.
*/
- .dot = { .min = 25000 * 5, .max = 27 * 5 },
+ .dot = { .min = 25000, .max = 27 },
.vco = { .min = 400, .max = 600 },
.n = { .min = 1, .max = 7 },
.m1 = { .min = 2, .max = 3 },
@@ -270,12 +270,12 @@ static const struct intel_limit intel_limits_vlv = {
static const struct intel_limit intel_limits_chv = {
/*
-* These are the data rate limits (measured in fast clocks)
+* These are based on the data rate limits (measured in fast clocks)
* since those are the strictest limits we have. The fast
* clock and actual rate limits are more relaxed, so checking
* them would make no difference.
*/
- .dot = { .min = 25000 * 5, .max = 54 * 5},
+ .dot = { .min = 25000, .max = 54 },
.vco = { .min = 480, .max = 648 },
.n = { .min = 1, .max = 1 },
.m1 = { .min = 2, .max = 2 },
@@ -337,26 +337,26 @@ int i9xx_calc_dpll_params(int refclk, struct dpll *clock)
int vlv_calc_dpll_params(int refclk, struct dpll *clock)
{
clock->m = clock->m1 * clock->m2;
- clock->p = clock->p1 * clock->p2;
+ clock->p = clock->p1 * clock->p2 * 5;
if (WARN_ON(clock->n == 0 || clock->p == 0))
return 0;
clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
- return clock->dot / 5;
+ return clock->dot;
}
int chv_calc_dpll_params(int refclk, struct dpll *clock)
{
clock->m = clock->m1 * clock->m2;
- clock->p = clock->p1 * clock->p2;
+ clock->p = clock->p1 * clock->p2 * 5;
if (WARN_ON(clock->n == 0 || clock->p == 0))
return 0;
clock->vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock->m),
clock->n << 22);
clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
- return clock->dot / 5;
+ return clock->dot;
}
/*
@@ -659,8 +659,6 @@ vlv_find_best_dpll(const struct intel_limit *limit,
int max_n = min(limit->n.max, refclk / 19200);
bool found = false;
- target *= 5; /* fast clock */
-
memset(best_clock, 0, sizeof(*best_clock));
/* based on hardware requirement, prefer smaller n to precision */
@@ -668,7 +666,7 @@ vlv_find_best_dpll(const struct intel_limit *limit,
for (clock.p1 = limit->p1.max; clock.p1 >= limit->p1.min;
clock.p1--) {
for (clock.p2 = limit->p2.p2_fast; clock.p2 >=
limit->p2.p2_slow;
clock.p2 -= clock.p2 > 10 ? 2 : 1) {
- clock.p = clock.p1 * clock.p2;
+ clock.p = clock.p1 * clock.p2 * 5;
/* based on hardware requirement, prefer bigger
m1,m2 values */
for (clock.m1 = limit->m1.min; clock.m1 <=
limit->m1.max; clock.m1++) {
unsigned int ppm;
@@ -729,7 +727,6 @@ chv_find_best_dpll(const struct intel_limit *limit,
*/
clock.n = 1;
clock.m1 = 2;
- target *= 5;/* fast clock */
for (clock.p1 = limit->p1.max; clock.p1 >= limit->p1.min; clock.p1--) {
for (clock.p2 = limit->p2.p2_fast;
@@ -737,7 +734,7 @@ chv_find_best_dpll(const struct intel_limit *limit,
clock.p2 -= clock.p2 > 10 ? 2 : 1) {
unsigned int error_ppm;
-
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs
== Series Details ==
Series: drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs
URL : https://patchwork.freedesktop.org/series/101197/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11341_full -> Patchwork_22521_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22521_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22521_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_22521_full:
### IGT changes ###
Possible regressions
* igt@kms_draw_crc@draw-method-xrgb-render-4tiled:
- shard-iclb: NOTRUN -> [SKIP][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-iclb7/igt@kms_draw_...@draw-method-xrgb-render-4tiled.html
* igt@kms_hdr@bpc-switch-dpms@bpc-switch-dpms-edp-1-pipe-a:
- shard-skl: [PASS][2] -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/shard-skl4/igt@kms_hdr@bpc-switch-d...@bpc-switch-dpms-edp-1-pipe-a.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-skl7/igt@kms_hdr@bpc-switch-d...@bpc-switch-dpms-edp-1-pipe-a.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-dpms:
- {shard-rkl}:[PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/shard-rkl-6/igt@i915_pm...@dc6-dpms.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-rkl-5/igt@i915_pm...@dc6-dpms.html
* igt@kms_big_fb@4-tiled-32bpp-rotate-0:
- {shard-dg1}:NOTRUN -> [SKIP][6] +6 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-dg1-13/igt@kms_big...@4-tiled-32bpp-rotate-0.html
* igt@kms_big_fb@4-tiled-8bpp-rotate-90:
- {shard-tglu}: NOTRUN -> [SKIP][7] +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-tglu-4/igt@kms_big...@4-tiled-8bpp-rotate-90.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180:
- {shard-rkl}:NOTRUN -> [SKIP][8] +12 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-rkl-2/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180.html
* igt@kms_setmode@invalid-clone-exclusive-crtc:
- {shard-rkl}:([PASS][9], [SKIP][10]) -> [SKIP][11]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/shard-rkl-4/igt@kms_setm...@invalid-clone-exclusive-crtc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/shard-rkl-2/igt@kms_setm...@invalid-clone-exclusive-crtc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-rkl-6/igt@kms_setm...@invalid-clone-exclusive-crtc.html
Known issues
Here are the changes found in Patchwork_22521_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271]) +39 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-apl4/igt@feature_discov...@display-4x.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/shard-apl2/igt@gem_ctx_isolation@preservation...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_exec_balancer@parallel:
- shard-tglb: NOTRUN -> [DMESG-WARN][15] ([i915#5076])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-tglb2/igt@gem_exec_balan...@parallel.html
* igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][16] ([i915#5076])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-kbl1/igt@gem_exec_balan...@parallel-keep-submit-fence.html
* igt@gem_exec_capture@pi@vcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][17] ([i915#4547])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/shard-skl8/igt@gem_exec_capture@p...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][18] -> [FAIL][19] ([i915#2842])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Pat
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev6)
== Series Details == Series: drm/i915: Clean up some dpll stuff (rev6) URL : https://patchwork.freedesktop.org/series/100899/ 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.BAT: success for drm/i915: Clean up some dpll stuff (rev6)
== Series Details ==
Series: drm/i915: Clean up some dpll stuff (rev6)
URL : https://patchwork.freedesktop.org/series/100899/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11346 -> Patchwork_22526
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/index.html
Participating hosts (43 -> 44)
--
Additional (3): bat-rpls-2 fi-icl-u2 fi-pnv-d510
Missing(2): fi-ctg-p8600 fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22526:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_setmode@basic-clone-single-crtc:
- {bat-rpls-2}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/bat-rpls-2/igt@kms_setm...@basic-clone-single-crtc.html
Known issues
Here are the changes found in Patchwork_22526 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_22526/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][5] ([i915#2927] / [i915#4528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([fdo#109278]) +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [PASS][8] -> [DMESG-WARN][9] ([i915#3576]) +1 similar
issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#109285])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([i915#3555])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][12] ([fdo#109271]) +40 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-pnv-d510/igt@prime_v...@basic-userptr.html
- fi-icl-u2: NOTRUN -> [SKIP][13] ([i915#3301])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-icl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#2403] /
[i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-pnv-d510/igt@run...@aborted.html
- fi-bdw-5557u: NOTRUN -> [FAIL][15] ([i915#2426] / [i915#4312])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-blb-e6850: [FAIL][16] ([i915#3194]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [INCOMPLETE][18] ([i915#146]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/fi-bdw-5557u/igt@gem_exec_suspend@basic...@
Re: [Intel-gfx] [PATCH v10 1/5] drm/i915/gsc: add gsc as a mei auxiliary device
On 3/8/2022 8:36 AM, Alexander Usyskin wrote:
From: Tomas Winkler
GSC is a graphics system controller, it provides
a chassis controller for graphics discrete cards.
There are two MEI interfaces in GSC: HECI1 and HECI2.
Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000.
GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled
via bit 15 and HECI2 via bit 14 in the interrupt register.
This patch exports GSC as auxiliary device for mei driver to bind to
for HECI2 interface.
Do we need a test for this? E.g. to catch the unlikely case where we
stop exposing the GSC device. We are going to get some indirect coverage
once we start making use of the PXP interface from within the kernel,
would that be enough?
Also, IMO we need a line here to explain that we're adding the code for
HECI1 as well because we plan to follow up with it soon.
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Alexander Usyskin
Acked-by: Tvrtko Ursulin
---
MAINTAINERS | 1 +
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile| 3 +
drivers/gpu/drm/i915/gt/intel_gsc.c | 204 +++
drivers/gpu/drm/i915/gt/intel_gsc.h | 37
drivers/gpu/drm/i915/gt/intel_gt.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_drv.h | 8 +
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_device_info.h | 2 +
include/linux/mei_aux.h | 19 +++
15 files changed, 303 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.h
create mode 100644 include/linux/mei_aux.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b1d296f92e9..d322e630d1d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9822,6 +9822,7 @@ S:Supported
F:Documentation/driver-api/mei/*
F:drivers/misc/mei/
F:drivers/watchdog/mei_wdt.c
+F: include/linux/mei_aux.h
F:include/linux/mei_cl_bus.h
F:include/uapi/linux/mei.h
F:samples/mei/*
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 98c5450b8eac..2660a85175d9 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -30,6 +30,7 @@ config DRM_I915
select VMAP_PFN
select DRM_TTM
select DRM_BUDDY
+ select AUXILIARY_BUS
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1a771ee5b1d0..9be7b13d8822 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -196,6 +196,9 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_huc_debugfs.o \
gt/uc/intel_huc_fw.o
+# graphics system controller (GSC) support
+i915-y += gt/intel_gsc.o
+
# modesetting core code
i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c
b/drivers/gpu/drm/i915/gt/intel_gsc.c
new file mode 100644
index ..152804e7c41a
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2022, Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "intel_gsc.h"
A bit of inconsistency here because intel_gsc.h and intel_gt.h are both
in the gt/ folder but you're only prefixing one with gt/. Also, we
usually try to keep includes in alphabetical order, but overall not a
blocker for me.
+
+#define GSC_BAR_LENGTH 0x0FFC
+
+static void gsc_irq_mask(struct irq_data *d)
+{
+ /* generic irq handling */
+}
+
+static void gsc_irq_unmask(struct irq_data *d)
+{
+ /* generic irq handling */
+}
+
+static struct irq_chip gsc_irq_chip = {
+ .name = "gsc_irq_chip",
+ .irq_mask = gsc_irq_mask,
+ .irq_unmask = gsc_irq_unmask,
+};
+
+static int gsc_irq_init(int irq)
+{
+ irq_set_chip_and_handler_name(irq, &gsc_irq_chip,
+ handle_simple_irq, "gsc_irq_handler");
+
+ return irq_set_chip_data(irq, NULL);
+}
+
+struct intel_gsc_def {
+ const char *name;
+ unsigned long bar;
+ size_t bar_size;
+};
+
+/* gscfi (graphics system controller firmware interface) resources */
Should this comment be moved down in the array? the array has sections
for both pxp and gscfi resources, even if the former are not set. Or
maybe expand to something like:
/* for DG1 we only need g
Re: [Intel-gfx] [PATCH] drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs
On Wed, Mar 09, 2022 at 11:09:13AM +0200, Jani Nikula wrote:
> Commit ce2fce2513c5 ("drm/i915: Only include i915_reg.h from .c files")
> moved GEN12_SFC_DONE_MAX from i915_regs.h to i915_reg_defs.h. Arguably
> it belongs next to the GEN12_SFC_DONE() definition, as it describes the
> number of GEN12_SFC_DONE instances.
It should probably be replaced with an I915_MAX_SFC define instead,
since what we really care about is the number of SFC units rather than
the number of registers; there's always one register per SFC unit. Or
maybe even get rid of this completely and replace it with I915_MAX_VCS/2
since we expect there to be a 2:1:1 ratio of VCS:VECS:SFC.
Matt
>
> The unfortunate downside is obviously having to pull in intel_gt_regs.h
> in i915_gpu_error.h.
>
> Cc: Matt Roper
> Signed-off-by: Jani Nikula
>
> ---
>
> I guess the alternative is to define GEN12_SFC_DONE_MAX in
> i915_gpu_error.h, to avoid the extra include. No matter what, IMO it's
> really out of place in i915_reg_defs.h.
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.h | 1 +
> drivers/gpu/drm/i915/i915_reg_defs.h| 2 --
> 3 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 19cd34f24263..6bb987fe3289 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1502,5 +1502,6 @@
> #define GEN12_CCS2_CCS3_INTR_MASK_MMIO(0x190104)
>
> #define GEN12_SFC_DONE(n)_MMIO(0x1cc000 + (n) * 0x1000)
> +#define GEN12_SFC_DONE_MAX 4
>
> #endif /* __INTEL_GT_REGS__ */
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
> b/drivers/gpu/drm/i915/i915_gpu_error.h
> index 903d838e2e63..d29155aca84c 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.h
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.h
> @@ -15,6 +15,7 @@
> #include
>
> #include "gt/intel_engine.h"
> +#include "gt/intel_gt_regs.h"
> #include "gt/intel_gt_types.h"
> #include "gt/uc/intel_uc_fw.h"
>
> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
> b/drivers/gpu/drm/i915/i915_reg_defs.h
> index d78d78fce431..8f486f77609f 100644
> --- a/drivers/gpu/drm/i915/i915_reg_defs.h
> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h
> @@ -123,6 +123,4 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>
> #define VLV_DISPLAY_BASE 0x18
>
> -#define GEN12_SFC_DONE_MAX 4
> -
> #endif /* __I915_REG_DEFS__ */
> --
> 2.30.2
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH v7] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Thu, Mar 03, 2022 at 03:32:22PM -0800, Manasi Navare wrote:
> With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> settings.
> When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> MSA bit
> in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> the corresponding VRR Capable Connector property.
> Hence the userspace still sees this as VRR Capable panel which is incorrect.
>
> Fix this by explicitly resetting the connector property.
>
> v2: Reset vrr capable if status == connector_disconnected
> v3: Use i915 and use bool vrr_capable (Jani Nikula)
> v4: Move vrr_capable to after update modes call (Jani N)
> Remove the redundant comment (Jan N)
> v5: Fixes the regression on older platforms by reseting the VRR
> only if HAS_VRR
> v6: Remove the checks from driver, add in drm core before
> setting VRR prop (Ville)
> v7: Move VRR set/reset to set/unset_edid (Ville)
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> property on a long hpd")
> Signed-off-by: Manasi Navare
Looks reasoanble enough to me.
Reviewed-by: Ville Syrjälä
But be careful when pushing this since I don't think
the drm_connector_set_vrr_capable_property() change has
percolated into drm-intel-next yet.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6ef33096bb6..1d0f8fc39005 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4385,13 +4385,20 @@ intel_dp_update_420(struct intel_dp *intel_dp)
> static void
> intel_dp_set_edid(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_connector *connector = intel_dp->attached_connector;
> struct edid *edid;
> + bool vrr_capable;
>
> intel_dp_unset_edid(intel_dp);
> edid = intel_dp_get_edid(intel_dp);
> connector->detect_edid = edid;
>
> + vrr_capable = intel_vrr_is_capable(&connector->base);
> + drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> + connector->base.base.id, connector->base.name,
> str_yes_no(vrr_capable));
> + drm_connector_set_vrr_capable_property(&connector->base, vrr_capable);
> +
> intel_dp_update_dfp(intel_dp, edid);
> intel_dp_update_420(intel_dp);
>
> @@ -4424,6 +4431,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>
> intel_dp->dfp.ycbcr_444_to_420 = false;
> connector->base.ycbcr_420_allowed = false;
> +
> + drm_connector_set_vrr_capable_property(&connector->base,
> +false);
> }
>
> static int
> @@ -4574,14 +4584,9 @@ static int intel_dp_get_modes(struct drm_connector
> *connector)
> int num_modes = 0;
>
> edid = intel_connector->detect_edid;
> - if (edid) {
> + if (edid)
> num_modes = intel_connector_update_modes(connector, edid);
>
> - if (intel_vrr_is_capable(connector))
> - drm_connector_set_vrr_capable_property(connector,
> -true);
> - }
> -
> /* Also add fixed mode, which may or may not be present in EDID */
> if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
> intel_connector->panel.fixed_mode) {
> --
> 2.19.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v7 02/13] drm/i915/guc: Add XE_LP static registers for GuC error capture.
On Sat, Feb 26, 2022 at 01:55:30AM -0800, Alan Previn wrote:
Add device specific tables and register lists to cover different engines
class types for GuC error state capture for XE_LP products.
Signed-off-by: Alan Previn
lgtm,
Reviewed-by: Umesh Nerlige Ramappa
Umesh
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 116 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 4 +-
2 files changed, 97 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 647a118aa3c3..fb3ca734ef97 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -19,43 +19,109 @@
/*
* Define all device tables of GuC error capture register lists
- * NOTE: For engine-registers, GuC only needs the register offsets
- * from the engine-mmio-base
+ * NOTE1: For engine-registers, GuC only needs the register offsets
+ *from the engine-mmio-base
*/
+#define COMMON_GEN12BASE_GLOBAL() \
+ {GEN12_FAULT_TLB_DATA0,0, 0, "GEN12_FAULT_TLB_DATA0"}, \
+ {GEN12_FAULT_TLB_DATA1,0, 0, "GEN12_FAULT_TLB_DATA1"}, \
+ {FORCEWAKE_MT, 0, 0, "FORCEWAKE"}, \
+ {GEN12_AUX_ERR_DBG,0, 0, "AUX_ERR_DBG"}, \
+ {GEN12_GAM_DONE, 0, 0, "GAM_DONE"}, \
+ {GEN12_RING_FAULT_REG, 0, 0, "FAULT_REG"}
+
+#define COMMON_GEN12BASE_ENGINE_INSTANCE() \
+ {RING_PSMI_CTL(0), 0, 0, "RC PSMI"}, \
+ {RING_ESR(0), 0, 0, "ESR"}, \
+ {RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LDW"}, \
+ {RING_DMA_FADD_UDW(0), 0, 0, "RING_DMA_FADD_UDW"}, \
+ {RING_IPEIR(0),0, 0, "IPEIR"}, \
+ {RING_IPEHR(0),0, 0, "IPEHR"}, \
+ {RING_INSTPS(0), 0, 0, "INSTPS"}, \
+ {RING_BBADDR(0), 0, 0, "RING_BBADDR_LOW32"}, \
+ {RING_BBADDR_UDW(0), 0, 0, "RING_BBADDR_UP32"}, \
+ {RING_BBSTATE(0), 0, 0, "BB_STATE"}, \
+ {CCID(0), 0, 0, "CCID"}, \
+ {RING_ACTHD(0),0, 0, "ACTHD_LDW"}, \
+ {RING_ACTHD_UDW(0),0, 0, "ACTHD_UDW"}, \
+ {RING_INSTPM(0), 0, 0, "INSTPM"}, \
+ {RING_INSTDONE(0), 0, 0, "INSTDONE"}, \
+ {RING_NOPID(0),0, 0, "RING_NOPID"}, \
+ {RING_START(0),0, 0, "START"}, \
+ {RING_HEAD(0), 0, 0, "HEAD"}, \
+ {RING_TAIL(0), 0, 0, "TAIL"}, \
+ {RING_CTL(0), 0, 0, "CTL"}, \
+ {RING_MI_MODE(0), 0, 0, "MODE"}, \
+ {RING_CONTEXT_CONTROL(0), 0, 0, "RING_CONTEXT_CONTROL"}, \
+ {RING_HWS_PGA(0), 0, 0, "HWS"}, \
+ {RING_MODE_GEN7(0),0, 0, "GFX_MODE"}, \
+ {GEN8_RING_PDP_LDW(0, 0), 0, 0, "PDP0_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 0), 0, 0, "PDP0_UDW"}, \
+ {GEN8_RING_PDP_LDW(0, 1), 0, 0, "PDP1_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 1), 0, 0, "PDP1_UDW"}, \
+ {GEN8_RING_PDP_LDW(0, 2), 0, 0, "PDP2_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 2), 0, 0, "PDP2_UDW"}, \
+ {GEN8_RING_PDP_LDW(0, 3), 0, 0, "PDP3_LDW"}, \
+ {GEN8_RING_PDP_UDW(0, 3), 0, 0, "PDP3_UDW"}
+
+#define COMMON_GEN12BASE_HAS_EU() \
+ {EIR, 0, 0, "EIR"}
+
+#define COMMON_GEN12BASE_RENDER() \
+ {GEN7_SC_INSTDONE, 0, 0, "GEN7_SC_INSTDONE"}, \
+ {GEN12_SC_INSTDONE_EXTRA, 0, 0, "GEN12_SC_INSTDONE_EXTRA"}, \
+ {GEN12_SC_INSTDONE_EXTRA2, 0, 0, "GEN12_SC_INSTDONE_EXTRA2"}
+
+#define COMMON_GEN12BASE_VEC() \
+ {GEN12_SFC_DONE(0),0, 0, "SFC_DONE[0]"}, \
+ {GEN12_SFC_DONE(1),0, 0, "SFC_DONE[1]"}, \
+ {GEN12_SFC_DONE(2),0, 0, "SFC_DONE[2]"}, \
+ {GEN12_SFC_DONE(3),0, 0, "SFC_DONE[3]"}
+
/* XE_LPD - Global */
static const struct __guc_mmio_reg_descr xe_lpd_global_regs[] = {
- {GEN12_RING_FAULT_REG, 0, 0, "GEN12_RING_FAULT_REG"}
+ COMMON_GEN12BASE_GLOBAL(),
};
/* XE_LPD - Render / Compute Per-Class */
static const struct __guc_mmio_reg_descr xe_lpd_rc_class_regs[] = {
- {EIR, 0, 0, "EIR"}
+ COMMON_GEN12BASE_HAS_EU(),
+ COMMON_GEN12BASE_RENDER(),
};
/* XE_LPD - Render / Compute Per-Engine-Instance */
static const struct __guc_mmio_reg_descr xe_lpd_rc_inst_regs[] = {
- {RING_HEAD(0), 0, 0, "RING_HEAD"},
- {RING_TAIL(0), 0, 0, "RING_TAIL"},
+ COMMON_GEN12BASE_ENGINE_INSTANCE(),
};
/* XE_LPD - Media Decode/Encode Per-Class */
static const struct __guc_mmio_reg_descr xe_lpd_vd_class_regs[] = {
+ COMMON_GEN12BASE_ENGINE_INSTANCE(),
};
/* XE_LPD - Media Decod
Re: [Intel-gfx] [PATCH v10 2/5] mei: add support for graphics system controller (gsc) devices
On 3/8/2022 8:36 AM, Alexander Usyskin wrote:
From: Tomas Winkler
GSC is a graphics system controller, based on CSE, it provides
a chassis controller for graphics discrete cards, as well as it
supports media protection on selected devices.
mei_gsc binds to a auxiliary devices exposed by Intel discrete
driver i915.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/Kconfig | 14 +++
drivers/misc/mei/Makefile | 3 +
drivers/misc/mei/gsc-me.c | 186 ++
drivers/misc/mei/hw-me.c | 27 +-
drivers/misc/mei/hw-me.h | 2 +
5 files changed, 230 insertions(+), 2 deletions(-)
create mode 100644 drivers/misc/mei/gsc-me.c
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 0e0bcd0da852..d21486d69df2 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -46,6 +46,20 @@ config INTEL_MEI_TXE
Supported SoCs:
Intel Bay Trail
+config INTEL_MEI_GSC
On platforms with a GSC, INTEL_MEI_PXP depends on INTEL_MEI_GSC. Are you
planning to add that dependency once the HECI1/PXP interface is exposed,
or are you expecting i915 to check for both?
+ tristate "Intel MEI GSC embedded device"
+ depends on INTEL_MEI
+ depends on INTEL_MEI_ME
+ depends on X86 && PCI
+ depends on DRM_I915
+ help
+ Intel auxiliary driver for GSC devices embedded in Intel graphics
devices.
+
+ An MEI device here called GSC can be embedded in an
+ Intel graphics devices, to support a range of chassis
+ tasks such as graphics card firmware update and security
+ tasks.
+
source "drivers/misc/mei/hdcp/Kconfig"
source "drivers/misc/mei/pxp/Kconfig"
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index d8e5165917f2..fb740d754900 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -18,6 +18,9 @@ obj-$(CONFIG_INTEL_MEI_ME) += mei-me.o
mei-me-objs := pci-me.o
mei-me-objs += hw-me.o
+obj-$(CONFIG_INTEL_MEI_GSC) += mei-gsc.o
+mei-gsc-objs := gsc-me.o
+
obj-$(CONFIG_INTEL_MEI_TXE) += mei-txe.o
mei-txe-objs := pci-txe.o
mei-txe-objs += hw-txe.o
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
new file mode 100644
index ..0afae70e0609
--- /dev/null
+++ b/drivers/misc/mei/gsc-me.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2019-2022, Intel Corporation. All rights reserved.
+ *
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mei_dev.h"
+#include "hw-me.h"
+#include "hw-me-regs.h"
+
+#include "mei-trace.h"
+
+#define MEI_GSC_RPM_TIMEOUT 500
MEI_ME_RPM_TIMEOUT already exists in hw-me.h with the same value. If
you're not expecting them to diverge, we could just re-use the existing
one. Not a blocker.
+
+static int mei_gsc_read_hfs(const struct mei_device *dev, int where, u32 *val)
+{
+ struct mei_me_hw *hw = to_me_hw(dev);
+
+ *val = ioread32(hw->mem_addr + where + 0xC00);
+
+ return 0;
+}
+
+static int mei_gsc_probe(struct auxiliary_device *aux_dev,
+const struct auxiliary_device_id *aux_dev_id)
+{
+ struct mei_aux_device *adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+ struct mei_device *dev;
might be worth renaming this variable to mei_dev, to avoid confusion
with "device" below. Not a blocker.
+ struct mei_me_hw *hw;
+ struct device *device;
+ const struct mei_cfg *cfg;
+ int ret;
+
+ cfg = mei_me_get_cfg(aux_dev_id->driver_data);
+ if (!cfg)
+ return -ENODEV;
+
+ device = &aux_dev->dev;
+
+ dev = mei_me_dev_init(device, cfg);
+ if (IS_ERR(dev)) {
+ ret = PTR_ERR(dev);
+ goto err;
+ }
+
+ hw = to_me_hw(dev);
+ hw->mem_addr = devm_ioremap_resource(device, &adev->bar);
+ if (IS_ERR(hw->mem_addr)) {
+ dev_err(device, "mmio not mapped\n");
+ ret = PTR_ERR(hw->mem_addr);
+ goto err;
+ }
+
+ hw->irq = adev->irq;
+ hw->read_fws = mei_gsc_read_hfs;
+
+ dev_set_drvdata(&aux_dev->dev, dev);
you have a device = &aux_dev->dev earlier, so you can just use device here.
+
+ ret = devm_request_threaded_irq(device, hw->irq,
+ mei_me_irq_quick_handler,
+ mei_me_irq_thread_handler,
+ IRQF_ONESHOT, KBUILD_MODNAME, dev);
If I'm understanding this correctly, you're tying the irq to the device
allocated by i915, so if the probe fails below or the mei_gsc module is
unloaded the irq is going to stick around. Probably better to clean it
up explicitly, in case we get a spurious interrupt from the HW and i915
propagates it (although that's a ver
Re: [Intel-gfx] [PATCH v7] drm/i915/display/vrr: Reset VRR capable property on a long hpd
On Thu, Mar 10, 2022 at 01:43:57AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 03, 2022 at 03:32:22PM -0800, Manasi Navare wrote:
> > With some VRR panels, user can turn VRR ON/OFF on the fly from the panel
> > settings.
> > When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore
> > MSA bit
> > in the DPCD. Currently the driver parses that onevery HPD but fails to reset
> > the corresponding VRR Capable Connector property.
> > Hence the userspace still sees this as VRR Capable panel which is incorrect.
> >
> > Fix this by explicitly resetting the connector property.
> >
> > v2: Reset vrr capable if status == connector_disconnected
> > v3: Use i915 and use bool vrr_capable (Jani Nikula)
> > v4: Move vrr_capable to after update modes call (Jani N)
> > Remove the redundant comment (Jan N)
> > v5: Fixes the regression on older platforms by reseting the VRR
> > only if HAS_VRR
> > v6: Remove the checks from driver, add in drm core before
> > setting VRR prop (Ville)
> > v7: Move VRR set/reset to set/unset_edid (Ville)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 390a1f8beb87 ("Revert "drm/i915/display/vrr: Reset VRR capable
> > property on a long hpd")
> > Signed-off-by: Manasi Navare
>
> Looks reasoanble enough to me.
> Reviewed-by: Ville Syrjälä
>
> But be careful when pushing this since I don't think
> the drm_connector_set_vrr_capable_property() change has
> percolated into drm-intel-next yet.
Okay I can wait then to push until that gets percolated from drm-misc
Manasi
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6ef33096bb6..1d0f8fc39005 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4385,13 +4385,20 @@ intel_dp_update_420(struct intel_dp *intel_dp)
> > static void
> > intel_dp_set_edid(struct intel_dp *intel_dp)
> > {
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > struct intel_connector *connector = intel_dp->attached_connector;
> > struct edid *edid;
> > + bool vrr_capable;
> >
> > intel_dp_unset_edid(intel_dp);
> > edid = intel_dp_get_edid(intel_dp);
> > connector->detect_edid = edid;
> >
> > + vrr_capable = intel_vrr_is_capable(&connector->base);
> > + drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
> > + connector->base.base.id, connector->base.name,
> > str_yes_no(vrr_capable));
> > + drm_connector_set_vrr_capable_property(&connector->base, vrr_capable);
> > +
> > intel_dp_update_dfp(intel_dp, edid);
> > intel_dp_update_420(intel_dp);
> >
> > @@ -4424,6 +4431,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> >
> > intel_dp->dfp.ycbcr_444_to_420 = false;
> > connector->base.ycbcr_420_allowed = false;
> > +
> > + drm_connector_set_vrr_capable_property(&connector->base,
> > + false);
> > }
> >
> > static int
> > @@ -4574,14 +4584,9 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > int num_modes = 0;
> >
> > edid = intel_connector->detect_edid;
> > - if (edid) {
> > + if (edid)
> > num_modes = intel_connector_update_modes(connector, edid);
> >
> > - if (intel_vrr_is_capable(connector))
> > - drm_connector_set_vrr_capable_property(connector,
> > - true);
> > - }
> > -
> > /* Also add fixed mode, which may or may not be present in EDID */
> > if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
> > intel_connector->panel.fixed_mode) {
> > --
> > 2.19.1
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Make the PIPESC rect relative to the entire bigjoiner area
On Fri, Mar 04, 2022 at 05:10:33PM +0200, Ville Syrjälä wrote:
> 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
Re: [Intel-gfx] [PATCH v10 3/5] mei: gsc: setup char driver alive in spite of firmware handshake failure
On 3/8/2022 8:36 AM, Alexander Usyskin wrote:
Setup char device in spite of firmware handshake failure.
In order to provide host access to the firmware status registers and other
information required for the manufacturing process.
IMO this patch should be moved to after the patch that adds the logic to
fetch the FW version, as that is interesting info for sysfs. Not a blocker.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/misc/mei/gsc-me.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index 0afae70e0609..cf427f6fdec9 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -79,11 +79,12 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
pm_runtime_set_active(device);
pm_runtime_enable(device);
- if (mei_start(dev)) {
- dev_err(device, "init hw failure.\n");
- ret = -ENODEV;
- goto err;
- }
+ /* Continue to char device setup in spite of firmware handshake failure.
+* In order to provide access to the firmware status registers to the
user
+* space via sysfs.
+*/
+ if (mei_start(dev))
+ dev_warn(device, "init hw failure.\n");
pm_runtime_set_autosuspend_delay(device, MEI_GSC_RPM_TIMEOUT);
pm_runtime_use_autosuspend(device);
[Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.
Cc: Ashutosh Dixit
Cc: Matt Roper
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/i915_query.c | 68 ++-
include/uapi/drm/i915_drm.h | 24 +++
2 files changed, 65 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..0cc2670ae09c 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "i915_perf.h"
#include "i915_query.h"
+#include "gt/intel_engine_user.h"
#include
static int copy_query_item(void *query_hdr, size_t query_sz,
@@ -28,36 +29,30 @@ static int copy_query_item(void *query_hdr, size_t query_sz,
return 0;
}
-static int query_topology_info(struct drm_i915_private *dev_priv,
- struct drm_i915_query_item *query_item)
+static int fill_topology_info(const struct sseu_dev_info *sseu,
+ struct drm_i915_query_item *query_item,
+ const u8 *subslice_mask)
{
- const struct sseu_dev_info *sseu = &to_gt(dev_priv)->info.sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
int ret;
- if (query_item->flags != 0)
- return -EINVAL;
+ BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
if (sseu->max_slices == 0)
return -ENODEV;
- BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
-
slice_length = sizeof(sseu->slice_mask);
subslice_length = sseu->max_slices * sseu->ss_stride;
eu_length = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
- ret = copy_query_item(&topo, sizeof(topo), total_length,
- query_item);
+ ret = copy_query_item(&topo, sizeof(topo), total_length, query_item);
+
if (ret != 0)
return ret;
- if (topo.flags != 0)
- return -EINVAL;
-
memset(&topo, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
@@ -69,27 +64,61 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.eu_stride = sseu->eu_stride;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
- &topo, sizeof(topo)))
+&topo, sizeof(topo)))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + sizeof(topo)),
- &sseu->slice_mask, slice_length))
+&sseu->slice_mask, slice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) + slice_length),
- sseu->subslice_mask, subslice_length))
+sizeof(topo) + slice_length),
+subslice_mask, subslice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) +
- slice_length + subslice_length),
- sseu->eu_mask, eu_length))
+sizeof(topo) +
+slice_length + subslice_length),
+sseu->eu_mask, eu_length))
return -EFAULT;
return total_length;
}
+static int query_topology_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu = &to_gt(dev_priv )->info.sseu;
+
+ if (query_item->flags != 0)
+ return -EINVAL;
+
+ return fill_topology_info(sseu, query_item, sseu->subslice_mask);
+}
+
+static int query_geometry_subslices(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu;
+ struct intel_engine_cs *engine;
+ u8 engine_class, engine_instance;
+
+ if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
+ return -ENODEV;
+
+ engine_class = query_item->flags & 0xFF;
+ engine_instance = (query_item->flags >>8) & 0xFF;
+
+ engine = intel_engine_lookup_user(i915, engine_class, engine_instance);
+
+ if(!engine)
+
[Intel-gfx] [PATCH 01/13] drm/i915: Fix up some DRRS type checks
From: Ville Syrjälä
Only seamless DRRS needs the frontbuffer tracking, so check for that.
Also use != consistently instead of randomly picing < as the comparison
operator.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index fa715b8ea310..146f2cf7d01a 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -152,7 +152,7 @@ static void intel_drrs_set_state(struct drm_i915_private
*dev_priv,
return;
}
- if (dev_priv->drrs.type < SEAMLESS_DRRS_SUPPORT) {
+ if (dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT) {
drm_dbg_kms(&dev_priv->drm, "Only Seamless DRRS supported.\n");
return;
}
@@ -326,7 +326,7 @@ static void intel_drrs_frontbuffer_update(struct
drm_i915_private *dev_priv,
struct drm_crtc *crtc;
enum pipe pipe;
- if (dev_priv->drrs.type == DRRS_NOT_SUPPORTED)
+ if (dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
return;
cancel_delayed_work(&dev_priv->drrs.work);
--
2.34.1
[Intel-gfx] [PATCH 00/13] drm/i915: DRRS fixes/cleanups and start of static DRRS
From: Ville Syrjälä
Fix/clean up the DRRS code sufficiently that I feel
comfortable enabling it on all ilk+ CPU eDP ports.
PCH ports still need a bit of work.
The other thing I slapped on top is the beginnings of
static DRRS support (ie. actually changing the refresh
rate based on what the user asked). This initial version
is still limited to just two refresh rates though. We'll
have to expand on that further to also allow switching
the other supported refresh rates.
For the moment the user initiated refresh rate change
will cause a full modeset. But I think we should be able
to skip that if the hardware supports seamless DRRS, at least
on BDW+ with its double buffered M/N registers. Some extra
work will likely be needed for the modeset sequence to make
sure the DRRS frontbuffer stuff won't interfere with the
fastset reprogramming, and to make sure the reprogrmming
happens atomically with all the plane updates. The biggest
sticking point will probably be the fastset state check/copy
stuff. As is that is pretty much a big hack when it comes to
anything dotclock related and so probably needs some real
surgery.
Ville Syrjälä (13):
drm/i915: Fix up some DRRS type checks
drm/i915: Constify intel_drrs_init() args
drm/i915: Pimp DRRS debugs
drm/i915: Read DRRS MSA timing delay from VBT
drm/i915: Program MSA timing delay on ilk/snb/ivb
drm/i915: Polish drrs type enum
drm/i915: Clean up DRRS refresh rate enum
drm/i915: Rename PIPECONF refresh select bits
drm/i915: Stash DRRS state under intel_crtc
drm/i915: Move DRRS enable/disable higher up
drm/i915: Enable eDP DRRS on ilk/snb port A
drm/i915: Introduce intel_panel_{fixed,downclock}_mode()
drm/i915: Implement static DRRS
drivers/gpu/drm/i915/display/intel_bios.c | 13 +-
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +-
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
.../drm/i915/display/intel_display_debugfs.c | 125 ++
.../drm/i915/display/intel_display_types.h| 15 +
drivers/gpu/drm/i915/display/intel_dp.c | 22 +-
drivers/gpu/drm/i915/display/intel_drrs.c | 358 --
drivers/gpu/drm/i915/display/intel_drrs.h | 22 +-
drivers/gpu/drm/i915/display/intel_panel.c| 36 +-
drivers/gpu/drm/i915/display/intel_panel.h| 8 +-
drivers/gpu/drm/i915/i915_drv.h | 36 +-
drivers/gpu/drm/i915/i915_reg.h | 6 +-
13 files changed, 301 insertions(+), 363 deletions(-)
--
2.34.1
[Intel-gfx] [PATCH 02/13] drm/i915: Constify intel_drrs_init() args
From: Ville Syrjälä
Pass the fixed_mode as const to intel_drrs_init() since it's
not supposed to mutate the mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 2 +-
drivers/gpu/drm/i915/display/intel_drrs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 146f2cf7d01a..3b871a51eb55 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -421,7 +421,7 @@ void intel_drrs_page_flip(struct intel_atomic_state *state,
*/
struct drm_display_mode *
intel_drrs_init(struct intel_connector *connector,
- struct drm_display_mode *fixed_mode)
+ const struct drm_display_mode *fixed_mode)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_encoder *encoder = connector->encoder;
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.h
b/drivers/gpu/drm/i915/display/intel_drrs.h
index 9ec9c447211a..6bca7692f59f 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.h
+++ b/drivers/gpu/drm/i915/display/intel_drrs.h
@@ -31,6 +31,6 @@ void intel_drrs_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
int output_bpp, bool constant_n);
struct drm_display_mode *intel_drrs_init(struct intel_connector *connector,
-struct drm_display_mode *fixed_mode);
+const struct drm_display_mode
*fixed_mode);
#endif /* __INTEL_DRRS_H__ */
--
2.34.1
[Intel-gfx] [PATCH 03/13] drm/i915: Pimp DRRS debugs
From: Ville Syrjälä
Use the standard [CONNECTOR:%d:%s] format in the DRRS debugs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 3b871a51eb55..17bedecbd7b2 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -432,26 +432,32 @@ intel_drrs_init(struct intel_connector *connector,
if (DISPLAY_VER(dev_priv) <= 6) {
drm_dbg_kms(&dev_priv->drm,
- "DRRS supported for Gen7 and above\n");
+ "[CONNECTOR:%d:%s] DRRS not supported on
platform\n",
+ connector->base.base.id, connector->base.name);
return NULL;
}
if ((DISPLAY_VER(dev_priv) < 8 && !HAS_GMCH(dev_priv)) &&
encoder->port != PORT_A) {
drm_dbg_kms(&dev_priv->drm,
- "DRRS only supported on eDP port A\n");
+ "[CONNECTOR:%d:%s] DRRS not supported on
[ENCODER:%d:%s]\n",
+ connector->base.base.id, connector->base.name,
+ encoder->base.base.id, encoder->base.name);
return NULL;
}
if (dev_priv->vbt.drrs_type != SEAMLESS_DRRS_SUPPORT) {
- drm_dbg_kms(&dev_priv->drm, "VBT doesn't support DRRS\n");
+ drm_dbg_kms(&dev_priv->drm,
+ "[CONNECTOR:%d:%s] DRRS not supported according to
VBT\n",
+ connector->base.base.id, connector->base.name);
return NULL;
}
downclock_mode = intel_panel_edid_downclock_mode(connector, fixed_mode);
if (!downclock_mode) {
drm_dbg_kms(&dev_priv->drm,
- "Downclock mode is not found. DRRS not
supported\n");
+ "[CONNECTOR:%d:%s] DRRS not supported due to lack
of downclock mode\n",
+ connector->base.base.id, connector->base.name);
return NULL;
}
@@ -459,6 +465,8 @@ intel_drrs_init(struct intel_connector *connector,
dev_priv->drrs.refresh_rate_type = DRRS_HIGH_RR;
drm_dbg_kms(&dev_priv->drm,
- "seamless DRRS supported for eDP panel.\n");
+ "[CONNECTOR:%d:%s] seamless DRRS supported\n",
+ connector->base.base.id, connector->base.name);
+
return downclock_mode;
}
--
2.34.1
[Intel-gfx] [PATCH 04/13] drm/i915: Read DRRS MSA timing delay from VBT
From: Ville Syrjälä
VBT hsa a field for the MSA timing delay, which supposedly
should be used with DRRS. Extract the data from the VBT.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index a559a1914588..93dc32fb3e40 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -888,6 +888,9 @@ parse_edp(struct drm_i915_private *i915, const struct
bdb_header *bdb)
i915->vbt.edp.low_vswing = vswing == 0;
}
}
+
+ i915->vbt.edp.drrs_msa_timing_delay =
+ (edp->sdrrs_msa_timing_delay >> (panel_type * 2)) & 3;
}
static void
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 943267393ecb..020c5f7602a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -356,10 +356,11 @@ struct intel_vbt_data {
int lanes;
int preemphasis;
int vswing;
- bool low_vswing;
- bool initialized;
int bpp;
struct edp_power_seq pps;
+ u8 drrs_msa_timing_delay;
+ bool low_vswing;
+ bool initialized;
bool hobl;
} edp;
--
2.34.1
[Intel-gfx] [PATCH 05/13] drm/i915: Program MSA timing delay on ilk/snb/ivb
From: Ville Syrjälä
Grab the DRRS MSA timing delay value from the VBT
and program things accordingly. Only ilk/snb/ivb have
this so presumably on hsw+ we don't need it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8 ++--
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_drrs.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h| 2 ++
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 54db81c2cce6..b7c418677372 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3577,6 +3577,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(crtc_state->framestart_delay - 1);
+ val |= PIPECONF_MSA_TIMING_DELAY(crtc_state->msa_timing_delay);
intel_de_write(dev_priv, PIPECONF(pipe), val);
intel_de_posting_read(dev_priv, PIPECONF(pipe));
@@ -3865,6 +3866,8 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc,
pipe_config->framestart_delay =
REG_FIELD_GET(PIPECONF_FRAME_START_DELAY_MASK, tmp) + 1;
+ pipe_config->msa_timing_delay =
REG_FIELD_GET(PIPECONF_MSA_TIMING_DELAY_MASK, tmp);
+
pipe_config->csc_mode = intel_de_read(dev_priv,
PIPE_CSC_MODE(crtc->pipe));
@@ -5345,8 +5348,8 @@ 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, "framestart delay: %d, MSA timing delay:
%d\n",
+ pipe_config->framestart_delay,
pipe_config->msa_timing_delay);
drm_dbg_kms(&dev_priv->drm,
"audio: %i, infoframes: %i, infoframes enabled: 0x%x\n",
@@ -6243,6 +6246,7 @@ 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(msa_timing_delay);
PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_hdisplay);
PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_htotal);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e8d7394a394..86b2fa675124 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1155,6 +1155,7 @@ struct intel_crtc_state {
u8 update_planes;
u8 framestart_delay; /* 1-4 */
+ u8 msa_timing_delay; /* 0-3 */
struct {
u32 enable;
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 17bedecbd7b2..5b3711fe0674 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -83,6 +83,9 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
return;
}
+ if (IS_IRONLAKE(i915) || IS_SANDYBRIDGE(i915) || IS_IVYBRIDGE(i915))
+ pipe_config->msa_timing_delay =
i915->vbt.edp.drrs_msa_timing_delay;
+
pipe_config->has_drrs = true;
pixel_clock = connector->panel.downclock_mode->clock;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 70484f6f2b8b..c106fb23e245 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3706,6 +3706,8 @@
#define PIPECONF_INTERLACE_IF_ID_DBL_ILK
REG_FIELD_PREP(PIPECONF_INTERLACE_MASK_ILK, 4) /* ilk/snb only */
#define PIPECONF_INTERLACE_PF_ID_DBL_ILK
REG_FIELD_PREP(PIPECONF_INTERLACE_MASK_ILK, 5) /* ilk/snb only */
#define PIPECONF_EDP_RR_MODE_SWITCH REG_BIT(20)
+#define PIPECONF_MSA_TIMING_DELAY_MASK REG_GENMASK(19, 18) /*
ilk/snb/ivb */
+#define PIPECONF_MSA_TIMING_DELAY(x)
REG_FIELD_PREP(PIPECONF_MSA_TIMING_DELAY_MASK, (x))
#define PIPECONF_CXSR_DOWNCLOCK REG_BIT(16)
#define PIPECONF_EDP_RR_MODE_SWITCH_VLV REG_BIT(14)
#define PIPECONF_COLOR_RANGE_SELECT REG_BIT(13)
--
2.34.1
[Intel-gfx] [PATCH 06/13] drm/i915: Polish drrs type enum
From: Ville Syrjälä
Make the drrs type enum less convoluted.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c| 10 +-
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
drivers/gpu/drm/i915/display/intel_drrs.c| 10 +-
drivers/gpu/drm/i915/i915_drv.h | 12 ++--
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 93dc32fb3e40..c7afe19dd44a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -257,16 +257,16 @@ parse_panel_options(struct drm_i915_private *i915,
*/
switch (drrs_mode) {
case 0:
- i915->vbt.drrs_type = STATIC_DRRS_SUPPORT;
+ i915->vbt.drrs_type = DRRS_TYPE_STATIC;
drm_dbg_kms(&i915->drm, "DRRS supported mode is static\n");
break;
case 2:
- i915->vbt.drrs_type = SEAMLESS_DRRS_SUPPORT;
+ i915->vbt.drrs_type = DRRS_TYPE_SEAMLESS;
drm_dbg_kms(&i915->drm,
"DRRS supported mode is seamless\n");
break;
default:
- i915->vbt.drrs_type = DRRS_NOT_SUPPORTED;
+ i915->vbt.drrs_type = DRRS_TYPE_NONE;
drm_dbg_kms(&i915->drm,
"DRRS not supported (VBT input)\n");
break;
@@ -740,7 +740,7 @@ parse_driver_features(struct drm_i915_private *i915,
* driver->drrs_enabled=false
*/
if (!driver->drrs_enabled)
- i915->vbt.drrs_type = DRRS_NOT_SUPPORTED;
+ i915->vbt.drrs_type = DRRS_TYPE_NONE;
i915->vbt.psr.enable = driver->psr_enabled;
}
@@ -769,7 +769,7 @@ parse_power_conservation_features(struct drm_i915_private
*i915,
* power->drrs & BIT(panel_type)=false
*/
if (!(power->drrs & BIT(panel_type)))
- i915->vbt.drrs_type = DRRS_NOT_SUPPORTED;
+ i915->vbt.drrs_type = DRRS_TYPE_NONE;
if (bdb->version >= 232)
i915->vbt.edp.hobl = power->hobl & BIT(panel_type);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 41b81d5dd5f4..28414472110e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1163,7 +1163,7 @@ static void drrs_status_per_crtc(struct seq_file *m,
seq_printf(m, "%s:\n", connector->name);
if (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
- drrs->type == SEAMLESS_DRRS_SUPPORT)
+ drrs->type == DRRS_TYPE_SEAMLESS)
supported = true;
seq_printf(m, "\tDRRS Supported: %s\n", str_yes_no(supported));
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 5b3711fe0674..7c4a3ecee93a 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -65,7 +65,7 @@ static bool can_enable_drrs(struct intel_connector *connector,
return false;
return connector->panel.downclock_mode &&
- i915->drrs.type == SEAMLESS_DRRS_SUPPORT;
+ i915->drrs.type == DRRS_TYPE_SEAMLESS;
}
void
@@ -155,7 +155,7 @@ static void intel_drrs_set_state(struct drm_i915_private
*dev_priv,
return;
}
- if (dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT) {
+ if (dev_priv->drrs.type != DRRS_TYPE_SEAMLESS) {
drm_dbg_kms(&dev_priv->drm, "Only Seamless DRRS supported.\n");
return;
}
@@ -274,7 +274,7 @@ intel_drrs_update(struct intel_dp *intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- if (dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
+ if (dev_priv->drrs.type != DRRS_TYPE_SEAMLESS)
return;
mutex_lock(&dev_priv->drrs.mutex);
@@ -329,7 +329,7 @@ static void intel_drrs_frontbuffer_update(struct
drm_i915_private *dev_priv,
struct drm_crtc *crtc;
enum pipe pipe;
- if (dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
+ if (dev_priv->drrs.type != DRRS_TYPE_SEAMLESS)
return;
cancel_delayed_work(&dev_priv->drrs.work);
@@ -449,7 +449,7 @@ intel_drrs_init(struct intel_connector *connector,
return NULL;
}
- if (dev_priv->vbt.drrs_type != SEAMLESS_DRRS_SUPPORT) {
+ if (dev_priv->vbt.drrs_type != DRRS_TYPE_SEAMLESS) {
drm_dbg_kms(&dev_priv->drm,
"[CONNECTOR:%d:%s] DRRS not supported according to
VBT\n",
connector->base.base.i
[Intel-gfx] [PATCH 07/13] drm/i915: Clean up DRRS refresh rate enum
From: Ville Syrjälä
Make the DRRS refresh rate enum less magical.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 18 ++--
drivers/gpu/drm/i915/display/intel_drrs.c | 44 +--
drivers/gpu/drm/i915/i915_drv.h | 14 ++
3 files changed, 28 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 28414472110e..798bf233a60f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1149,7 +1149,6 @@ static void drrs_status_per_crtc(struct seq_file *m,
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_drrs *drrs = &dev_priv->drrs;
- int vrefresh = 0;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
@@ -1191,21 +1190,12 @@ static void drrs_status_per_crtc(struct seq_file *m,
drrs->busy_frontbuffer_bits);
seq_puts(m, "\n\t\t");
- if (drrs->refresh_rate_type == DRRS_HIGH_RR) {
- seq_puts(m, "DRRS_State: DRRS_HIGH_RR\n");
- vrefresh = drm_mode_vrefresh(panel->fixed_mode);
- } else if (drrs->refresh_rate_type == DRRS_LOW_RR) {
- seq_puts(m, "DRRS_State: DRRS_LOW_RR\n");
- vrefresh = drm_mode_vrefresh(panel->downclock_mode);
- } else {
- seq_printf(m, "DRRS_State: Unknown(%d)\n",
- drrs->refresh_rate_type);
- mutex_unlock(&drrs->mutex);
- return;
- }
- seq_printf(m, "\t\tVrefresh: %d", vrefresh);
+ seq_printf(m, "DRRS refresh rate: %s\n",
+ drrs->refresh_rate == DRRS_REFRESH_RATE_LOW ?
+ "low" : "high");
seq_puts(m, "\n\t\t");
+
mutex_unlock(&drrs->mutex);
} else {
/* DRRS not supported. Print the VBT parameter*/
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 7c4a3ecee93a..3979ceaaf651 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -103,7 +103,7 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
static void
intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state *crtc_state,
-enum drrs_refresh_rate_type refresh_type)
+enum drrs_refresh_rate refresh_rate)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -117,7 +117,7 @@ intel_drrs_set_refresh_rate_pipeconf(const struct
intel_crtc_state *crtc_state,
val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder));
- if (refresh_type == DRRS_LOW_RR)
+ if (refresh_rate == DRRS_REFRESH_RATE_LOW)
val |= bit;
else
val &= ~bit;
@@ -127,22 +127,21 @@ intel_drrs_set_refresh_rate_pipeconf(const struct
intel_crtc_state *crtc_state,
static void
intel_drrs_set_refresh_rate_m_n(const struct intel_crtc_state *crtc_state,
- enum drrs_refresh_rate_type refresh_type)
+ enum drrs_refresh_rate refresh_rate)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
intel_cpu_transcoder_set_m1_n1(crtc, crtc_state->cpu_transcoder,
- refresh_type == DRRS_LOW_RR ?
+ refresh_rate == DRRS_REFRESH_RATE_LOW ?
&crtc_state->dp_m2_n2 :
&crtc_state->dp_m_n);
}
static void intel_drrs_set_state(struct drm_i915_private *dev_priv,
const struct intel_crtc_state *crtc_state,
-enum drrs_refresh_rate_type refresh_type)
+enum drrs_refresh_rate refresh_rate)
{
struct intel_dp *intel_dp = dev_priv->drrs.dp;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- struct drm_display_mode *mode;
if (!intel_dp) {
drm_dbg_kms(&dev_priv->drm, "DRRS not supported.\n");
@@ -160,7 +159,7 @@ static void intel_drrs_set_state(struct drm_i915_private
*dev_priv,
return;
}
- if (refresh_type == dev_priv->drrs.refresh_rate_type)
+ if (refresh_rate == dev_priv->drrs.refresh_rate)
return;
if (!crtc_state->hw.active) {
@@ -170,18 +169,14 @@ static void intel_drrs_set_state(struct drm_i915_private
*dev_priv,
}
if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_pri
[Intel-gfx] [PATCH 08/13] drm/i915: Rename PIPECONF refresh select bits
From: Ville Syrjälä Rename the PIPECONF refresh rate select bits to be less cryptic. Also nothing eDP specific about these as they also select between FP0 vs. FP1 for the DPLL and thus can be used to change the refresh rate on other output types as well. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_drrs.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c b/drivers/gpu/drm/i915/display/intel_drrs.c index 3979ceaaf651..c97b5dee8cae 100644 --- a/drivers/gpu/drm/i915/display/intel_drrs.c +++ b/drivers/gpu/drm/i915/display/intel_drrs.c @@ -111,9 +111,9 @@ intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state *crtc_state, u32 val, bit; if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) - bit = PIPECONF_EDP_RR_MODE_SWITCH_VLV; + bit = PIPECONF_REFRESH_RATE_ALT_VLV; else - bit = PIPECONF_EDP_RR_MODE_SWITCH; + bit = PIPECONF_REFRESH_RATE_ALT_ILK; val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder)); diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index c106fb23e245..f66309a7566f 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3705,11 +3705,11 @@ #define PIPECONF_INTERLACE_IF_ID_ILK REG_FIELD_PREP(PIPECONF_INTERLACE_MASK_ILK, 3) #define PIPECONF_INTERLACE_IF_ID_DBL_ILK REG_FIELD_PREP(PIPECONF_INTERLACE_MASK_ILK, 4) /* ilk/snb only */ #define PIPECONF_INTERLACE_PF_ID_DBL_ILK REG_FIELD_PREP(PIPECONF_INTERLACE_MASK_ILK, 5) /* ilk/snb only */ -#define PIPECONF_EDP_RR_MODE_SWITCH REG_BIT(20) +#define PIPECONF_REFRESH_RATE_ALT_ILKREG_BIT(20) #define PIPECONF_MSA_TIMING_DELAY_MASK REG_GENMASK(19, 18) /* ilk/snb/ivb */ #define PIPECONF_MSA_TIMING_DELAY(x) REG_FIELD_PREP(PIPECONF_MSA_TIMING_DELAY_MASK, (x)) #define PIPECONF_CXSR_DOWNCLOCK REG_BIT(16) -#define PIPECONF_EDP_RR_MODE_SWITCH_VLV REG_BIT(14) +#define PIPECONF_REFRESH_RATE_ALT_VLVREG_BIT(14) #define PIPECONF_COLOR_RANGE_SELECT REG_BIT(13) #define PIPECONF_OUTPUT_COLORSPACE_MASK REG_GENMASK(12, 11) /* ilk-ivb */ #define PIPECONF_OUTPUT_COLORSPACE_RGB REG_FIELD_PREP(PIPECONF_OUTPUT_COLORSPACE_MASK, 0) /* ilk-ivb */ -- 2.34.1
[Intel-gfx] [PATCH 09/13] drm/i915: Stash DRRS state under intel_crtc
From: Ville Syrjälä
Get rid of the ugly intel_dp dependency, and one more crtc->config
usage by storing the DRRS state under intel_crtc. intel_drrs_enable()
copies what it needs from the crtc state, after which DRRS can be
blissfully ignorant of anything going on around it.
This also lets multiple pipes do DRRS simultanously and entirely
independently.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +
drivers/gpu/drm/i915/display/intel_ddi.c | 8 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
.../drm/i915/display/intel_display_debugfs.c | 97 ++
.../drm/i915/display/intel_display_types.h| 14 +
drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
drivers/gpu/drm/i915/display/intel_drrs.c | 300 +++---
drivers/gpu/drm/i915/display/intel_drrs.h | 20 +-
drivers/gpu/drm/i915/i915_drv.h | 15 -
9 files changed, 171 insertions(+), 291 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 65827481c1b1..f655c1622877 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -24,6 +24,7 @@
#include "intel_display_debugfs.h"
#include "intel_display_trace.h"
#include "intel_display_types.h"
+#include "intel_drrs.h"
#include "intel_dsi.h"
#include "intel_pipe_crc.h"
#include "intel_psr.h"
@@ -367,6 +368,7 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, enum
pipe pipe)
intel_color_init(crtc);
+ intel_crtc_drrs_init(crtc);
intel_crtc_crc_init(crtc);
cpu_latency_qos_add_request(&crtc->vblank_pm_qos, PM_QOS_DEFAULT_VALUE);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e6d86a54850..a3bf4e876fb4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2820,7 +2820,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
- intel_drrs_enable(intel_dp, crtc_state);
+ intel_drrs_enable(crtc_state);
if (crtc_state->has_audio)
intel_audio_codec_enable(encoder, crtc_state, conn_state);
@@ -2963,7 +2963,7 @@ static void intel_disable_ddi_dp(struct
intel_atomic_state *state,
intel_audio_codec_disable(encoder,
old_crtc_state, old_conn_state);
- intel_drrs_disable(intel_dp, old_crtc_state);
+ intel_drrs_disable(old_crtc_state);
intel_psr_disable(intel_dp, old_crtc_state);
intel_edp_backlight_off(old_conn_state);
/* Disable the decompression in DP Sink */
@@ -3013,12 +3013,12 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
{
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
intel_ddi_set_dp_msa(crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
- intel_drrs_update(intel_dp, crtc_state);
+ intel_drrs_update(state, crtc);
intel_backlight_update(state, encoder, crtc_state, conn_state);
drm_connector_update_privacy_screen(conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b7c418677372..4c7c74665819 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1229,7 +1229,7 @@ static void intel_post_plane_update(struct
intel_atomic_state *state,
hsw_ips_post_update(state, crtc);
intel_fbc_post_update(state, crtc);
- intel_drrs_page_flip(state, crtc);
+ intel_drrs_page_flip(crtc);
if (needs_async_flip_vtd_wa(old_crtc_state) &&
!needs_async_flip_vtd_wa(new_crtc_state))
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 798bf233a60f..bbf6ebd18414 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1143,87 +1143,44 @@ static int i915_ddb_info(struct seq_file *m, void
*unused)
return 0;
}
-static void drrs_status_per_crtc(struct seq_file *m,
-struct drm_device *dev,
-struct intel_crtc *crtc)
+static int i915_drrs_status(struct seq_file *m, void *unused)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_drrs *drrs = &dev_priv->drrs;
- struct drm_connector *connector;
+ str
[Intel-gfx] [PATCH 11/13] drm/i915: Enable eDP DRRS on ilk/snb port A
From: Ville Syrjälä
Nothing special about ivb+ here, if DRRS works on ivb+ port A
it should work just as well on ilk/snb. So let's enable
that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 246dd0c71194..dcbbd9c48458 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -145,10 +145,10 @@ static void intel_drrs_set_state(struct intel_crtc *crtc,
if (refresh_rate == crtc->drrs.refresh_rate)
return;
- if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv))
- intel_drrs_set_refresh_rate_m_n(crtc, refresh_rate);
- else if (DISPLAY_VER(dev_priv) > 6)
+ if (intel_cpu_transcoder_has_m2_n2(dev_priv, crtc->drrs.cpu_transcoder))
intel_drrs_set_refresh_rate_pipeconf(crtc, refresh_rate);
+ else
+ intel_drrs_set_refresh_rate_m_n(crtc, refresh_rate);
crtc->drrs.refresh_rate = refresh_rate;
}
@@ -364,7 +364,7 @@ intel_drrs_init(struct intel_connector *connector,
struct intel_encoder *encoder = connector->encoder;
struct drm_display_mode *downclock_mode;
- if (DISPLAY_VER(dev_priv) <= 6) {
+ if (DISPLAY_VER(dev_priv) < 5) {
drm_dbg_kms(&dev_priv->drm,
"[CONNECTOR:%d:%s] DRRS not supported on
platform\n",
connector->base.base.id, connector->base.name);
--
2.34.1
[Intel-gfx] [PATCH 10/13] drm/i915: Move DRRS enable/disable higher up
From: Ville Syrjälä No reason to keep the DRRS enable/disable hidden insider the encoder hooks. Let's just move them all the way up into platform independent code so that all platforms get to use them. These are nops when the state computation doesn't think DRRS is possible. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_ddi.c | 3 --- drivers/gpu/drm/i915/display/intel_display.c | 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index a3bf4e876fb4..e2b297d2c295 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -2820,8 +2820,6 @@ static void intel_enable_ddi_dp(struct intel_atomic_state *state, if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink) intel_dp_set_infoframes(encoder, true, crtc_state, conn_state); - intel_drrs_enable(crtc_state); - if (crtc_state->has_audio) intel_audio_codec_enable(encoder, crtc_state, conn_state); @@ -2963,7 +2961,6 @@ static void intel_disable_ddi_dp(struct intel_atomic_state *state, intel_audio_codec_disable(encoder, old_crtc_state, old_conn_state); - intel_drrs_disable(old_crtc_state); intel_psr_disable(intel_dp, old_crtc_state); intel_edp_backlight_off(old_conn_state); /* Disable the decompression in DP Sink */ diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 4c7c74665819..455f19e6d43d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8106,6 +8106,8 @@ static void intel_enable_crtc(struct intel_atomic_state *state, if (intel_crtc_is_bigjoiner_slave(new_crtc_state)) return; + intel_drrs_enable(new_crtc_state); + /* vblanks work again, re-enable pipe CRC. */ intel_crtc_enable_pipe_crc(crtc); } @@ -8175,6 +8177,8 @@ static void intel_old_crtc_state_disables(struct intel_atomic_state *state, */ intel_crtc_disable_pipe_crc(crtc); + intel_drrs_disable(old_crtc_state); + dev_priv->display->crtc_disable(state, crtc); crtc->active = false; intel_fbc_disable(crtc); -- 2.34.1
[Intel-gfx] [PATCH 13/13] drm/i915: Implement static DRRS
From: Ville Syrjälä
Let's start supporting static DRRS by trying to match the refresh
rate the user has requested, assuming the panel supports suitable
timings.
For now we stick to just our current two timings:
- fixed_mode: the panel's preferred mode
- downclock_mode: the lowest refresh rate mode we found
Some panels may support more timings than that, but we'll
have to convert our fixed_mode/downclock_mode pointers
into a full list before we can handle that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c| 11 +++
drivers/gpu/drm/i915/display/intel_drrs.c | 8 +---
drivers/gpu/drm/i915/display/intel_panel.c | 20 ++--
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index af659320c02e..9bd958377a54 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4599,6 +4599,17 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
num_modes++;
}
}
+ if (intel_dp_is_edp(intel_attached_dp(intel_connector)) &&
+ intel_connector->panel.downclock_mode) {
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(connector->dev,
+
intel_connector->panel.downclock_mode);
+ if (mode) {
+ drm_mode_probed_add(connector, mode);
+ num_modes++;
+ }
+ }
if (num_modes)
return num_modes;
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 5b2eb55c1340..dc1733c9abab 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -383,7 +383,7 @@ intel_drrs_init(struct intel_connector *connector,
return NULL;
}
- if (dev_priv->vbt.drrs_type != DRRS_TYPE_SEAMLESS) {
+ if (dev_priv->vbt.drrs_type == DRRS_TYPE_NONE) {
drm_dbg_kms(&dev_priv->drm,
"[CONNECTOR:%d:%s] DRRS not supported according to
VBT\n",
connector->base.base.id, connector->base.name);
@@ -399,8 +399,10 @@ intel_drrs_init(struct intel_connector *connector,
}
drm_dbg_kms(&dev_priv->drm,
- "[CONNECTOR:%d:%s] seamless DRRS supported\n",
- connector->base.base.id, connector->base.name);
+ "[CONNECTOR:%d:%s] %s DRRS supported\n",
+ connector->base.base.id, connector->base.name,
+ dev_priv->vbt.drrs_type == DRRS_TYPE_SEAMLESS ?
+ "seamless" : "static");
return downclock_mode;
}
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 127ad9643360..6ddbb69dcfdc 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -49,14 +49,30 @@ const struct drm_display_mode *
intel_panel_fixed_mode(struct intel_connector *connector,
const struct drm_display_mode *mode)
{
- return connector->panel.fixed_mode;
+ const struct drm_display_mode *fixed_mode = connector->panel.fixed_mode;
+ const struct drm_display_mode *downclock_mode =
connector->panel.downclock_mode;
+
+ /* pick the one that is closer in terms of vrefresh */
+ /* FIXME make this a a list of modes so we can have more than two */
+ if (fixed_mode && downclock_mode &&
+ abs(drm_mode_vrefresh(downclock_mode) - drm_mode_vrefresh(mode)) <
+ abs(drm_mode_vrefresh(fixed_mode) - drm_mode_vrefresh(mode)))
+ return downclock_mode;
+ else
+ return fixed_mode;
}
const struct drm_display_mode *
intel_panel_downclock_mode(struct intel_connector *connector,
const struct drm_display_mode *fixed_mode)
{
- return connector->panel.downclock_mode;
+ const struct drm_display_mode *downclock_mode =
connector->panel.downclock_mode;
+
+ if (downclock_mode &&
+ drm_mode_vrefresh(downclock_mode) < drm_mode_vrefresh(fixed_mode))
+ return downclock_mode;
+ else
+ return NULL;
}
int intel_panel_compute_config(struct intel_connector *connector,
--
2.34.1
[Intel-gfx] [PATCH 12/13] drm/i915: Introduce intel_panel_{fixed, downclock}_mode()
From: Ville Syrjälä
Absract away the details on where we store the fixed/downclock modes,
and also how we select them. Will be useful for static DRRS (aka.
allowing the user to select the refresh rate for the panel).
Only hooked these up into the DP code for now since that's
the only one that can do DRRS atm.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c| 7 +--
drivers/gpu/drm/i915/display/intel_drrs.c | 11 +++
drivers/gpu/drm/i915/display/intel_panel.c | 20 ++--
drivers/gpu/drm/i915/display/intel_panel.h | 8 ++--
4 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 725c3350c923..af659320c02e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -918,8 +918,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
{
struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
struct intel_connector *intel_connector = to_intel_connector(connector);
- struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ const struct drm_display_mode *fixed_mode;
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = dev_priv->max_dotclk_freq;
@@ -934,6 +934,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
+ fixed_mode = intel_panel_fixed_mode(intel_connector, mode);
if (intel_dp_is_edp(intel_dp) && fixed_mode) {
status = intel_panel_mode_valid(intel_connector, mode);
if (status != MODE_OK)
@@ -1797,6 +1798,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ const struct drm_display_mode *fixed_mode;
enum port port = encoder->port;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct intel_digital_connector_state *intel_conn_state =
@@ -1823,7 +1825,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
else
pipe_config->has_audio = intel_conn_state->force_audio ==
HDMI_AUDIO_ON;
- if (intel_dp_is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
+ fixed_mode = intel_panel_fixed_mode(intel_connector, adjusted_mode);
+ if (intel_dp_is_edp(intel_dp) && fixed_mode) {
ret = intel_panel_compute_config(intel_connector,
adjusted_mode);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index dcbbd9c48458..5b2eb55c1340 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -48,7 +48,8 @@
*/
static bool can_enable_drrs(struct intel_connector *connector,
- const struct intel_crtc_state *pipe_config)
+ const struct intel_crtc_state *pipe_config,
+ const struct drm_display_mode *downclock_mode)
{
const struct drm_i915_private *i915 = to_i915(connector->base.dev);
@@ -64,7 +65,7 @@ static bool can_enable_drrs(struct intel_connector *connector,
if (pipe_config->has_psr)
return false;
- return connector->panel.downclock_mode &&
+ return downclock_mode &&
i915->vbt.drrs_type == DRRS_TYPE_SEAMLESS;
}
@@ -74,9 +75,11 @@ intel_drrs_compute_config(struct intel_crtc_state
*pipe_config,
int output_bpp, bool constant_n)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ const struct drm_display_mode *downclock_mode =
+ intel_panel_downclock_mode(connector,
&pipe_config->hw.adjusted_mode);
int pixel_clock;
- if (!can_enable_drrs(connector, pipe_config)) {
+ if (!can_enable_drrs(connector, pipe_config, downclock_mode)) {
if (intel_cpu_transcoder_has_m2_n2(i915,
pipe_config->cpu_transcoder))
intel_zero_m_n(&pipe_config->dp_m2_n2);
return;
@@ -87,7 +90,7 @@ intel_drrs_compute_config(struct intel_crtc_state
*pipe_config,
pipe_config->has_drrs = true;
- pixel_clock = connector->panel.downclock_mode->clock;
+ pixel_clock = downclock_mode->clock;
if (pipe_config->splitter.enable)
pixel_clock /= pipe_config->splitter.link_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 6cd6d4f
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
== Series Details ==
Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
URL : https://patchwork.freedesktop.org/series/101219/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cd66c422f46c drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
-:106: ERROR:SPACING: space prohibited before that close parenthesis ')'
#106: FILE: drivers/gpu/drm/i915/i915_query.c:91:
+ const struct sseu_dev_info *sseu = &to_gt(dev_priv )->info.sseu;
-:125: CHECK:SPACING: spaces preferred around that '>>' (ctx:WxV)
#125: FILE: drivers/gpu/drm/i915/i915_query.c:110:
+ engine_instance = (query_item->flags >>8) & 0xFF;
^
-:129: ERROR:SPACING: space required before the open parenthesis '('
#129: FILE: drivers/gpu/drm/i915/i915_query.c:114:
+ if(!engine)
-:160: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#160: FILE: include/uapi/drm/i915_drm.h:2690:
+#define DRM_I915_QUERY_TOPOLOGY_INFO^I1$
-:162: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#162: FILE: include/uapi/drm/i915_drm.h:2692:
+#define DRM_I915_QUERY_PERF_CONFIG ^I3$
-:163: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#163: FILE: include/uapi/drm/i915_drm.h:2693:
+#define DRM_I915_QUERY_MEMORY_REGIONS ^I4$
total: 2 errors, 3 warnings, 1 checks, 172 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES URL : https://patchwork.freedesktop.org/series/101219/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v7 03/13] drm/i915/guc: Add XE_LP steered register lists support
On Sat, Feb 26, 2022 at 01:55:31AM -0800, Alan Previn wrote:
Add the ability for runtime allocation and freeing of
steered register list extentions that depend on the
detected HW config fuses.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 9 +
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 175 --
2 files changed, 173 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 858f85478636..27b89539d0d5 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -51,6 +51,7 @@ struct __guc_mmio_reg_descr_group {
u32 owner; /* see enum guc_capture_owner */
u32 type; /* see enum guc_capture_type */
u32 engine; /* as per MAX_ENGINE_CLASS */
+ struct __guc_mmio_reg_descr *extlist; /* only used for steered
registers */
};
/**
@@ -78,6 +79,14 @@ struct __guc_state_capture_priv {
*/
const struct __guc_mmio_reg_descr_group *reglists;
+ /**
+* @extlists: allocated table of steered register lists used for
error-capture state.
+*
+* NOTE: steered registers have multiple instances depending on the HW
configuration
+* (slices or dual-sub-slices) and thus depends on HW fuses discovered
at startup
+*/
+ struct __guc_mmio_reg_descr_group *extlists;
+
/**
* @ads_cache: cached register lists that is ADS format ready
*/
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index fb3ca734ef97..6370943ea300 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -133,6 +133,7 @@ static const struct __guc_mmio_reg_descr empty_regs_list[]
= {
TO_GCAP_DEF_OWNER(regsowner), \
TO_GCAP_DEF_TYPE(regstype), \
class, \
+ NULL, \
}
/* List of lists */
@@ -150,28 +151,33 @@ static const struct __guc_mmio_reg_descr_group
xe_lpd_lists[] = {
};
static const struct __guc_mmio_reg_descr_group *
-guc_capture_get_device_reglist(struct intel_guc *guc)
+guc_capture_get_one_list(const struct __guc_mmio_reg_descr_group *reglists,
+u32 owner, u32 type, u32 id)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ int i;
- if (IS_TIGERLAKE(i915) || IS_ROCKETLAKE(i915) ||
- IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i915)) {
- return xe_lpd_lists;
+ if (!reglists)
+ return NULL;
+
+ for (i = 0; reglists[i].list; ++i) {
+ if (reglists[i].owner == owner && reglists[i].type == type &&
+ (reglists[i].engine == id || reglists[i].type ==
GUC_CAPTURE_LIST_TYPE_GLOBAL))
+ return ®lists[i];
}
return NULL;
}
-static const struct __guc_mmio_reg_descr_group *
-guc_capture_get_one_list(const struct __guc_mmio_reg_descr_group *reglists,
-u32 owner, u32 type, u32 id)
+static struct __guc_mmio_reg_descr_group *
+guc_capture_get_one_ext_list(struct __guc_mmio_reg_descr_group *reglists,
+u32 owner, u32 type, u32 id)
{
int i;
if (!reglists)
return NULL;
- for (i = 0; reglists[i].list; ++i) {
+ for (i = 0; reglists[i].extlist; ++i) {
if (reglists[i].owner == owner && reglists[i].type == type &&
(reglists[i].engine == id || reglists[i].type ==
GUC_CAPTURE_LIST_TYPE_GLOBAL))
return ®lists[i];
@@ -180,6 +186,127 @@ guc_capture_get_one_list(const struct
__guc_mmio_reg_descr_group *reglists,
return NULL;
}
+static void guc_capture_free_extlists(struct __guc_mmio_reg_descr_group
*reglists)
+{
+ int i = 0;
+
+ if (!reglists)
+ return;
+
+ while (reglists[i].extlist)
+ kfree(reglists[i++].extlist);
+}
+
+struct __ext_steer_reg {
+ const char *name;
+ i915_reg_t reg;
+};
+
+static const struct __ext_steer_reg xe_extregs[] = {
+ {"GEN7_SAMPLER_INSTDONE", GEN7_SAMPLER_INSTDONE},
+ {"GEN7_ROW_INSTDONE", GEN7_ROW_INSTDONE}
+};
+
+static void __fill_ext_reg(struct __guc_mmio_reg_descr *ext,
+ const struct __ext_steer_reg *extlist,
+ int slice_id, int subslice_id)
+{
+ ext->reg = extlist->reg;
+ ext->flags = FIELD_PREP(GUC_REGSET_STEERING_GROUP, slice_id);
+ ext->flags |= FIELD_PREP(GUC_REGSET_STEERING_INSTANCE, subslice_id);
+ ext->regname = extlist->name;
+}
+
+static int
+__alloc_ext_regs(struct __guc_mmio_reg_descr_group *newlist,
+const struct __guc_mmio_reg_descr_group *rootlist, int
num_regs)
+{
+ struct __guc_mmio_reg_descr *list;
+
+ list = kcalloc(num_regs, sizeof(struct __guc_mmio_reg
[Intel-gfx] [CI] PR for new GuC v70.0.5
The following changes since commit f011ccb490f952ea35e9ce4d73ca9b7d0d2453c3: linux-firmware: add firmware for MT7986 (2022-03-04 08:43:26 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_v70.0.5_dg2 for you to fetch changes up to 850f9be3f587b63aa43da3f4b5b85399dfd67c1f: i915: Add GuC v70.0.5 for DG2 (2022-03-08 15:14:12 -0800) John Harrison (2): i915: Add GuC v70.0.5 for all platforms i915: Add GuC v70.0.5 for DG2 WHENCE | 33 + i915/adlp_guc_70.0.5.bin | Bin 0 -> 290496 bytes i915/bxt_guc_70.0.5.bin | Bin 0 -> 206592 bytes i915/cml_guc_70.0.5.bin | Bin 0 -> 207040 bytes i915/dg1_guc_70.0.5.bin | Bin 0 -> 266112 bytes i915/dg2_guc_70.0.5.bin | Bin 0 -> 365504 bytes i915/ehl_guc_70.0.5.bin | Bin 0 -> 274944 bytes i915/glk_guc_70.0.5.bin | Bin 0 -> 206912 bytes i915/icl_guc_70.0.5.bin | Bin 0 -> 274944 bytes i915/kbl_guc_70.0.5.bin | Bin 0 -> 207040 bytes i915/skl_guc_70.0.5.bin | Bin 0 -> 206336 bytes i915/tgl_guc_70.0.5.bin | Bin 0 -> 278400 bytes 12 files changed, 33 insertions(+) create mode 100644 i915/adlp_guc_70.0.5.bin create mode 100644 i915/bxt_guc_70.0.5.bin create mode 100644 i915/cml_guc_70.0.5.bin create mode 100644 i915/dg1_guc_70.0.5.bin create mode 100644 i915/dg2_guc_70.0.5.bin create mode 100644 i915/ehl_guc_70.0.5.bin create mode 100644 i915/glk_guc_70.0.5.bin create mode 100644 i915/icl_guc_70.0.5.bin create mode 100644 i915/kbl_guc_70.0.5.bin create mode 100644 i915/skl_guc_70.0.5.bin create mode 100644 i915/tgl_guc_70.0.5.bin
Re: [Intel-gfx] [PATCH v10 5/5] mei: gsc: retrieve the firmware version
On 3/8/2022 8:36 AM, Alexander Usyskin wrote:
Add a hook to retrieve the firmware version of the
GSC devices to bus-fixup.
GSC has a different MKHI clients GUIDs but the same message structure
to retrieve the firmware version as MEI so mei_fwver() can be reused.
CC: Ashutosh Dixit
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 25 +
drivers/misc/mei/hw-me.c | 2 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 67844089db21..59506ba6fc48 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -30,6 +30,12 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
#define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
+#define MEI_UUID_IGSC_MKHI UUID_LE(0xE2C2AFA2, 0x3817, 0x4D19, \
+ 0x9D, 0x95, 0x06, 0xB1, 0x6B, 0x58, 0x8A, 0x5D)
+
+#define MEI_UUID_IGSC_MKHI_FIX UUID_LE(0x46E0C1FB, 0xA546, 0x414F, \
+ 0x91, 0x70, 0xB7, 0xF4, 0x6D, 0x57, 0xB4, 0xAD)
+
These matches what the HW is reporting as sub-devices got gscfi and gsc
respectively. I think we could use a comment to make which matches what
clearer, but anyway:
Reviewed-by: Daniele Ceraolo Spurio
#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
@@ -241,6 +247,23 @@ static void mei_mkhi_fix(struct mei_cl_device *cldev)
mei_cldev_disable(cldev);
}
+static void mei_gsc_mkhi_ver(struct mei_cl_device *cldev)
+{
+ int ret;
+
+ /* No need to enable the client if nothing is needed from it */
+ if (!cldev->bus->fw_f_fw_ver_supported)
+ return;
+
+ ret = mei_cldev_enable(cldev);
+ if (ret)
+ return;
+
+ ret = mei_fwver(cldev);
+ if (ret < 0)
+ dev_err(&cldev->dev, "FW version command failed %d\n", ret);
+ mei_cldev_disable(cldev);
+}
/**
* mei_wd - wd client on the bus, change protocol version
* as the API has changed.
@@ -492,6 +515,8 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI, mei_gsc_mkhi_ver),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_ver),
MEI_FIXUP(MEI_UUID_HDCP, whitelist),
MEI_FIXUP(MEI_UUID_ANY, vt_support),
MEI_FIXUP(MEI_UUID_PAVP, whitelist),
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 9748d14849a1..7e77328142ff 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -1577,12 +1577,14 @@ static const struct mei_cfg mei_me_pch15_sps_cfg = {
static const struct mei_cfg mei_me_gsc_cfg = {
MEI_CFG_TYPE_GSC,
MEI_CFG_PCH8_HFS,
+ MEI_CFG_FW_VER_SUPP,
};
/* Graphics System Controller Firmware Interface */
static const struct mei_cfg mei_me_gscfi_cfg = {
MEI_CFG_TYPE_GSCFI,
MEI_CFG_PCH8_HFS,
+ MEI_CFG_FW_VER_SUPP,
};
/*
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/reset: Fix error_state_read ptr + offset use
On 3/8/2022 11:47, Teres Alexis, Alan Previn wrote:
On 3/1/2022 1:37 PM, John Harrison wrote:
On 2/25/2022 22:27, Alan Previn wrote:
...
This fixes a kernel page fault can happen when
multiple tests are running concurrently in a loop
and one is producing engine resets and consuming
the i915 error_state dump while the other is
forcing full GT resets. (takes a while to trigger).
Does need a fixes tag given that it is fixing a bug in an earlier
patch. Especially when it is a kernel BUG.
E.g.:
13:23> dim fixes 0e39037b31655
Fixes: 0e39037b3165 ("drm/i915: Cache the error string")
okay, will add that.
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index a4d1759375b9..c40e51298066 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -432,7 +432,7 @@ static ssize_t error_state_read(struct file
*filp, struct kobject *kobj,
struct device *kdev = kobj_to_dev(kobj);
struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
struct i915_gpu_coredump *gpu;
- ssize_t ret;
+ ssize_t ret = 0;
gpu = i915_first_error_state(i915);
if (IS_ERR(gpu)) {
@@ -444,8 +444,10 @@ static ssize_t error_state_read(struct file
*filp, struct kobject *kobj,
const char *str = "No error state collected\n";
size_t len = strlen(str);
- ret = min_t(size_t, count, len - off);
- memcpy(buf, str + off, ret);
+ if (off < len) {
+ ret = min_t(size_t, count, len - off);
+ memcpy(buf, str + off, ret);
+ }
So the problem is that the error dump disappeared while it was being
read? That seems like it cause more problems than just this
out-of-range access. E.g. what if the dump was freed and a new one
created? The entity doing the partial reads would end up with half of
one dump and half of the next.
I think we should at least add a FIXME comment to the code that fast
recycling dumps could cause inconsistent sysfs reads.
I guess you could do something like add a unique id to the gpu
coredump structure. Then, when a partial sysfs read occurs starting
at zero (i.e. a new read), take a note of the id somewhere (e.g.
inside the i915 structure). When the next non-zero read comes in,
compare the save id with the current coredump's id and return an
error if there is a mis-match.
Not sure if this would be viewed as an important enough problem to be
worth fixing. I'd be happy with just a FIXME comment for now.
For now I shall add a FIXME additional checks might impact IGT's that
currently dump and check the error state. I would assume with that
additional check in kernel, we would need to return a specific error
value like -ENODATA or -ENOLINK and handle it accordingly in the igt.
If an an extra check against returning invalid data affects an existing
IGT then that IGT is already broken. The check would to prevent userland
reading the first half of one capture and then getting the second half
of a completely different one. If that is already happening then the
returned data is meaningless gibberish and even if the IGT says it is
passing, it really isn't.
I would also change the test to be 'if (off)' rather than 'if (off <
len)'. Technically, the user could have read the first 10 bytes of a
coredump and then gets "tate collected\n" as the remainder, for
example. If we ensure that 'off' is zero then we know that this is a
fresh read from scratch.
John.
I'm a little confused, did u mean: in the case we dont have a
gpu-state to report, and then the user offset is zero (i.e. "if
(!off)" ) then we copy the string vs if we dont have a gpu-state to
report and the user-offset is non-zero, then we return an error (like
the -ENOLINK?). If thats what you meant, then it does mean we are
assuming that (in the case we dont have a gpu-state) the user will
never come in with a first-time-read where the user's buffer size of
less than the string length and be expected continue to read the rest
of the string-length. This i guess is okay since even 6 chars are
enough to say "No err". :)
Sorry, yes. That was meant to say 'if (!off)'.
Hmm, I guess technically the user could be issuing single byte reads.
User's can be evil.
Okay. Maybe just add a FIXME about needing to check for
changed/missing/new error state since last read if the offset is
non-zero and otherwise leave it as is.
John.
}
return ret;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
== Series Details ==
Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
URL : https://patchwork.freedesktop.org/series/101219/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11346 -> Patchwork_22527
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/index.html
Participating hosts (46 -> 44)
--
Additional (3): bat-rpls-2 fi-icl-u2 fi-pnv-d510
Missing(5): shard-tglu fi-bsw-cyan fi-ctg-p8600 shard-rkl shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22527:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_setmode@basic-clone-single-crtc:
- {bat-rpls-2}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/bat-rpls-2/igt@kms_setm...@basic-clone-single-crtc.html
Known issues
Here are the changes found in Patchwork_22527 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_22527/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#2943])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +58 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-pnv-d510/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_22527/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_22527/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][8] ([i915#3921])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109278]) +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][14] ([fdo#109285])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u: NOTRUN -> [SKIP][15] ([fdo#109271]) +14 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html
- fi-icl-u2: NOTRUN -> [SKIP][16] ([i915#3555])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][17] ([i915#3301])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22527/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-blb-e6850: [FAIL][18] ([i915#3194]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[19]:
https://intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: DRRS fixes/cleanups and start of static DRRS
== Series Details ==
Series: drm/i915: DRRS fixes/cleanups and start of static DRRS
URL : https://patchwork.freedesktop.org/series/101222/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d02f80fe9d06 drm/i915: Fix up some DRRS type checks
1d8de7687685 drm/i915: Constify intel_drrs_init() args
4afde97e93b0 drm/i915: Pimp DRRS debugs
68a4fe03dceb drm/i915: Read DRRS MSA timing delay from VBT
2a005be48e70 drm/i915: Program MSA timing delay on ilk/snb/ivb
691d5646b6ee drm/i915: Polish drrs type enum
0ce0532a4cce drm/i915: Clean up DRRS refresh rate enum
1cc72ce0c712 drm/i915: Rename PIPECONF refresh select bits
1407ab78d3dc drm/i915: Stash DRRS state under intel_crtc
-:252: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#252: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:1303:
+ struct mutex mutex;
total: 0 errors, 0 warnings, 1 checks, 710 lines checked
83598718ed14 drm/i915: Move DRRS enable/disable higher up
50dc95da8ab0 drm/i915: Enable eDP DRRS on ilk/snb port A
fb10fe933f94 drm/i915: Introduce intel_panel_{fixed, downclock}_mode()
ec08fd6eee6a drm/i915: Implement static DRRS
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: DRRS fixes/cleanups and start of static DRRS
== Series Details == Series: drm/i915: DRRS fixes/cleanups and start of static DRRS URL : https://patchwork.freedesktop.org/series/101222/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/reset: Fix error_state_read ptr + offset use
On 3/9/2022 5:18 PM, John Harrison wrote:
On 3/8/2022 11:47, Teres Alexis, Alan Previn wrote:
On 3/1/2022 1:37 PM, John Harrison wrote:
On 2/25/2022 22:27, Alan Previn wrote:
...
This fixes a kernel page fault can happen when
multiple tests are running concurrently in a loop
and one is producing engine resets and consuming
the i915 error_state dump while the other is
forcing full GT resets. (takes a while to trigger).
Does need a fixes tag given that it is fixing a bug in an earlier
patch. Especially when it is a kernel BUG.
E.g.:
13:23> dim fixes 0e39037b31655
Fixes: 0e39037b3165 ("drm/i915: Cache the error string")
okay, will add that.
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index a4d1759375b9..c40e51298066 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -432,7 +432,7 @@ static ssize_t error_state_read(struct file
*filp, struct kobject *kobj,
struct device *kdev = kobj_to_dev(kobj);
struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
struct i915_gpu_coredump *gpu;
- ssize_t ret;
+ ssize_t ret = 0;
gpu = i915_first_error_state(i915);
if (IS_ERR(gpu)) {
@@ -444,8 +444,10 @@ static ssize_t error_state_read(struct file
*filp, struct kobject *kobj,
const char *str = "No error state collected\n";
size_t len = strlen(str);
- ret = min_t(size_t, count, len - off);
- memcpy(buf, str + off, ret);
+ if (off < len) {
+ ret = min_t(size_t, count, len - off);
+ memcpy(buf, str + off, ret);
+ }
So the problem is that the error dump disappeared while it was being
read? That seems like it cause more problems than just this
out-of-range access. E.g. what if the dump was freed and a new one
created? The entity doing the partial reads would end up with half
of one dump and half of the next.
I think we should at least add a FIXME comment to the code that fast
recycling dumps could cause inconsistent sysfs reads.
I guess you could do something like add a unique id to the gpu
coredump structure. Then, when a partial sysfs read occurs starting
at zero (i.e. a new read), take a note of the id somewhere (e.g.
inside the i915 structure). When the next non-zero read comes in,
compare the save id with the current coredump's id and return an
error if there is a mis-match.
Not sure if this would be viewed as an important enough problem to
be worth fixing. I'd be happy with just a FIXME comment for now.
For now I shall add a FIXME additional checks might impact IGT's that
currently dump and check the error state. I would assume with that
additional check in kernel, we would need to return a specific error
value like -ENODATA or -ENOLINK and handle it accordingly in the igt.
If an an extra check against returning invalid data affects an
existing IGT then that IGT is already broken. The check would to
prevent userland reading the first half of one capture and then
getting the second half of a completely different one. If that is
already happening then the returned data is meaningless gibberish and
even if the IGT says it is passing, it really isn't.
I would also change the test to be 'if (off)' rather than 'if (off <
len)'. Technically, the user could have read the first 10 bytes of a
coredump and then gets "tate collected\n" as the remainder, for
example. If we ensure that 'off' is zero then we know that this is a
fresh read from scratch.
John.
I'm a little confused, did u mean: in the case we dont have a
gpu-state to report, and then the user offset is zero (i.e. "if
(!off)" ) then we copy the string vs if we dont have a gpu-state to
report and the user-offset is non-zero, then we return an error (like
the -ENOLINK?). If thats what you meant, then it does mean we are
assuming that (in the case we dont have a gpu-state) the user will
never come in with a first-time-read where the user's buffer size of
less than the string length and be expected continue to read the rest
of the string-length. This i guess is okay since even 6 chars are
enough to say "No err". :)
Sorry, yes. That was meant to say 'if (!off)'.
Hmm, I guess technically the user could be issuing single byte reads.
User's can be evil.
Okay. Maybe just add a FIXME about needing to check for
changed/missing/new error state since last read if the offset is
non-zero and otherwise leave it as is.
John.
Sounds good - will do. Apologies on the tardiness with the responses.
}
return ret;
Re: [Intel-gfx] [PATCH v7 04/13] drm/i915/guc: Add DG2 registers for GuC error state capture.
On Sat, Feb 26, 2022 at 01:55:32AM -0800, Alan Previn wrote:
Add additional DG2 registers for GuC error state capture.
Signed-off-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 80 ++-
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 6370943ea300..c8441ca1566b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -285,20 +285,96 @@ guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc
*guc,
guc->capture.priv->extlists = extlists;
}
+static const struct __ext_steer_reg xehpg_extregs[] = {
+ {"XEHPG_INSTDONE_GEOM_SVG", XEHPG_INSTDONE_GEOM_SVG}
+};
+
+static bool __has_xehpg_extregs(u32 ipver)
What I meant was to make has_xehpg_extregs part of platform feature, but
this is fine too.
+{
+ return (ipver >= IP_VER(12, 55));
+}
+
+static void
+guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc *guc,
+ const struct __guc_mmio_reg_descr_group
*lists,
+ u32 ipver)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct sseu_dev_info *sseu;
+ int slice, subslice, i, iter, num_steer_regs, num_tot_regs = 0;
+ const struct __guc_mmio_reg_descr_group *list;
+ struct __guc_mmio_reg_descr_group *extlists;
+ struct __guc_mmio_reg_descr *extarray;
+
+ /* In XE_LP / HPG we only have render-class steering registers during
error-capture */
+ list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF,
+ GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
GUC_RENDER_CLASS);
+ /* skip if extlists was previously allocated */
+ if (!list || guc->capture.priv->extlists)
+ return;
+
+ num_steer_regs = ARRAY_SIZE(xe_extregs);
+ if (__has_xehpg_extregs(ipver))
+ num_steer_regs += ARRAY_SIZE(xehpg_extregs);
+
+ sseu = >->info.sseu;
+ for_each_instdone_gslice_dss_xehp(i915, sseu, iter, slice, subslice) {
+ num_tot_regs += num_steer_regs;
+ }
+
+ if (!num_tot_regs)
+ return;
+
+ /* allocate an extra for an end marker */
+ extlists = kcalloc(2, sizeof(struct __guc_mmio_reg_descr_group),
GFP_KERNEL);
+ if (!extlists)
+ return;
+
+ if (__alloc_ext_regs(&extlists[0], list, num_tot_regs)) {
+ kfree(extlists);
+ return;
+ }
+
+ extarray = extlists[0].extlist;
+ for_each_instdone_gslice_dss_xehp(i915, sseu, iter, slice, subslice) {
+ for (i = 0; i < ARRAY_SIZE(xe_extregs); ++i) {
+ __fill_ext_reg(extarray, &xe_extregs[i], slice,
subslice);
+ ++extarray;
+ }
+ if (__has_xehpg_extregs(ipver)) {
+ for (i = 0; i < ARRAY_SIZE(xehpg_extregs); ++i) {
+ __fill_ext_reg(extarray, &xehpg_extregs[i],
slice, subslice);
+ ++extarray;
+ }
+ }
+ }
+
+ drm_dbg(&i915->drm, "GuC-capture found %d-ext-regs.\n", num_tot_regs);
+ guc->capture.priv->extlists = extlists;
+}
+
static const struct __guc_mmio_reg_descr_group *
guc_capture_get_device_reglist(struct intel_guc *guc)
{
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
if (IS_TIGERLAKE(i915) || IS_ROCKETLAKE(i915) ||
- IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i915)) {
+ IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i915) ||
+ IS_DG2(i915) || IS_XEHPSDV(i915)) {
/*
* For certain engine classes, there are slice and subslice
* level registers requiring steering. We allocate and populate
* these at init time based on hw config add it as an extension
* list at the end of the pre-populated render list.
*/
- guc_capture_alloc_steered_lists_xe_lpd(guc, xe_lpd_lists);
+ if (IS_DG2(i915))
+ guc_capture_alloc_steered_lists_xe_hpg(guc,
xe_lpd_lists, IP_VER(12, 55));
+ else if (IS_XEHPSDV(i915))
+ guc_capture_alloc_steered_lists_xe_hpg(guc,
xe_lpd_lists, IP_VER(12, 50));
+ else
+ guc_capture_alloc_steered_lists_xe_lpd(guc,
xe_lpd_lists);
+
return xe_lpd_lists;
}
If you know that this applies to gen12 platforms, then you could do away with
the ORed platform checks. I think it is cumbersome to maintain an OR of
platforms that need this. The other pattern I see in the driver is like this:
i.e, If you return xe_lpd_lists back from
guc_capture_alloc_steered_lists_xe_hpg, then
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DRRS fixes/cleanups and start of static DRRS
== Series Details ==
Series: drm/i915: DRRS fixes/cleanups and start of static DRRS
URL : https://patchwork.freedesktop.org/series/101222/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11346 -> Patchwork_22528
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/index.html
Participating hosts (46 -> 42)
--
Additional (2): bat-rpls-2 fi-icl-u2
Missing(6): shard-tglu fi-bsw-cyan fi-ctg-p8600 fi-kbl-8809g shard-rkl
shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22528:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_setmode@basic-clone-single-crtc:
- {bat-rpls-2}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/bat-rpls-2/igt@kms_setm...@basic-clone-single-crtc.html
Known issues
Here are the changes found in Patchwork_22528 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_22528/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#3921])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([fdo#111827]) +8 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: NOTRUN -> [SKIP][8] ([fdo#109278]) +2 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([fdo#109285])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][10] ([i915#3555])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([i915#3301])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-icl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][12] ([i915#2426] / [i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-blb-e6850: [FAIL][13] ([i915#3194]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [INCOMPLETE][15] ([i915#146]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-6: [FAIL][17] ([i915#4032]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/bat-dg1-6/igt@i915_pm_...@basic-api.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/bat-dg1-6/igt@i915_pm_...@basic-api.html
* igt@kms_busy@basic@flip:
- {bat-dg2-9}:[DMESG-WARN][19] ([i915#5195]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/bat-dg2-9/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22528/bat-dg2-9/igt@
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation (rev2)
== Series Details ==
Series: drm/mm: Add an iterator to optimally walk over holes suitable for an
allocation (rev2)
URL : https://patchwork.freedesktop.org/series/101123/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11346_full -> Patchwork_22523_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22523_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22523_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_22523_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gem_contexts:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-skl4/igt@i915_selftest@live@gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-skl2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-tglb: NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-tglb3/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_draw_crc@draw-method-xrgb-render-4tiled:
- shard-iclb: NOTRUN -> [SKIP][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-iclb8/igt@kms_draw_...@draw-method-xrgb-render-4tiled.html
* igt@kms_hdr@bpc-switch-dpms@bpc-switch-dpms-edp-1-pipe-a:
- shard-skl: [PASS][5] -> [FAIL][6] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-skl8/igt@kms_hdr@bpc-switch-d...@bpc-switch-dpms-edp-1-pipe-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-skl4/igt@kms_hdr@bpc-switch-d...@bpc-switch-dpms-edp-1-pipe-a.html
* igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-dp-1-pipe-a:
- shard-kbl: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-kbl1/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-dp-1-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-kbl4/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-dp-1-pipe-a.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_big_fb@4-tiled-64bpp-rotate-90:
- {shard-dg1}:NOTRUN -> [SKIP][9] +6 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-dg1-12/igt@kms_big...@4-tiled-64bpp-rotate-90.html
* igt@kms_mmap_write_crc@main:
- {shard-dg1}:NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-dg1-19/igt@kms_mmap_write_...@main.html
* igt@kms_plane_multiple@atomic-pipe-d-tiling-4:
- {shard-rkl}:[SKIP][11] ([i915#4070]) -> [SKIP][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-rkl-1/igt@kms_plane_multi...@atomic-pipe-d-tiling-4.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-rkl-5/igt@kms_plane_multi...@atomic-pipe-d-tiling-4.html
*
{igt@kms_plane_scaling@scaler-with-pixel-format-unity-scaling@pipe-b-edp-1-scaler-with-pixel-format}:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-iclb4/igt@kms_plane_scaling@scaler-with-pixel-format-unity-scal...@pipe-b-edp-1-scaler-with-pixel-format.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-iclb2/igt@kms_plane_scaling@scaler-with-pixel-format-unity-scal...@pipe-b-edp-1-scaler-with-pixel-format.html
* igt@kms_setmode@invalid-clone-single-crtc:
- {shard-rkl}:NOTRUN -> [SKIP][15] +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-rkl-2/igt@kms_setm...@invalid-clone-single-crtc.html
Known issues
Here are the changes found in Patchwork_22523_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][16] -> [SKIP][17] ([i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-iclb2/igt@feature_discov...@psr2.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-iclb6/igt@feature_discov...@psr2.html
* igt@gem_create@create-massive:
- shard-kbl: NOTRUN -> [DMESG-WARN][18] ([i915#4991])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22523/shard-kbl3/igt@gem_cre...@create-
[Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.
v2: fix white space errors
Cc: Ashutosh Dixit
Cc: Matt Roper
Cc: Joonas Lahtinen
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/i915_query.c | 68 ++-
include/uapi/drm/i915_drm.h | 24 +++
2 files changed, 65 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..e4f35da28642 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "i915_perf.h"
#include "i915_query.h"
+#include "gt/intel_engine_user.h"
#include
static int copy_query_item(void *query_hdr, size_t query_sz,
@@ -28,36 +29,30 @@ static int copy_query_item(void *query_hdr, size_t query_sz,
return 0;
}
-static int query_topology_info(struct drm_i915_private *dev_priv,
- struct drm_i915_query_item *query_item)
+static int fill_topology_info(const struct sseu_dev_info *sseu,
+ struct drm_i915_query_item *query_item,
+ const u8 *subslice_mask)
{
- const struct sseu_dev_info *sseu = &to_gt(dev_priv)->info.sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
int ret;
- if (query_item->flags != 0)
- return -EINVAL;
+ BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
if (sseu->max_slices == 0)
return -ENODEV;
- BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
-
slice_length = sizeof(sseu->slice_mask);
subslice_length = sseu->max_slices * sseu->ss_stride;
eu_length = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
- ret = copy_query_item(&topo, sizeof(topo), total_length,
- query_item);
+ ret = copy_query_item(&topo, sizeof(topo), total_length, query_item);
+
if (ret != 0)
return ret;
- if (topo.flags != 0)
- return -EINVAL;
-
memset(&topo, 0, sizeof(topo));
topo.max_slices = sseu->max_slices;
topo.max_subslices = sseu->max_subslices;
@@ -69,27 +64,61 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.eu_stride = sseu->eu_stride;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
- &topo, sizeof(topo)))
+&topo, sizeof(topo)))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + sizeof(topo)),
- &sseu->slice_mask, slice_length))
+&sseu->slice_mask, slice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) + slice_length),
- sseu->subslice_mask, subslice_length))
+sizeof(topo) + slice_length),
+subslice_mask, subslice_length))
return -EFAULT;
if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
- sizeof(topo) +
- slice_length + subslice_length),
- sseu->eu_mask, eu_length))
+sizeof(topo) +
+slice_length + subslice_length),
+sseu->eu_mask, eu_length))
return -EFAULT;
return total_length;
}
+static int query_topology_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu = &to_gt(dev_priv)->info.sseu;
+
+ if (query_item->flags != 0)
+ return -EINVAL;
+
+ return fill_topology_info(sseu, query_item, sseu->subslice_mask);
+}
+
+static int query_geometry_subslices(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ const struct sseu_dev_info *sseu;
+ struct intel_engine_cs *engine;
+ u8 engine_class, engine_instance;
+
+ if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
+ return -ENODEV;
+
+ engine_class = query_item->flags & 0xFF;
+ engine_instance = (query_item->flags >> 8) & 0xFF;
+
+ engine = intel_engine_lookup_user(i915, engine_class, engin
Re: [Intel-gfx] [PATCH v7 01/13] drm/i915/guc: Update GuC ADS size for error capture lists
On Sat, Feb 26, 2022 at 01:55:29AM -0800, Alan Previn wrote:
> Update GuC ADS size allocation to include space for
> the lists of error state capture register descriptors.
>
> Also, populate the lists of registers we want GuC to report back to
> Host on engine reset events. This list should include global,
> engine-class and engine-instance registers for every engine-class
> type on the current hardware.
>
> NOTE: Start with a sample table of register lists to layout the
> framework before adding real registers in subsequent patch.
>
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 89 +
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 13 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 132 ++-
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 352 ++
> .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 22 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +
> 8 files changed, 611 insertions(+), 17 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 9d588d936e3d..547adc36d4e9 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -184,6 +184,7 @@ i915-y += gt/uc/intel_uc.o \
> gt/uc/intel_uc_fw.o \
> gt/uc/intel_guc.o \
> gt/uc/intel_guc_ads.o \
> + gt/uc/intel_guc_capture.o \
> gt/uc/intel_guc_ct.o \
> gt/uc/intel_guc_debugfs.o \
> gt/uc/intel_guc_fw.o \
> diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> new file mode 100644
> index ..858f85478636
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> @@ -0,0 +1,89 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2021-2022 Intel Corporation
> + */
> +
> +#ifndef _INTEL_GUC_CAPTURE_FWIF_H
> +#define _INTEL_GUC_CAPTURE_FWIF_H
> +
> +#include
> +#include "intel_guc_fwif.h"
> +
> +struct intel_guc;
> +struct file;
> +
> +/**
> + * struct guc_debug_capture_list_header / struct guc_debug_capture_list
> + *
> + * As part of ADS registration, these header structures (followed by
> + * an array of 'struct guc_mmio_reg' entries) are used to register with
> + * GuC microkernel the list of registers we want it to dump out prior
> + * to a engine reset.
> + */
> +struct guc_debug_capture_list_header {
> + u32 info;
> +#define GUC_CAPTURELISTHDR_NUMDESCR GENMASK(15, 0)
> +} __packed;
> +
> +struct guc_debug_capture_list {
> + struct guc_debug_capture_list_header header;
struct guc_mmio_reg regs[0];
This is the convention when allocating dynamically sized structures.
This allows:
list.header
list.regs[some index]
Also by looking at the structure definition, it implies that the end of
struct is dynamically allocated array.
> +} __packed;
> +
> +/**
> + * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group
> + *
> + * intel_guc_capture module uses these structures to maintain static
> + * tables (per unique platform) that consists of lists of registers
> + * (offsets, names, flags,...) that are used at the ADS regisration
> + * time as well as during runtime processing and reporting of error-
> + * capture states generated by GuC just prior to engine reset events.
> + */
> +struct __guc_mmio_reg_descr {
> + i915_reg_t reg;
> + u32 flags;
> + u32 mask;
> + const char *regname;
> +};
> +
> +struct __guc_mmio_reg_descr_group {
> + const struct __guc_mmio_reg_descr *list;
> + u32 num_regs;
> + u32 owner; /* see enum guc_capture_owner */
> + u32 type; /* see enum guc_capture_type */
> + u32 engine; /* as per MAX_ENGINE_CLASS */
> +};
> +
> +/**
> + * struct __guc_capture_ads_cache
> + *
> + * A structure to cache register lists that were populated and registered
> + * with GuC at startup during ADS registration. This allows much quicker
> + * GuC resets without re-parsing all the tables for the given gt.
It also stores a one time allocated file too which I don't think you
need rather just a pointer. More on this below.
> + */
> +struct __guc_capture_ads_cache {
> + bool is_valid;
> + struct file *file;
> + size_t size;
> + int status;
> +};
> +
> +/**
> + * struct __guc_state_capture_priv
> + *
> + * Internal context of the intel_guc_capture module.
> + */
> +struct __guc_state_capture_priv {
> + /**
> + * @reglists: static table of register lists used for error-capture
> state.
> + */
> + const struct __guc_mmio_reg_descr_group *reglists;
> +
> + /**
> + * @ads_cache: cached register lists that is ADS format ready
> + */
> + st
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev2)
== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev2) URL : https://patchwork.freedesktop.org/series/101219/ 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.IGT: failure for drm/i915: SAGV block time fixes (rev2)
== Series Details ==
Series: drm/i915: SAGV block time fixes (rev2)
URL : https://patchwork.freedesktop.org/series/101171/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11346_full -> Patchwork_22524_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22524_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22524_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_22524_full:
### IGT changes ###
Possible regressions
* igt@kms_draw_crc@draw-method-xrgb-render-4tiled:
- shard-iclb: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-iclb5/igt@kms_draw_...@draw-method-xrgb-render-4tiled.html
* igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary:
- shard-tglb: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-tglb6/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-tglb6/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html
* igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-dp-1-pipe-a:
- shard-kbl: [PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-kbl1/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-dp-1-pipe-a.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-kbl4/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-dp-1-pipe-a.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_big_fb@4-tiled-64bpp-rotate-90:
- {shard-rkl}:[SKIP][6] ([i915#5286]) -> [SKIP][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-rkl-6/igt@kms_big...@4-tiled-64bpp-rotate-90.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-rkl-2/igt@kms_big...@4-tiled-64bpp-rotate-90.html
* igt@kms_big_fb@4-tiled-addfb-size-overflow:
- {shard-rkl}:NOTRUN -> [SKIP][8] +6 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-rkl-2/igt@kms_big...@4-tiled-addfb-size-overflow.html
* igt@kms_draw_crc@draw-method-xrgb-blt-4tiled:
- {shard-dg1}:NOTRUN -> [SKIP][9] +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-dg1-18/igt@kms_draw_...@draw-method-xrgb-blt-4tiled.html
* igt@kms_mmap_write_crc@main:
- {shard-dg1}:NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22524/shard-dg1-16/igt@kms_mmap_write_...@main.html
Known issues
Here are the changes found in Patchwork_22524_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-glk: ([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], [FAIL][26],
[PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35]) ([i915#4392]) -> ([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], [PASS][58], [PASS][59], [PASS][60])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk9/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk9/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk9/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk8/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk8/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk8/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk6/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk5/boot.html
[23]:
https:/
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev2)
== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev2) URL : https://patchwork.freedesktop.org/series/101219/ State : success == Summary == CI Bug Log - changes from CI_DRM_11347 -> Patchwork_22529 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/index.html Participating hosts (40 -> 36) -- Additional (2): fi-bxt-dsi fi-icl-u2 Missing(6): bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-rpls-2 bat-jsl-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_22529 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-bxt-dsi: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@requests: - fi-pnv-d510:[PASS][6] -> [DMESG-FAIL][7] ([i915#2927] / [i915#4528]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11347/fi-pnv-d510/igt@i915_selftest@l...@requests.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-pnv-d510/igt@i915_selftest@l...@requests.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bxt-dsi: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#109278]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-bxt-dsi: NOTRUN -> [SKIP][11] ([fdo#109271]) +31 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html - fi-icl-u2: NOTRUN -> [SKIP][12] ([fdo#109285]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-bxt-dsi: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_setmode@basic-clone-single-crtc: - fi-icl-u2: NOTRUN -> [SKIP][14] ([i915#3555]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-userptr: - fi-icl-u2: NOTRUN -> [SKIP][15] ([i915#3301]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-icl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-pnv-d510:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#2403] / [i915#4312]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-pnv-d510/igt@run...@aborted.html Possible fixes * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][17] ([i915#295]) -> [PASS][18] +11 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11347/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22529/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-guc: [FAIL][19] ([i915#3049]) -> [SKIP][20] ([fd
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Clean up some dpll stuff (rev6)
== Series Details ==
Series: drm/i915: Clean up some dpll stuff (rev6)
URL : https://patchwork.freedesktop.org/series/100899/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11346_full -> Patchwork_22526_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22526_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22526_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_22526_full:
### IGT changes ###
Possible regressions
* igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-skl8/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-edp-1-pipe-a.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/shard-skl9/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-edp-1-pipe-a.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_mmap_write_crc@main:
- {shard-dg1}:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/shard-dg1-19/igt@kms_mmap_write_...@main.html
* igt@kms_plane_lowres@pipe-a-tiling-4:
- {shard-rkl}:NOTRUN -> [SKIP][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/shard-rkl-1/igt@kms_plane_low...@pipe-a-tiling-4.html
*
{igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-25@pipe-c-hdmi-a-3-downscale-with-pixel-format}:
- {shard-dg1}:NOTRUN -> [SKIP][5] +4 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22526/shard-dg1-18/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-c-hdmi-a-3-downscale-with-pixel-format.html
Known issues
Here are the changes found in Patchwork_22526_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-glk: ([PASS][6], [PASS][7], [PASS][8], [PASS][9],
[PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][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#4392]) -> ([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_11346/shard-glk5/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk3/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk3/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk9/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk9/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk9/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk8/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk8/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk4/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk8/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk5/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11346/shard-glk2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_113
Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Round up when calculating display bandwidth requirements
On Thu, Mar 03, 2022 at 09:12:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We should round up when doing bandwidth calculations to make sure
> our estimates don't fall short of the actual number.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index df98b1d7a6f7..0759bb95ea4b 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -638,7 +638,7 @@ static unsigned int intel_bw_data_rate(struct
> drm_i915_private *dev_priv,
> data_rate += bw_state->data_rate[pipe];
>
> if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv))
> - data_rate = data_rate * 105 / 100;
> + data_rate = DIV_ROUND_UP(data_rate * 105, 100);
>
> return data_rate;
> }
> @@ -763,7 +763,7 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> }
> }
>
> - new_bw_state->min_cdclk = max_bw / 64;
> + new_bw_state->min_cdclk = DIV_ROUND_UP(max_bw, 64);
>
> if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> int ret = intel_atomic_lock_global_state(&new_bw_state->base);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v2 7/9] drm/i915: Properly write lock bw_state when it changes
On Thu, Mar 03, 2022 at 09:12:05PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code also forgets to call intel_atomic_lock_global_state()
> when other stuff besides the final min_cdlck changes in the state.
> That means we may throw away data which actually has changed, and
> thus we can't be at all sure what the code ends up doing during
> subsequent commits. Do the write lock properly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 0759bb95ea4b..56eebccd16e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -678,6 +678,28 @@ intel_atomic_get_bw_state(struct intel_atomic_state
> *state)
> return to_intel_bw_state(bw_state);
> }
>
> +static bool intel_bw_state_changed(struct drm_i915_private *i915,
> +const struct intel_bw_state *old_bw_state,
> +const struct intel_bw_state *new_bw_state)
> +{
> + enum pipe pipe;
> +
> + for_each_pipe(i915, pipe) {
> + const struct intel_dbuf_bw *old_crtc_bw =
> + &old_bw_state->dbuf_bw[pipe];
> + const struct intel_dbuf_bw *new_crtc_bw =
> + &new_bw_state->dbuf_bw[pipe];
> + enum dbuf_slice slice;
> +
> + for_each_dbuf_slice(i915, slice) {
> + if (old_crtc_bw->used_bw[slice] !=
> new_crtc_bw->used_bw[slice])
> + return true;
> + }
> + }
> +
> + return old_bw_state->min_cdclk != new_bw_state->min_cdclk;
> +}
> +
> static void skl_crtc_calc_dbuf_bw(struct intel_bw_state *bw_state,
> const struct intel_crtc_state *crtc_state)
> {
> @@ -765,7 +787,7 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
>
> new_bw_state->min_cdclk = DIV_ROUND_UP(max_bw, 64);
>
> - if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
> + if (intel_bw_state_changed(dev_priv, old_bw_state, new_bw_state)) {
> int ret = intel_atomic_lock_global_state(&new_bw_state->base);
>
> if (ret)
> --
> 2.34.1
>
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel, Here's a batch of -next-fixes from drm-intel-next/drm-intel-gt-next. On GT side just a fix to relax GGTT alignment down 64K from 2M. Addition of missing "name" attribute for GVT mdev device. On display side async flip fixes and a static checker fix. CI results had some display errors on TGL, the display has been rebooted to fix those so should cause no worries. Regards, Joonas *** drm-intel-next-fixes-2022-03-10: - Reduce overzealous alignment constraints for GGTT - Add missing mdev attribute "name" for GVT - Async flip fixes (Ville) - Static checker fix (Ville) The following changes since commit 6de7e4f02640fba2ffa6ac04e2be13785d614175: Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next (2022-03-04 14:39:00 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-03-10 for you to fetch changes up to 5e7f44b5c2c035fe2e5458193c2bbee56db6a090: drm/i915/gtt: reduce overzealous alignment constraints for GGTT (2022-03-09 08:34:55 +0200) - Reduce overzealous alignment constraints for GGTT - Add missing mdev attribute "name" for GVT - Async flip fixes (Ville) - Static checker fix (Ville) Joonas Lahtinen (1): Merge tag 'gvt-next-2022-03-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Matthew Auld (1): drm/i915/gtt: reduce overzealous alignment constraints for GGTT Ville Syrjälä (4): drm/i915: Avoid negative shift due to bigjoiner_pipes==0 drm/i915: Don't skip ddb allocation if data_rate==0 drm/i915: Check async flip capability early on drm/i915: Fix the async flip wm0/ddb optimization Zhi Wang (1): drm/i915/gvt: add the missing mdev attribute "name" drivers/gpu/drm/i915/display/intel_atomic.c| 1 + drivers/gpu/drm/i915/display/intel_atomic_plane.c | 7 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 122 + drivers/gpu/drm/i915/display/intel_display_types.h | 6 +- drivers/gpu/drm/i915/gt/intel_gtt.c| 3 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +++ drivers/gpu/drm/i915/intel_pm.c| 30 ++--- 8 files changed, 136 insertions(+), 52 deletions(-)
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Use iosys_map interface to update lrc_desc
== Series Details ==
Series: drm/i915/guc: Use iosys_map interface to update lrc_desc
URL : https://patchwork.freedesktop.org/series/101166/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11337_full -> Patchwork_22515_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_22515_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_flush@basic-wb-ro-default:
- {shard-rkl}:([PASS][1], [PASS][2]) -> [INCOMPLETE][3]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-rkl-1/igt@gem_exec_fl...@basic-wb-ro-default.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-rkl-4/igt@gem_exec_fl...@basic-wb-ro-default.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-rkl-5/igt@gem_exec_fl...@basic-wb-ro-default.html
* igt@gem_exec_whisper@basic-queues-priority:
- {shard-rkl}:([PASS][4], [PASS][5]) -> [DMESG-WARN][6]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-rkl-4/igt@gem_exec_whis...@basic-queues-priority.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-rkl-1/igt@gem_exec_whis...@basic-queues-priority.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-rkl-5/igt@gem_exec_whis...@basic-queues-priority.html
* igt@gem_linear_blits@normal:
- {shard-dg1}:[PASS][7] -> [TIMEOUT][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-dg1-19/igt@gem_linear_bl...@normal.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-dg1-18/igt@gem_linear_bl...@normal.html
* igt@kms_cursor_legacy@all-pipes-forked-bo:
- {shard-rkl}:[PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-rkl-1/igt@kms_cursor_leg...@all-pipes-forked-bo.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-rkl-5/igt@kms_cursor_leg...@all-pipes-forked-bo.html
* {igt@kms_hdr@bpc-switch@bpc-switch-edp-1-pipe-a}:
- shard-skl: NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-skl6/igt@kms_hdr@bpc-swi...@bpc-switch-edp-1-pipe-a.html
* igt@kms_hdr@static-toggle-suspend:
- {shard-dg1}:NOTRUN -> [SKIP][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-dg1-17/igt@kms_...@static-toggle-suspend.html
*
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-b-edp-1-planes-upscale-downscale.html
*
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale}:
- shard-iclb: [PASS][14] -> [SKIP][15] +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-edp-1-planes-upscale-downscale.html
Known issues
Here are the changes found in Patchwork_22515_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#232])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-tglb6/igt@gem_...@unwedge-stress.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-tglb5/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][18] -> [FAIL][19] ([i915#2842])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][20] ([i915#2842])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22515/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2842]) +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11337/shard-tglb2/igt@gem_exec_fair@basic-
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
On 08/03/2022 17:27, Kai Vehmanen wrote:
If kernel is built with hung task detection enabled and
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds,
snd_hdac_i915_init() will trigger the hung task timeout in case i915 is
not available and taint the kernel.
Split the 60sec wait into a loop of smaller waits to avoid this.
Reviewed-by: Lucas De Marchi
Co-developed-by: Ramalingam C
Signed-off-by: Ramalingam C
Signed-off-by: Kai Vehmanen
---
sound/hda/hdac_i915.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Changes V1->V2:
- address local variable naming issue raised by Amadeusz
and use Takashi's proposal
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 454474ac5716..aa48bed7baf7 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -143,7 +143,7 @@ static bool i915_gfx_present(void)
int snd_hdac_i915_init(struct hdac_bus *bus)
{
struct drm_audio_component *acomp;
- int err;
+ int err, i;
if (!i915_gfx_present())
return -ENODEV;
@@ -159,9 +159,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
if (!acomp->ops) {
if (!IS_ENABLED(CONFIG_MODULES) ||
!request_module("i915")) {
- /* 60s timeout */
Where does this 60s come from and why is the fix to work around
DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would
limiting the wait here to whatever the kconfig is set to be an option?
Regards,
Tvrtko
-
wait_for_completion_timeout(&acomp->master_bind_complete,
- msecs_to_jiffies(60 *
1000));
+ /* max 60s timeout */
+ for (i = 0; i < 60; i++)
+ if
(wait_for_completion_timeout(&acomp->master_bind_complete,
+
msecs_to_jiffies(1000)))
+ break;
}
}
if (!acomp->ops) {
base-commit: fd7698cf0858f8c5e659b655109cd93c2f15cdd3
Re: [Intel-gfx] [PATCH] drm/i915/vlv_dsi_pll: use min_t() to make code cleaner
On Tue, 08 Mar 2022, cgel@gmail.com wrote: > From: Changcheng Deng > > Use min_t() in order to make code cleaner. > > Reported-by: Zeal Robot > Signed-off-by: Changcheng Deng Thanks, pushed to drm-intel-next. BR, Jani. > --- > drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c > b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c > index df880f44700a..f801f7ec3f9a 100644 > --- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c > +++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c > @@ -393,10 +393,7 @@ static void glk_dsi_program_esc_clock(struct drm_device > *dev, > /* Calculate TXESC2 divider */ > div2_value = DIV_ROUND_UP(div1_value, txesc1_div); > > - if (div2_value < 10) > - txesc2_div = div2_value; > - else > - txesc2_div = 10; > + txesc2_div = min_t(u32, div2_value, 10); > > intel_de_write(dev_priv, MIPIO_TXESC_CLK_DIV1, > (1 << (txesc1_div - 1)) & GLK_TX_ESC_CLK_DIV1_MASK); -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
Hi, On Wed, 9 Mar 2022, Tvrtko Ursulin wrote: > > - /* 60s timeout */ > > Where does this 60s come from and why is the fix to work around > DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would > limiting the wait here to whatever the kconfig is set to be an option? this was discussed in https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html ... and that thread concluded it's cleaner to split the wait than try to figure out hung-task configuration from middle of audio driver. The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component bind timeout" to fix an issue reported by Paul Menzel (cc'ed). This patch keeps the timeout intact. Br, Kai
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
On Wed, 09 Mar 2022 09:36:54 +0100,
Tvrtko Ursulin wrote:
>
>
> On 08/03/2022 17:27, Kai Vehmanen wrote:
> > If kernel is built with hung task detection enabled and
> > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds,
> > snd_hdac_i915_init() will trigger the hung task timeout in case i915 is
> > not available and taint the kernel.
> >
> > Split the 60sec wait into a loop of smaller waits to avoid this.
> >
> > Reviewed-by: Lucas De Marchi
> > Co-developed-by: Ramalingam C
> > Signed-off-by: Ramalingam C
> > Signed-off-by: Kai Vehmanen
> > ---
> > sound/hda/hdac_i915.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > Changes V1->V2:
> > - address local variable naming issue raised by Amadeusz
> > and use Takashi's proposal
> >
> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> > index 454474ac5716..aa48bed7baf7 100644
> > --- a/sound/hda/hdac_i915.c
> > +++ b/sound/hda/hdac_i915.c
> > @@ -143,7 +143,7 @@ static bool i915_gfx_present(void)
> > int snd_hdac_i915_init(struct hdac_bus *bus)
> > {
> > struct drm_audio_component *acomp;
> > - int err;
> > + int err, i;
> > if (!i915_gfx_present())
> > return -ENODEV;
> > @@ -159,9 +159,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
> > if (!acomp->ops) {
> > if (!IS_ENABLED(CONFIG_MODULES) ||
> > !request_module("i915")) {
> > - /* 60s timeout */
>
> Where does this 60s come from and why is the fix to work around
> DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay?
The 60s timeout comes from the fact that the binding with i915 *might*
be mandatory for HD-audio driver on some platforms, while the binding
couldn't be achieved depending on the dynamic configuration change or
any other reasons, so we don't want to block forver. And, basically
the hung check is false-positive, and if there is a better way to mark
to skip the hung check, we'd take it. But currently this seems to be
the easiest workaround for avoiding the false-positive checks.
> For instance
> would limiting the wait here to whatever the kconfig is set to be an
> option?
No, the hunk task timeout can be changed dynamically via procfs, hence
the fixed Kconfig won't help at all.
Takashi
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
On 09/03/2022 08:39, Kai Vehmanen wrote: Hi, On Wed, 9 Mar 2022, Tvrtko Ursulin wrote: - /* 60s timeout */ Where does this 60s come from and why is the fix to work around DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would limiting the wait here to whatever the kconfig is set to be an option? this was discussed in https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html ... and that thread concluded it's cleaner to split the wait than try to figure out hung-task configuration from middle of audio driver. The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component bind timeout" to fix an issue reported by Paul Menzel (cc'ed). This patch keeps the timeout intact. I did not spot discussion touching on the point I raised. How about not fight the hung task detector but mark your wait context as "I really know what I'm doing - not stuck trust me". Maybe using wait_for_completion_killable_timeout would do it since snd_hdac_i915_init is allowed to fail with an error already? Regards, Tvrtko
[Intel-gfx] [PATCH] drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs
Commit ce2fce2513c5 ("drm/i915: Only include i915_reg.h from .c files")
moved GEN12_SFC_DONE_MAX from i915_regs.h to i915_reg_defs.h. Arguably
it belongs next to the GEN12_SFC_DONE() definition, as it describes the
number of GEN12_SFC_DONE instances.
The unfortunate downside is obviously having to pull in intel_gt_regs.h
in i915_gpu_error.h.
Cc: Matt Roper
Signed-off-by: Jani Nikula
---
I guess the alternative is to define GEN12_SFC_DONE_MAX in
i915_gpu_error.h, to avoid the extra include. No matter what, IMO it's
really out of place in i915_reg_defs.h.
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.h | 1 +
drivers/gpu/drm/i915/i915_reg_defs.h| 2 --
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 19cd34f24263..6bb987fe3289 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1502,5 +1502,6 @@
#define GEN12_CCS2_CCS3_INTR_MASK _MMIO(0x190104)
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+#define GEN12_SFC_DONE_MAX 4
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 903d838e2e63..d29155aca84c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -15,6 +15,7 @@
#include
#include "gt/intel_engine.h"
+#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
#include "gt/uc/intel_uc_fw.h"
diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
b/drivers/gpu/drm/i915/i915_reg_defs.h
index d78d78fce431..8f486f77609f 100644
--- a/drivers/gpu/drm/i915/i915_reg_defs.h
+++ b/drivers/gpu/drm/i915/i915_reg_defs.h
@@ -123,6 +123,4 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define VLV_DISPLAY_BASE 0x18
-#define GEN12_SFC_DONE_MAX 4
-
#endif /* __I915_REG_DEFS__ */
--
2.30.2
Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Clean up bxt/glk PLL registers
On Tue, 08 Mar 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Use REG_BIT() & co. for bxt/glk PLL registers. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 32 +- > drivers/gpu/drm/i915/gvt/handlers.c | 15 +++-- > drivers/gpu/drm/i915/i915_reg.h | 61 ++- > 3 files changed, 57 insertions(+), 51 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > index 4595795d694f..2a88c6fa1f34 100644 > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > @@ -1898,7 +1898,7 @@ static void bxt_ddi_pll_enable(struct drm_i915_private > *dev_priv, > > /* Write M2 integer */ > temp = intel_de_read(dev_priv, BXT_PORT_PLL(phy, ch, 0)); > - temp &= ~PORT_PLL_M2_MASK; > + temp &= ~PORT_PLL_M2_INT_MASK; > temp |= pll->state.hw_state.pll0; > intel_de_write(dev_priv, BXT_PORT_PLL(phy, ch, 0), temp); > > @@ -2034,7 +2034,7 @@ static bool bxt_ddi_pll_get_hw_state(struct > drm_i915_private *dev_priv, > hw_state->ebb4 &= PORT_PLL_10BIT_CLK_ENABLE; > > hw_state->pll0 = intel_de_read(dev_priv, BXT_PORT_PLL(phy, ch, 0)); > - hw_state->pll0 &= PORT_PLL_M2_MASK; > + hw_state->pll0 &= PORT_PLL_M2_INT_MASK; > > hw_state->pll1 = intel_de_read(dev_priv, BXT_PORT_PLL(phy, ch, 1)); > hw_state->pll1 &= PORT_PLL_N_MASK; > @@ -2200,23 +2200,23 @@ 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 = PORT_PLL_M2_INT(clk_div->m2_int); > dpll_hw_state->pll1 = PORT_PLL_N(clk_div->n); > - dpll_hw_state->pll2 = clk_div->m2_frac; > + dpll_hw_state->pll2 = PORT_PLL_M2_FRAC(clk_div->m2_frac); > > 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); > - dpll_hw_state->pll6 |= PORT_PLL_GAIN_CTL(gain_ctl); > + dpll_hw_state->pll6 = PORT_PLL_PROP_COEFF(prop_coef) | > + PORT_PLL_INT_COEFF(int_coef) | > + PORT_PLL_GAIN_CTL(gain_ctl); > > - dpll_hw_state->pll8 = targ_cnt; > + dpll_hw_state->pll8 = PORT_PLL_TARGET_CNT(targ_cnt); > > - dpll_hw_state->pll9 = 5 << PORT_PLL_LOCK_THRESHOLD_SHIFT; > + dpll_hw_state->pll9 = PORT_PLL_LOCK_THRESHOLD(5); > > - dpll_hw_state->pll10 = > - PORT_PLL_DCO_AMP(PORT_PLL_DCO_AMP_DEFAULT) > - | PORT_PLL_DCO_AMP_OVR_EN_H; > + dpll_hw_state->pll10 = PORT_PLL_DCO_AMP(15) | > + PORT_PLL_DCO_AMP_OVR_EN_H; > > dpll_hw_state->ebb4 = PORT_PLL_10BIT_CLK_ENABLE; > > @@ -2252,12 +2252,12 @@ static int bxt_ddi_pll_get_freq(struct > drm_i915_private *i915, > struct dpll clock; > > clock.m1 = 2; > - clock.m2 = (pll_state->pll0 & PORT_PLL_M2_MASK) << 22; > + clock.m2 = REG_FIELD_GET(PORT_PLL_M2_INT_MASK, pll_state->pll0) << 22; > if (pll_state->pll3 & PORT_PLL_M2_FRAC_ENABLE) > - clock.m2 |= pll_state->pll2 & PORT_PLL_M2_FRAC_MASK; > - clock.n = (pll_state->pll1 & PORT_PLL_N_MASK) >> PORT_PLL_N_SHIFT; > - clock.p1 = (pll_state->ebb0 & PORT_PLL_P1_MASK) >> PORT_PLL_P1_SHIFT; > - clock.p2 = (pll_state->ebb0 & PORT_PLL_P2_MASK) >> PORT_PLL_P2_SHIFT; > + clock.m2 |= REG_FIELD_GET(PORT_PLL_M2_FRAC_MASK, > pll_state->pll2); > + clock.n = REG_FIELD_GET(PORT_PLL_N_MASK, pll_state->pll1); > + clock.p1 = REG_FIELD_GET(PORT_PLL_P1_MASK, pll_state->ebb0); > + clock.p2 = REG_FIELD_GET(PORT_PLL_P2_MASK, pll_state->ebb0); > > return chv_calc_dpll_params(i915->dpll.ref_clks.nssc, &clock); > } > diff --git a/drivers/gpu/drm/i915/gvt/handlers.c > b/drivers/gpu/drm/i915/gvt/handlers.c > index efdd2f3f9d73..0ee3ecc83234 100644 > --- a/drivers/gpu/drm/i915/gvt/handlers.c > +++ b/drivers/gpu/drm/i915/gvt/handlers.c > @@ -576,12 +576,17 @@ static u32 bxt_vgpu_get_dp_bitrate(struct intel_vgpu > *vgpu, enum port port) > } > > clock.m1 = 2; > - clock.m2 = (vgpu_vreg_t(vgpu, BXT_PORT_PLL(phy, ch, 0)) & > PORT_PLL_M2_MASK) << 22; > + clock.m2 = REG_FIELD_GET(PORT_PLL_M2_INT_MASK, > + vgpu_vreg_t(vgpu, BXT_PORT_PLL(phy, ch, 0))) > << 22; > if (vgpu_vreg_t(vgpu, BXT_PORT_PLL(phy, ch, 3)) & > PORT_PLL_M2_FRAC_ENABLE) > - clock.m2 |= vgpu_vreg_t(vgpu, BXT_PORT_PLL(phy, ch, 2)) & > PORT_PLL_M2_FRAC_MASK; > - clock.n = (vgpu_vreg_t(vgpu, BXT_PORT_PLL(phy, ch, 1)) & > PORT_PLL_N_MASK) >> PORT_PLL_N_SHIFT; > - clock.p1 = (vgpu_vreg_t(vgpu, BXT_PORT_PLL_EBB_0(phy, ch)) & > PORT_PLL_P1_MASK) >> PORT_PLL_P1_SHIFT; > - clock.p2 = (vgpu
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
On Wed, 09 Mar 2022 10:02:13 +0100, Tvrtko Ursulin wrote: > > > On 09/03/2022 08:39, Kai Vehmanen wrote: > > Hi, > > > > On Wed, 9 Mar 2022, Tvrtko Ursulin wrote: > > > >>> - /* 60s timeout */ > >> > >> Where does this 60s come from and why is the fix to work around > >> DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would > >> limiting the wait here to whatever the kconfig is set to be an option? > > > > this was discussed in > > https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html > > ... and that thread concluded it's cleaner to split the wait than try > > to figure out hung-task configuration from middle of audio driver. > > > > The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component > > bind timeout" to fix an issue reported by Paul Menzel (cc'ed). > > > > This patch keeps the timeout intact. > > I did not spot discussion touching on the point I raised. > > How about not fight the hung task detector but mark your wait context > as "I really know what I'm doing - not stuck trust me". The question is how often this problem hits. Basically it's a very corner case, and I even think we may leave as is; that's a matter of configuration, and lowering such a bar should expect some side-effect. OTOH, if the problem happens in many cases, it's beneficial to fix in the core part, indeed. > Maybe using > wait_for_completion_killable_timeout would do it since > snd_hdac_i915_init is allowed to fail with an error already? It makes it killable -- which is a complete behavior change. Takashi
Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Store the m2 divider as a whole in bxt_clk_div
On Tue, 08 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.
>
> v2: Document the full divider as a proper decimal number
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 27 +--
> 1 file changed, 13 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 2a88c6fa1f34..ae3c07cc2eaa 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2088,8 +2088,7 @@ struct bxt_clk_div {
> int clock;
> u32 p1;
> u32 p2;
> - u32 m2_int;
> - u32 m2_frac;
> + u32 m2;
> u32 n;
>
> int vco;
> @@ -2097,13 +2096,14 @@ 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, },
> + /* m2 is .22 binary fixed point */
> + { .clock = 162000, .p1 = 4, .p2 = 2, .n = 1, .m2 = 0x81a /* 32.4 */
> },
> + { .clock = 27, .p1 = 4, .p2 = 1, .n = 1, .m2 = 0x6c0 /* 27.0 */
> },
> + { .clock = 54, .p1 = 2, .p2 = 1, .n = 1, .m2 = 0x6c0 /* 27.0 */
> },
> + { .clock = 216000, .p1 = 3, .p2 = 2, .n = 1, .m2 = 0x81a /* 32.4 */
> },
> + { .clock = 243000, .p1 = 4, .p2 = 1, .n = 1, .m2 = 0x613 /* 24.3 */
> },
> + { .clock = 324000, .p1 = 4, .p2 = 1, .n = 1, .m2 = 0x81a /* 32.4 */
> },
> + { .clock = 432000, .p1 = 3, .p2 = 1, .n = 1, .m2 = 0x81a /* 32.4 */
> },
> };
>
> static bool
> @@ -2130,8 +2130,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;
>
> @@ -2200,11 +2199,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 = PORT_PLL_M2_INT(clk_div->m2_int);
> + dpll_hw_state->pll0 = PORT_PLL_M2_INT(clk_div->m2 >> 22);
> dpll_hw_state->pll1 = PORT_PLL_N(clk_div->n);
> - dpll_hw_state->pll2 = PORT_PLL_M2_FRAC(clk_div->m2_frac);
> + dpll_hw_state->pll2 = PORT_PLL_M2_FRAC(clk_div->m2 & 0x3f);
>
> - if (clk_div->m2_frac)
> + if (clk_div->m2 & 0x3f)
> dpll_hw_state->pll3 = PORT_PLL_M2_FRAC_ENABLE;
>
> dpll_hw_state->pll6 = PORT_PLL_PROP_COEFF(prop_coef) |
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Populate bxt/glk DPLL clock limits a bit more
On Tue, 08 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Set the bxt/glk DPLL min dotclock to 25MHz (HDMI minimum)
> and the max to 594 MHz (HDMI max). The supported DP frequencies
> (162MHz-540MHz) fit within the same range.
>
> Signed-off-by: Ville Syrjälä
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
> b/drivers/gpu/drm/i915/display/intel_dpll.c
> index f4e5290b86a4..7377f1f009ba 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> @@ -285,8 +285,7 @@ static const struct intel_limit intel_limits_chv = {
> };
>
> static const struct intel_limit intel_limits_bxt = {
> - /* FIXME: find real dot limits */
> - .dot = { .min = 0, .max = INT_MAX },
> + .dot = { .min = 25000, .max = 594000 },
> .vco = { .min = 480, .max = 670 },
> .n = { .min = 1, .max = 1 },
> .m1 = { .min = 2, .max = 2 },
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 8/8] drm/i915: Remove struct dp_link_dpll
On Tue, 08 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> struct dp_link_dpll is a pointless wrapper around struct dpll.
> Just store the desired link rate into struct dpll::dot and
> we're done.
>
> v2: Document the full divider as a proper decimal number on chv
> Nuke bogus eDP 1.4 comments for chv while at it
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c | 55 +--
> 1 file changed, 17 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index 22345051e667..8e1338678d91 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -24,58 +24,37 @@
> #include "intel_pps.h"
> #include "vlv_sideband.h"
>
> -struct dp_link_dpll {
> - int clock;
> - struct dpll dpll;
> +static const struct dpll g4x_dpll[] = {
> + { .dot = 162000, .p1 = 2, .p2 = 10, .n = 2, .m1 = 23, .m2 = 8, },
> + { .dot = 27, .p1 = 1, .p2 = 10, .n = 1, .m1 = 14, .m2 = 2, },
> };
>
> -static const struct dp_link_dpll g4x_dpll[] = {
> - { 162000,
> - { .p1 = 2, .p2 = 10, .n = 2, .m1 = 23, .m2 = 8 } },
> - { 27,
> - { .p1 = 1, .p2 = 10, .n = 1, .m1 = 14, .m2 = 2 } }
> +static const struct dpll pch_dpll[] = {
> + { .dot = 162000, .p1 = 2, .p2 = 10, .n = 1, .m1 = 12, .m2 = 9, },
> + { .dot = 27, .p1 = 1, .p2 = 10, .n = 2, .m1 = 14, .m2 = 8, },
> };
>
> -static const struct dp_link_dpll pch_dpll[] = {
> - { 162000,
> - { .p1 = 2, .p2 = 10, .n = 1, .m1 = 12, .m2 = 9 } },
> - { 27,
> - { .p1 = 1, .p2 = 10, .n = 2, .m1 = 14, .m2 = 8 } }
> +static const struct dpll vlv_dpll[] = {
> + { .dot = 162000, .p1 = 3, .p2 = 2, .n = 5, .m1 = 3, .m2 = 81, },
> + { .dot = 27, .p1 = 2, .p2 = 2, .n = 1, .m1 = 2, .m2 = 27, },
> };
>
> -static const struct dp_link_dpll vlv_dpll[] = {
> - { 162000,
> - { .p1 = 3, .p2 = 2, .n = 5, .m1 = 3, .m2 = 81 } },
> - { 27,
> - { .p1 = 2, .p2 = 2, .n = 1, .m1 = 2, .m2 = 27 } }
> -};
> -
> -/*
> - * CHV supports eDP 1.4 that have more link rates.
> - * Below only provides the fixed rate but exclude variable rate.
> - */
> -static const struct dp_link_dpll chv_dpll[] = {
> - /*
> - * CHV requires to program fractional division for m2.
> - * m2 is stored in fixed point format using formula below
> - * (m2_int << 22) | m2_fraction
> - */
> - { 162000, /* m2_int = 32, m2_fraction = 1677722 */
> - { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
> - { 27, /* m2_int = 27, m2_fraction = 0 */
> - { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
> +static const struct dpll chv_dpll[] = {
> + /* m2 is .22 binary fixed point */
> + { .dot = 162000, .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a /*
> 32.4 */ },
> + { .dot = 27, .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 /*
> 27.0 */ },
> };
>
> const struct dpll *vlv_get_dpll(struct drm_i915_private *i915)
> {
> - return IS_CHERRYVIEW(i915) ? &chv_dpll[0].dpll : &vlv_dpll[0].dpll;
> + return IS_CHERRYVIEW(i915) ? &chv_dpll[0] : &vlv_dpll[0];
> }
>
> void g4x_dp_set_clock(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - const struct dp_link_dpll *divisor = NULL;
> + const struct dpll *divisor = NULL;
> int i, count = 0;
>
> if (IS_G4X(dev_priv)) {
> @@ -94,8 +73,8 @@ void g4x_dp_set_clock(struct intel_encoder *encoder,
>
> if (divisor && count) {
> for (i = 0; i < count; i++) {
> - if (pipe_config->port_clock == divisor[i].clock) {
> - pipe_config->dpll = divisor[i].dpll;
> + if (pipe_config->port_clock == divisor[i].dot) {
> + pipe_config->dpll = divisor[i];
> pipe_config->clock_set = true;
> break;
> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Replace hand rolled bxt vco calculation with chv_calc_dpll_params()
On Tue, 08 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use chv_calc_dpll_params() to calculate the BXT DP DPLL VCO
> frequency.
>
> We need to add the m1 divider into bxt_dp_clk_val[] for this to work.
>
> v2: Make the WARN_ON() sensible
>
> Signed-off-by: Ville Syrjälä
I admit I didn't check all the computations, but the drm_WARN_ON()
should catch any functional changes AFAICT.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 23 +++
> 1 file changed, 13 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 4b52086aa9e9..b7071da4b7e5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2086,13 +2086,13 @@ static bool bxt_ddi_pll_get_hw_state(struct
> drm_i915_private *dev_priv,
> /* pre-calculated values for DP linkrates */
> static const struct dpll bxt_dp_clk_val[] = {
> /* m2 is .22 binary fixed point */
> - { .dot = 162000, .p1 = 4, .p2 = 2, .n = 1, .m2 = 0x81a /* 32.4 */ },
> - { .dot = 27, .p1 = 4, .p2 = 1, .n = 1, .m2 = 0x6c0 /* 27.0 */ },
> - { .dot = 54, .p1 = 2, .p2 = 1, .n = 1, .m2 = 0x6c0 /* 27.0 */ },
> - { .dot = 216000, .p1 = 3, .p2 = 2, .n = 1, .m2 = 0x81a /* 32.4 */ },
> - { .dot = 243000, .p1 = 4, .p2 = 1, .n = 1, .m2 = 0x613 /* 24.3 */ },
> - { .dot = 324000, .p1 = 4, .p2 = 1, .n = 1, .m2 = 0x81a /* 32.4 */ },
> - { .dot = 432000, .p1 = 3, .p2 = 1, .n = 1, .m2 = 0x81a /* 32.4 */ },
> + { .dot = 162000, .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a /*
> 32.4 */ },
> + { .dot = 27, .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 /*
> 27.0 */ },
> + { .dot = 54, .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 /*
> 27.0 */ },
> + { .dot = 216000, .p1 = 3, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a /*
> 32.4 */ },
> + { .dot = 243000, .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x613 /*
> 24.3 */ },
> + { .dot = 324000, .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x81a /*
> 32.4 */ },
> + { .dot = 432000, .p1 = 3, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x81a /*
> 32.4 */ },
> };
>
> static bool
> @@ -2122,18 +2122,21 @@ bxt_ddi_hdmi_pll_dividers(struct intel_crtc_state
> *crtc_state,
> static void bxt_ddi_dp_pll_dividers(struct intel_crtc_state *crtc_state,
> struct dpll *clk_div)
> {
> - int clock = crtc_state->port_clock;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> 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].dot == clock) {
> + if (crtc_state->port_clock == bxt_dp_clk_val[i].dot) {
> *clk_div = bxt_dp_clk_val[i];
> break;
> }
> }
>
> - clk_div->vco = clock * 10 / 2 * clk_div->p1 * clk_div->p2;
> + chv_calc_dpll_params(i915->dpll.ref_clks.nssc, clk_div);
> +
> + drm_WARN_ON(&i915->drm, clk_div->vco == 0 ||
> + clk_div->dot != crtc_state->port_clock);
> }
>
> static bool bxt_ddi_set_dpll_hw_state(struct intel_crtc_state *crtc_state,
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
On 09/03/2022 09:23, Takashi Iwai wrote: On Wed, 09 Mar 2022 10:02:13 +0100, Tvrtko Ursulin wrote: On 09/03/2022 08:39, Kai Vehmanen wrote: Hi, On Wed, 9 Mar 2022, Tvrtko Ursulin wrote: - /* 60s timeout */ Where does this 60s come from and why is the fix to work around DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would limiting the wait here to whatever the kconfig is set to be an option? this was discussed in https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html ... and that thread concluded it's cleaner to split the wait than try to figure out hung-task configuration from middle of audio driver. The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component bind timeout" to fix an issue reported by Paul Menzel (cc'ed). This patch keeps the timeout intact. I did not spot discussion touching on the point I raised. How about not fight the hung task detector but mark your wait context as "I really know what I'm doing - not stuck trust me". The question is how often this problem hits. Basically it's a very corner case, and I even think we may leave as is; that's a matter of configuration, and lowering such a bar should expect some side-effect. OTOH, if the problem happens in many cases, it's beneficial to fix in the core part, indeed. Yes argument you raise can be made I agree. Maybe using wait_for_completion_killable_timeout would do it since snd_hdac_i915_init is allowed to fail with an error already? It makes it killable -- which is a complete behavior change. Complete behaviour change how? Isn't this something ran on probe so likelihood of anyone sending SIGKILL to the modprobe process is only the init process? And in that case what is the fundamental difference in init giving up before the internal 60s in HDA driver does? I don't see a difference. Either party decided to abort the wait and code can just unwind and propagate the different error codes. Regards, Tvrtko
Re: [Intel-gfx] [PATCH] drm/i915/dpll: make read-only array div1_vals static const
On Mon, 07 Mar 2022, Colin Ian King wrote:
> Don't populate the read-only array div1_vals on the stack but
> instead make it static const. Also makes the object code a little
> smaller.
Thanks, but this was just fixed in commit fe70b262e781 ("drm/i915: Move
a bunch of stuff into rodata from the stack").
BR,
Jani.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 569903d47aea..17668b58b30c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2759,7 +2759,7 @@ static bool icl_mg_pll_find_divisors(int clock_khz,
> bool is_dp, bool use_ssc,
>bool is_dkl)
> {
> u32 dco_min_freq, dco_max_freq;
> - int div1_vals[] = {7, 5, 3, 2};
> + static const int div1_vals[] = {7, 5, 3, 2};
> unsigned int i;
> int div2;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Remove redundant/wrong comments
On Tue, 08 Mar 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Remove the comment specifying the exact formulat for calculating > the DPLL frequency from the *_find_best_dpll() functions. Each > platform variant has its own way to calculate these and we have > the code already to do that. These comments are entirely redundant > and often even wrong so just get rid of them. > > Signed-off-by: Ville Syrjälä Acked-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_dpll.c | 15 +-- > 1 file changed, 5 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c > b/drivers/gpu/drm/i915/display/intel_dpll.c > index b3fd94538c44..f4e5290b86a4 100644 > --- a/drivers/gpu/drm/i915/display/intel_dpll.c > +++ b/drivers/gpu/drm/i915/display/intel_dpll.c > @@ -425,8 +425,7 @@ i9xx_select_p2_div(const struct intel_limit *limit, > > /* > * Returns a set of divisors for the desired target clock with the given > - * refclk, or FALSE. The returned values represent the clock equation: > - * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2. > + * refclk, or FALSE. > * > * Target and reference clocks are specified in kHz. > * > @@ -484,8 +483,7 @@ i9xx_find_best_dpll(const struct intel_limit *limit, > > /* > * Returns a set of divisors for the desired target clock with the given > - * refclk, or FALSE. The returned values represent the clock equation: > - * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2. > + * refclk, or FALSE. > * > * Target and reference clocks are specified in kHz. > * > @@ -541,8 +539,7 @@ pnv_find_best_dpll(const struct intel_limit *limit, > > /* > * Returns a set of divisors for the desired target clock with the given > - * refclk, or FALSE. The returned values represent the clock equation: > - * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2. > + * refclk, or FALSE. > * > * Target and reference clocks are specified in kHz. > * > @@ -641,8 +638,7 @@ static bool vlv_PLL_is_optimal(struct drm_device *dev, > int target_freq, > > /* > * Returns a set of divisors for the desired target clock with the given > - * refclk, or FALSE. The returned values represent the clock equation: > - * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2. > + * refclk, or FALSE. > */ > static bool > vlv_find_best_dpll(const struct intel_limit *limit, > @@ -700,8 +696,7 @@ vlv_find_best_dpll(const struct intel_limit *limit, > > /* > * Returns a set of divisors for the desired target clock with the given > - * refclk, or FALSE. The returned values represent the clock equation: > - * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2. > + * refclk, or FALSE. > */ > static bool > chv_find_best_dpll(const struct intel_limit *limit, -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Store the /5 target clock in struct dpll on vlv/chv
On Tue, 08 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Unify vlv/chv with earlier platforms so that the sturct dpll::dot
> represents the /5 clock frequency (ie. DP symbol rate or HDMI
> TMDS rate) rather than the *5 fast clock (/2 of the bitrate).
> Makes life a little less confusing to get the same number back
> in .dot which we fed into the DPLL algorithm.
>
> v2: Actually just include the 5x in the final P divider
> Do the same change to the hand rolled gvt code
>
> Signed-off-by: Ville Syrjälä
For some reason it was really hard for me to convince myself that I'd
checked every code path for the right amount of *5 and /5 in the right
places... I'll just say I didn't spot anything obviously wrong
here. Fingers crossed.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll.c | 19 ---
> drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> 2 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
> b/drivers/gpu/drm/i915/display/intel_dpll.c
> index 0ae37fdbf2a5..b3fd94538c44 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> @@ -254,12 +254,12 @@ static const struct intel_limit
> ilk_limits_dual_lvds_100m = {
>
> static const struct intel_limit intel_limits_vlv = {
>/*
> - * These are the data rate limits (measured in fast clocks)
> + * These are based on the data rate limits (measured in fast clocks)
> * since those are the strictest limits we have. The fast
> * clock and actual rate limits are more relaxed, so checking
> * them would make no difference.
> */
> - .dot = { .min = 25000 * 5, .max = 27 * 5 },
> + .dot = { .min = 25000, .max = 27 },
> .vco = { .min = 400, .max = 600 },
> .n = { .min = 1, .max = 7 },
> .m1 = { .min = 2, .max = 3 },
> @@ -270,12 +270,12 @@ static const struct intel_limit intel_limits_vlv = {
>
> static const struct intel_limit intel_limits_chv = {
> /*
> - * These are the data rate limits (measured in fast clocks)
> + * These are based on the data rate limits (measured in fast clocks)
>* since those are the strictest limits we have. The fast
>* clock and actual rate limits are more relaxed, so checking
>* them would make no difference.
>*/
> - .dot = { .min = 25000 * 5, .max = 54 * 5},
> + .dot = { .min = 25000, .max = 54 },
> .vco = { .min = 480, .max = 648 },
> .n = { .min = 1, .max = 1 },
> .m1 = { .min = 2, .max = 2 },
> @@ -337,26 +337,26 @@ int i9xx_calc_dpll_params(int refclk, struct dpll
> *clock)
> int vlv_calc_dpll_params(int refclk, struct dpll *clock)
> {
> clock->m = clock->m1 * clock->m2;
> - clock->p = clock->p1 * clock->p2;
> + clock->p = clock->p1 * clock->p2 * 5;
> if (WARN_ON(clock->n == 0 || clock->p == 0))
> return 0;
> clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
>
> - return clock->dot / 5;
> + return clock->dot;
> }
>
> int chv_calc_dpll_params(int refclk, struct dpll *clock)
> {
> clock->m = clock->m1 * clock->m2;
> - clock->p = clock->p1 * clock->p2;
> + clock->p = clock->p1 * clock->p2 * 5;
> if (WARN_ON(clock->n == 0 || clock->p == 0))
> return 0;
> clock->vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock->m),
> clock->n << 22);
> clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
>
> - return clock->dot / 5;
> + return clock->dot;
> }
>
> /*
> @@ -659,8 +659,6 @@ vlv_find_best_dpll(const struct intel_limit *limit,
> int max_n = min(limit->n.max, refclk / 19200);
> bool found = false;
>
> - target *= 5; /* fast clock */
> -
> memset(best_clock, 0, sizeof(*best_clock));
>
> /* based on hardware requirement, prefer smaller n to precision */
> @@ -729,7 +727,6 @@ chv_find_best_dpll(const struct intel_limit *limit,
>*/
> clock.n = 1;
> clock.m1 = 2;
> - target *= 5;/* fast clock */
>
> for (clock.p1 = limit->p1.max; clock.p1 >= limit->p1.min; clock.p1--) {
> for (clock.p2 = limit->p2.p2_fast;
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 520a7e1942f3..efdd2f3f9d73 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -583,7 +583,7 @@ static u32 bxt_vgpu_get_dp_bitrate(struct intel_vgpu
> *vgpu, enum port port)
> clock.p1 = (vgpu_vreg_t(vgpu, BXT_PORT_PLL_EBB_0(phy, ch)) &
> PORT_PLL_P1_MASK) >> PORT_PLL_P1_SHIFT;
> clock.p2 = (vgpu_vreg_t(vgpu, BXT_PORT_PLL_EBB_0(phy, ch)) &
> PORT_PLL_P2_MASK) >> PORT_PLL_P2_SHIFT;
> clock.m = clock.m1 * clock.m2;
> -
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
On Wed, 09 Mar 2022 10:48:49 +0100, Tvrtko Ursulin wrote: > > > On 09/03/2022 09:23, Takashi Iwai wrote: > > On Wed, 09 Mar 2022 10:02:13 +0100, > > Tvrtko Ursulin wrote: > >> > >> > >> On 09/03/2022 08:39, Kai Vehmanen wrote: > >>> Hi, > >>> > >>> On Wed, 9 Mar 2022, Tvrtko Ursulin wrote: > >>> > > - /* 60s timeout */ > > Where does this 60s come from and why is the fix to work around > DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would > limiting the wait here to whatever the kconfig is set to be an option? > >>> > >>> this was discussed in > >>> https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html > >>> ... and that thread concluded it's cleaner to split the wait than try > >>> to figure out hung-task configuration from middle of audio driver. > >>> > >>> The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component > >>> bind timeout" to fix an issue reported by Paul Menzel (cc'ed). > >>> > >>> This patch keeps the timeout intact. > >> > >> I did not spot discussion touching on the point I raised. > >> > >> How about not fight the hung task detector but mark your wait context > >> as "I really know what I'm doing - not stuck trust me". > > > > The question is how often this problem hits. Basically it's a very > > corner case, and I even think we may leave as is; that's a matter of > > configuration, and lowering such a bar should expect some > > side-effect. OTOH, if the problem happens in many cases, it's > > beneficial to fix in the core part, indeed. > > Yes argument you raise can be made I agree. > > >> Maybe using > >> wait_for_completion_killable_timeout would do it since > >> snd_hdac_i915_init is allowed to fail with an error already? > > > > It makes it killable -- which is a complete behavior change. > > Complete behaviour change how? Isn't this something ran on probe so > likelihood of anyone sending SIGKILL to the modprobe process is only > the init process? And in that case what is the fundamental difference > in init giving up before the internal 60s in HDA driver does? I don't > see a difference. Either party decided to abort the wait and code can > just unwind and propagate the different error codes. The point is that it does change the actual behavior, and changing the actual behavior just for working around the corner case like the above wouldn't be justified without the proper evaluation. That said, if this behavior change is intentional and even desired, that's a way to go. Takashi
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: check before removing mm notifier
== Series Details ==
Series: drm/i915: check before removing mm notifier
URL : https://patchwork.freedesktop.org/series/101170/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11338_full -> Patchwork_22516_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22516_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22516_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_22516_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic:
- shard-kbl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-kbl6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-kbl1/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_param@basic-default:
- {shard-dg1}:NOTRUN -> [SKIP][3] +34 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@gem_ctx_pa...@basic-default.html
* igt@gem_exec_balancer@parallel-out-fence:
- {shard-dg1}:[DMESG-WARN][4] ([i915#5076]) -> [SKIP][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-dg1-13/igt@gem_exec_balan...@parallel-out-fence.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_reloc@basic-gtt-wc-active:
- {shard-dg1}:[SKIP][6] ([i915#3281]) -> [SKIP][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-dg1-13/igt@gem_exec_re...@basic-gtt-wc-active.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@gem_exec_re...@basic-gtt-wc-active.html
* igt@gem_workarounds@basic-read-context:
- {shard-dg1}:[SKIP][8] ([i915#4873]) -> [SKIP][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-dg1-13/igt@gem_workarou...@basic-read-context.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@gem_workarou...@basic-read-context.html
* igt@kms_big_fb@y-tiled-8bpp-rotate-0:
- {shard-dg1}:NOTRUN -> [FAIL][10] +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@kms_big...@y-tiled-8bpp-rotate-0.html
* igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs:
- {shard-dg1}:[PASS][11] -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-dg1-13/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs.html
* {igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a}:
- shard-skl: [PASS][13] -> [FAIL][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-skl10/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-edp-1-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-skl5/igt@kms_hdr@bpc-switch-susp...@bpc-switch-suspend-edp-1-pipe-a.html
* igt@perf@polling-small-buf:
- {shard-dg1}:[PASS][15] -> [SKIP][16] +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-dg1-13/igt@p...@polling-small-buf.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/shard-dg1-18/igt@p...@polling-small-buf.html
### Piglit changes ###
Possible regressions
* spec@ext_transform_feedback@query-primitives_written-bufferbase-discard:
- pig-kbl-iris: NOTRUN -> [INCOMPLETE][17]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22516/pig-kbl-iris/spec@ext_transform_feedback@query-primitives_written-bufferbase-discard.html
New tests
-
New tests have been introduced between CI_DRM_11338_full and
Patchwork_22516_full:
### New IGT tests (66) ###
* igt@dmabuf@all@dma_fence:
- Statuses : 10 pass(s)
- Exec time: [0.13, 0.21] s
* igt@dmabuf@all@sanitycheck:
- Statuses : 10 pass(s)
- Exec time: [0.02, 0.07] s
* igt@gem_render_copy@mixed-tiled-to-yf-tiled-ccs:
- Statuses :
- Exec time: [None] s
* igt@gem_render_copy@y-tiled-ccs-to-x-tiled:
- Statuses :
- Exec tim
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Remove leftover cnl SAGV block time
On Tue, 2022-03-08 at 19:32 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> GLK doesn't support SAGV, so with CNL gone there is no
> use for having a DISPLAY_VER==10 SAGV block time in the code.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Vinod Govindapillai
> ---
> drivers/gpu/drm/i915/intel_pm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f70eb10ab24d..8ee31c9590a7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3689,9 +3689,6 @@ skl_setup_sagv_block_time(struct drm_i915_private
> *dev_priv)
> } else if (DISPLAY_VER(dev_priv) == 11) {
> dev_priv->sagv_block_time_us = 10;
> return;
> - } else if (DISPLAY_VER(dev_priv) == 10) {
> - dev_priv->sagv_block_time_us = 20;
> - return;
> } else if (DISPLAY_VER(dev_priv) == 9) {
> dev_priv->sagv_block_time_us = 30;
> return;
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Rework SAGV block time probing
On Tue, 2022-03-08 at 19:32 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I'd like to see the SAGV block time we got from the mailbox
> in the logs regardless of whether other factors prevent the
> use of SAGV.
>
> So let's adjust the code to always query the SAGV block time,
> log it, and then reset it if SAGV is not actually supported.
>
> Signed-off-by: Ville Syrjälä
Hi Ville,
I wonder if it is better to comprehend if we clean assigning -1 to a u32
variable first before
this? I see that you are doing that anyway in the next patch in this series.
Was there any
particular reason?
BR
Vinod
> ---
> drivers/gpu/drm/i915/intel_pm.c | 38 +++--
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8ee31c9590a7..21c37115c36e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3670,8 +3670,8 @@ intel_has_sagv(struct drm_i915_private *dev_priv)
> dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
> }
>
> -static void
> -skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
> +static u32
> +intel_sagv_block_time(struct drm_i915_private *dev_priv)
> {
> if (DISPLAY_VER(dev_priv) >= 12) {
> u32 val = 0;
> @@ -3680,24 +3680,31 @@ skl_setup_sagv_block_time(struct drm_i915_private
> *dev_priv)
> ret = snb_pcode_read(dev_priv,
>GEN12_PCODE_READ_SAGV_BLOCK_TIME_US,
>&val, NULL);
> - if (!ret) {
> - dev_priv->sagv_block_time_us = val;
> - return;
> + if (ret) {
> + drm_dbg_kms(&dev_priv->drm, "Couldn't read SAGV block
> time!\n");
> + return -1;
> }
>
> - drm_dbg(&dev_priv->drm, "Couldn't read SAGV block time!\n");
> + return val;
> } else if (DISPLAY_VER(dev_priv) == 11) {
> - dev_priv->sagv_block_time_us = 10;
> - return;
> - } else if (DISPLAY_VER(dev_priv) == 9) {
> - dev_priv->sagv_block_time_us = 30;
> - return;
> + return 10;
> + } else if (DISPLAY_VER(dev_priv) == 9 && !IS_LP(dev_priv)) {
> + return 30;
> } else {
> - MISSING_CASE(DISPLAY_VER(dev_priv));
> + /* Default to an unusable block time */
> + return -1;
> }
> +}
>
> - /* Default to an unusable block time */
> - dev_priv->sagv_block_time_us = -1;
> +static void intel_sagv_init(struct drm_i915_private *i915)
> +{
> + i915->sagv_block_time_us = intel_sagv_block_time(i915);
> +
> + drm_dbg_kms(&i915->drm, "SAGV supported: %s, original SAGV block time:
> %u us\n",
> + str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us);
> +
> + if (!intel_has_sagv(i915))
> + i915->sagv_block_time_us = -1;
> }
>
> /*
> @@ -8173,8 +8180,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
> else if (GRAPHICS_VER(dev_priv) == 5)
> ilk_get_mem_freq(dev_priv);
>
> - if (intel_has_sagv(dev_priv))
> - skl_setup_sagv_block_time(dev_priv);
> + intel_sagv_init(dev_priv);
>
> /* For FIFO watermark updates */
> if (DISPLAY_VER(dev_priv) >= 9) {
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: SAGV block time fixes
== Series Details ==
Series: drm/i915: SAGV block time fixes
URL : https://patchwork.freedesktop.org/series/101171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11338_full -> Patchwork_22517_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_22517_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_11338/shard-dg1-13/igt@api_intel_alloca...@fork-simple-stress-signal.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22517/shard-dg1-13/igt@api_intel_alloca...@fork-simple-stress-signal.html
* igt@kms_cursor_legacy@all-pipes-forked-bo:
- {shard-rkl}:([PASS][3], [PASS][4]) -> ([INCOMPLETE][5], [PASS][6])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-rkl-4/igt@kms_cursor_leg...@all-pipes-forked-bo.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-rkl-5/igt@kms_cursor_leg...@all-pipes-forked-bo.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22517/shard-rkl-5/igt@kms_cursor_leg...@all-pipes-forked-bo.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22517/shard-rkl-4/igt@kms_cursor_leg...@all-pipes-forked-bo.html
* {igt@kms_hdr@bpc-switch-dpms@bpc-switch-dpms-edp-1-pipe-a}:
- shard-skl: [PASS][7] -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11338/shard-skl8/igt@kms_hdr@bpc-switch-d...@bpc-switch-dpms-edp-1-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22517/shard-skl7/igt@kms_hdr@bpc-switch-d...@bpc-switch-dpms-edp-1-pipe-a.html
* igt@kms_hdr@static-toggle:
- {shard-dg1}:NOTRUN -> [SKIP][9] +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22517/shard-dg1-17/igt@kms_...@static-toggle.html
*
{igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-edp-1-planes-upscale-downscale}:
- {shard-rkl}:NOTRUN -> [SKIP][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22517/shard-rkl-6/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-b-edp-1-planes-upscale-downscale.html
New tests
-
New tests have been introduced between CI_DRM_11338_full and
Patchwork_22517_full:
### New IGT tests (20) ###
* igt@gem_ctx_persistence@saturated-hostile:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@gem_render_copy@mixed-tiled-to-yf-tiled-ccs:
- Statuses :
- Exec time: [None] s
* igt@i915_selftest@perf:
- Statuses :
- Exec time: [None] s
*
igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-5@pipe-a-edp-1-downscale-with-pixel-format:
- Statuses : 1 pass(s) 2 skip(s)
- Exec time: [0.01, 30.11] s
*
igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-5@pipe-b-edp-1-downscale-with-pixel-format:
- Statuses : 1 pass(s) 2 skip(s)
- Exec time: [0.02, 29.96] s
* igt@kms_plane_scaling@downscale-with-rotation-factor-0-25:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
*
igt@kms_plane_scaling@downscale-with-rotation-factor-0-75@pipe-a-edp-1-downscale-with-rotation:
- Statuses : 3 skip(s)
- Exec time: [0.94, 5.04] s
*
igt@kms_plane_scaling@downscale-with-rotation-factor-0-75@pipe-b-edp-1-downscale-with-rotation:
- Statuses : 3 skip(s)
- Exec time: [1.97, 5.24] s
*
igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale:
- Statuses : 2 pass(s)
- Exec time: [1.43, 1.45] s
*
igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-b-edp-1-planes-downscale:
- Statuses : 2 pass(s)
- Exec time: [1.27, 1.33] s
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-25:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-a-edp-1-planes-upscale-downscale:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [1.34, 1.54] s
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1-planes-upscale-downscale:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.30, 1.28] s
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a-edp-1-planes-upscale-downscale:
- Statuses : 3 pass(s)
- Exec time: [0.13, 1.71] s
*
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-b-edp-1-planes-upscale-downscale:
- Statuses : 3 pass(s)
- Exec time: [1.23, 1.58] s
*
igt@kms_plan
Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write
Hi,
can we have ack? or we need to do anything further to get r-o-b.
Thanks,
Mastan
-Original Message-
From: Katragadda, MastanX
Sent: 09 March 2022 07:16
To: Auld, Matthew ; Tvrtko Ursulin
; intel-gfx@lists.freedesktop.org
Cc: Surendrakumar Upadhyay, TejaskumarX
Subject: RE: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access
leads to OOB read/write
On 03/03/2022 09:00, Tvrtko Ursulin wrote:
>
> + Matt
>
> On 03/03/2022 06:04, Mastan Katragadda wrote:
>> Intel ID: PSIRT-PTK0002429
>>
>> A missing bounds check in vm_access()can lead to an out-of-bounds
>> read or write in the adjacent memory area.The len attribute is not
>> validated before the memcpy at [1]or [2] occurs.
>
> s/[1]or [2]/later in the function/ ?
>
>>
>> [ 183.637831] BUG: unable to handle page fault for address:
>> c9c86000
>> [ 183.637934] #PF: supervisor read access in kernel mode [
>> 183.637997] #PF: error_code(0x) - not-present page [ 183.638059]
>> PGD 10067 P4D 10067 PUD 100258067 PMD 106341067 PTE 0 [
>> 183.638144] Oops: [#2] PREEMPT SMP NOPTI
>> [ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D
>> 5.17.0-rc6-ci-drm-11296+ #1
>> [ 183.638298] Hardware name: Intel Corporation CoffeeLake Client
>> Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319
>> 05/30/2019
>> [ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 [ 183.640213] RSP:
>> 0018:c90001763d48 EFLAGS: 00010246 [ 183.641117] RAX:
>> 888109c14000 RBX: 888111bece40 RCX:
>> 0ffc
>> [ 183.642029] RDX: 1000 RSI: c9c86000 RDI:
>> 888109c14004
>> [ 183.642946] RBP: 0ffc R08: 816b R09:
>>
>> [ 183.643848] R10: c9c85000 R11: 0048 R12:
>> 1000
>> [ 183.644742] R13: 888111bed190 R14: 888109c14000 R15:
>> 1000
>> [ 183.645653] FS: 7fe5ef807540() GS:88845b38()
>> knlGS:
>> [ 183.646570] CS: 0010 DS: ES: CR0: 80050033 [
>> 183.647481] CR2: c9c86000 CR3: 00010ff02006 CR4:
>> 003706e0
>> [ 183.648384] DR0: DR1: DR2:
>>
>> [ 183.649271] DR3: DR6: fffe0ff0 DR7:
>> 0400
>> [ 183.650142] Call Trace:
>> [ 183.650988]
>> [ 183.651793] vm_access+0x1f0/0x2a0 [i915] [ 183.652726]
>> __access_remote_vm+0x224/0x380 [ 183.653561]
>> mem_rw.isra.0+0xf9/0x190 [ 183.654402] vfs_read+0x9d/0x1b0 [
>> 183.655238] ksys_read+0x63/0xe0 [ 183.656065]
>> do_syscall_64+0x38/0xc0 [ 183.656882]
>> entry_SYSCALL_64_after_hwframe+0x44/0xae
>> [ 183.657663] RIP: 0033:0x7fe5ef725142 [ 183.659351] RSP:
>> 002b:7ffe1e81c7e8 EFLAGS: 0246 ORIG_RAX:
>>
>> [ 183.660227] RAX: ffda RBX: 557055dfb780 RCX:
>> 7fe5ef725142
>> [ 183.661104] RDX: 1000 RSI: 7ffe1e81d880 RDI:
>> 0005
>> [ 183.661972] RBP: 7ffe1e81e890 R08: 0030 R09:
>> 0046
>> [ 183.662832] R10: 557055dfc2e0 R11: 0246 R12:
>> 557055dfb1c0
>> [ 183.663691] R13: 7ffe1e81e980 R14: R15:
>>
>> [ 183.664566]
>>
>> Changes since v1:
>> - Updated if condition with range_overflows_t [Chris Wilson]
>>
>> Signed-off-by: Mastan Katragadda
>> Suggested-by: Adam Zabrocki
>> Reported-by: Jackson Cody
>> Cc: Chris Wilson
>> Cc: Bloomfield Jon
>> Cc: Dutt Sudeep
>
> Fixes: 9f909e215fea ("drm/i915: Implement vm_ops->access for gdb
> access into mmaps")
> Cc: # v5.8+
>
> Right?
>
> There was a selftest added with the referenced patch and it sounds
> like it would be a good idea to extend it to cover this scenario. As
> a separate patch though so this one is easy to backport.
Agreed, a simple regression test(either selftest or igt) for this would be
nice, if possible.
>
> Regards,
>
> Tvrtko
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index efe69d6b86f4..c3ea243d414d 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -455,7 +455,7 @@ vm_access(struct vm_area_struct *area, unsigned
>> long addr,
>> return -EACCES;
>> addr -= area->vm_start;
>> - if (addr >= obj->base.size)
>> + if (range_overflows_t(u64, addr, len, obj->base.size))
>> return -EINVAL;
Other users like ttm_bo_vm_access are also checking if len <= 0, should we also
add an explicit check for that here? Otherwise LGTM.
I think no need to add here len<=0, we already validating same
range_overflows_t . converted following condition to range_overflow_t.
if (len < 1 || len > obj->base.size ||
addr >= obj->ba
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Treat SAGV block time 0 as SAGV disabled
On Tue, 2022-03-08 at 19:32 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For modern platforms the spec explicitly states that a
> SAGV block time of zero means that SAGV is not supported.
> Let's extend that to all platforms. Supposedly there should
> be no systems where this isn't true, and it'll allow us to:
> - use the same code regardless of older vs. newer platform
> - wm latencies already treat 0 as disabled, so this fits well
> with other related code
> - make it a bit more clear when SAGV is used vs. not
> - avoid overflows from adding U32_MAX with a u16 wm0 latency value
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 21c37115c36e..906501d6b298 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3682,7 +3682,7 @@ intel_sagv_block_time(struct drm_i915_private *dev_priv)
>&val, NULL);
> if (ret) {
> drm_dbg_kms(&dev_priv->drm, "Couldn't read SAGV block
> time!\n");
> - return -1;
> + return 0;
> }
>
> return val;
> @@ -3691,8 +3691,7 @@ intel_sagv_block_time(struct drm_i915_private *dev_priv)
> } else if (DISPLAY_VER(dev_priv) == 9 && !IS_LP(dev_priv)) {
> return 30;
> } else {
> - /* Default to an unusable block time */
> - return -1;
> + return 0;
> }
> }
>
> @@ -3704,7 +3703,7 @@ static void intel_sagv_init(struct drm_i915_private
> *i915)
> str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us);
>
> if (!intel_has_sagv(i915))
> - i915->sagv_block_time_us = -1;
> + i915->sagv_block_time_us = 0;
Hi Ville
Currently we set the "sagv_status" as "I915_SAGV_NOT_CONTROLLED" based on the
number of qgv points.
So here i915->sagv_block_time_us will be set to 0 even if
intel_sagv_block_time(i915) would have
returned some valid values. Is that the desired behavior for sgav watermarks
calcultations?
BR
vinod
> }
>
> /*
> @@ -5651,7 +5650,7 @@ static void skl_compute_plane_wm(const struct
> intel_crtc_state *crtc_state,
> result->min_ddb_alloc = max(min_ddb_alloc, blocks) + 1;
> result->enable = true;
>
> - if (DISPLAY_VER(dev_priv) < 12)
> + if (DISPLAY_VER(dev_priv) < 12 && dev_priv->sagv_block_time_us)
> result->can_sagv = latency >= dev_priv->sagv_block_time_us;
> }
>
> @@ -5684,7 +5683,10 @@ static void tgl_compute_sagv_wm(const struct
> intel_crtc_state *crtc_state,
> struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> struct skl_wm_level *sagv_wm = &plane_wm->sagv.wm0;
> struct skl_wm_level *levels = plane_wm->wm;
> - unsigned int latency = dev_priv->wm.skl_latency[0] +
> dev_priv->sagv_block_time_us;
> + unsigned int latency = 0;
> +
> + if (dev_priv->sagv_block_time_us)
> + latency = dev_priv->sagv_block_time_us +
> dev_priv->wm.skl_latency[0];
>
> skl_compute_plane_wm(crtc_state, plane, 0, latency,
>wm_params, &levels[0],
Re: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access leads to OOB read/write
On 09/03/2022 11:19, Katragadda, MastanX wrote:
Hi,
can we have ack? or we need to do anything further to get r-o-b.
There was just the potential strangeness around len <= 0, and exactly
how we are meant to handle that, but if you are confident that is
already covered in a sane way, then feel free to add,
Reviewed-by: Matthew Auld
Thanks,
Mastan
-Original Message-
From: Katragadda, MastanX
Sent: 09 March 2022 07:16
To: Auld, Matthew ; Tvrtko Ursulin
; intel-gfx@lists.freedesktop.org
Cc: Surendrakumar Upadhyay, TejaskumarX
Subject: RE: [Intel-gfx] [v2] drm/i915/gem: missing boundary check in vm_access
leads to OOB read/write
On 03/03/2022 09:00, Tvrtko Ursulin wrote:
+ Matt
On 03/03/2022 06:04, Mastan Katragadda wrote:
Intel ID: PSIRT-PTK0002429
A missing bounds check in vm_access()can lead to an out-of-bounds
read or write in the adjacent memory area.The len attribute is not
validated before the memcpy at [1]or [2] occurs.
s/[1]or [2]/later in the function/ ?
[ 183.637831] BUG: unable to handle page fault for address:
c9c86000
[ 183.637934] #PF: supervisor read access in kernel mode [
183.637997] #PF: error_code(0x) - not-present page [ 183.638059]
PGD 10067 P4D 10067 PUD 100258067 PMD 106341067 PTE 0 [
183.638144] Oops: [#2] PREEMPT SMP NOPTI
[ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D
5.17.0-rc6-ci-drm-11296+ #1
[ 183.638298] Hardware name: Intel Corporation CoffeeLake Client
Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319
05/30/2019
[ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 [ 183.640213] RSP:
0018:c90001763d48 EFLAGS: 00010246 [ 183.641117] RAX:
888109c14000 RBX: 888111bece40 RCX:
0ffc
[ 183.642029] RDX: 1000 RSI: c9c86000 RDI:
888109c14004
[ 183.642946] RBP: 0ffc R08: 816b R09:
[ 183.643848] R10: c9c85000 R11: 0048 R12:
1000
[ 183.644742] R13: 888111bed190 R14: 888109c14000 R15:
1000
[ 183.645653] FS: 7fe5ef807540() GS:88845b38()
knlGS:
[ 183.646570] CS: 0010 DS: ES: CR0: 80050033 [
183.647481] CR2: c9c86000 CR3: 00010ff02006 CR4:
003706e0
[ 183.648384] DR0: DR1: DR2:
[ 183.649271] DR3: DR6: fffe0ff0 DR7:
0400
[ 183.650142] Call Trace:
[ 183.650988]
[ 183.651793] vm_access+0x1f0/0x2a0 [i915] [ 183.652726]
__access_remote_vm+0x224/0x380 [ 183.653561]
mem_rw.isra.0+0xf9/0x190 [ 183.654402] vfs_read+0x9d/0x1b0 [
183.655238] ksys_read+0x63/0xe0 [ 183.656065]
do_syscall_64+0x38/0xc0 [ 183.656882]
entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 183.657663] RIP: 0033:0x7fe5ef725142 [ 183.659351] RSP:
002b:7ffe1e81c7e8 EFLAGS: 0246 ORIG_RAX:
[ 183.660227] RAX: ffda RBX: 557055dfb780 RCX:
7fe5ef725142
[ 183.661104] RDX: 1000 RSI: 7ffe1e81d880 RDI:
0005
[ 183.661972] RBP: 7ffe1e81e890 R08: 0030 R09:
0046
[ 183.662832] R10: 557055dfc2e0 R11: 0246 R12:
557055dfb1c0
[ 183.663691] R13: 7ffe1e81e980 R14: R15:
[ 183.664566]
Changes since v1:
- Updated if condition with range_overflows_t [Chris Wilson]
Signed-off-by: Mastan Katragadda
Suggested-by: Adam Zabrocki
Reported-by: Jackson Cody
Cc: Chris Wilson
Cc: Bloomfield Jon
Cc: Dutt Sudeep
Fixes: 9f909e215fea ("drm/i915: Implement vm_ops->access for gdb
access into mmaps")
Cc: # v5.8+
Right?
There was a selftest added with the referenced patch and it sounds
like it would be a good idea to extend it to cover this scenario. As
a separate patch though so this one is easy to backport.
Agreed, a simple regression test(either selftest or igt) for this would be
nice, if possible.
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index efe69d6b86f4..c3ea243d414d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -455,7 +455,7 @@ vm_access(struct vm_area_struct *area, unsigned
long addr,
return -EACCES;
addr -= area->vm_start;
-if (addr >= obj->base.size)
+if (range_overflows_t(u64, addr, len, obj->base.size))
return -EINVAL;
Other users like ttm_bo_vm_access are also checking if len <= 0, should we also
add an explicit check for that here? Otherwise LGTM.
I think no need to add here len<=0, we already validating same
range_overflows_t . converted following condition to range_overflow_t.
if (len < 1 || len > obj->base.size ||
addr >= obj->base.size ||
addr + len > obj->base.
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs
== Series Details == Series: drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs URL : https://patchwork.freedesktop.org/series/101197/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Rework SAGV block time probing
On Wed, Mar 09, 2022 at 10:41:28AM +, Govindapillai, Vinod wrote:
> On Tue, 2022-03-08 at 19:32 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > I'd like to see the SAGV block time we got from the mailbox
> > in the logs regardless of whether other factors prevent the
> > use of SAGV.
> >
> > So let's adjust the code to always query the SAGV block time,
> > log it, and then reset it if SAGV is not actually supported.
> >
> > Signed-off-by: Ville Syrjälä
>
> Hi Ville,
>
> I wonder if it is better to comprehend if we clean assigning -1 to a u32
> variable first before
> this? I see that you are doing that anyway in the next patch in this series.
> Was there any
> particular reason?
No real reason. Probably best to reorder as you suggest so we can
backport the s/-1/0/ change, assuming it actually fixes something.
>
> BR
> Vinod
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 38 +++--
> > 1 file changed, 22 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 8ee31c9590a7..21c37115c36e 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3670,8 +3670,8 @@ intel_has_sagv(struct drm_i915_private *dev_priv)
> > dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
> > }
> >
> > -static void
> > -skl_setup_sagv_block_time(struct drm_i915_private *dev_priv)
> > +static u32
> > +intel_sagv_block_time(struct drm_i915_private *dev_priv)
> > {
> > if (DISPLAY_VER(dev_priv) >= 12) {
> > u32 val = 0;
> > @@ -3680,24 +3680,31 @@ skl_setup_sagv_block_time(struct drm_i915_private
> > *dev_priv)
> > ret = snb_pcode_read(dev_priv,
> > GEN12_PCODE_READ_SAGV_BLOCK_TIME_US,
> > &val, NULL);
> > - if (!ret) {
> > - dev_priv->sagv_block_time_us = val;
> > - return;
> > + if (ret) {
> > + drm_dbg_kms(&dev_priv->drm, "Couldn't read SAGV block
> > time!\n");
> > + return -1;
> > }
> >
> > - drm_dbg(&dev_priv->drm, "Couldn't read SAGV block time!\n");
> > + return val;
> > } else if (DISPLAY_VER(dev_priv) == 11) {
> > - dev_priv->sagv_block_time_us = 10;
> > - return;
> > - } else if (DISPLAY_VER(dev_priv) == 9) {
> > - dev_priv->sagv_block_time_us = 30;
> > - return;
> > + return 10;
> > + } else if (DISPLAY_VER(dev_priv) == 9 && !IS_LP(dev_priv)) {
> > + return 30;
> > } else {
> > - MISSING_CASE(DISPLAY_VER(dev_priv));
> > + /* Default to an unusable block time */
> > + return -1;
> > }
> > +}
> >
> > - /* Default to an unusable block time */
> > - dev_priv->sagv_block_time_us = -1;
> > +static void intel_sagv_init(struct drm_i915_private *i915)
> > +{
> > + i915->sagv_block_time_us = intel_sagv_block_time(i915);
> > +
> > + drm_dbg_kms(&i915->drm, "SAGV supported: %s, original SAGV block time:
> > %u us\n",
> > + str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us);
> > +
> > + if (!intel_has_sagv(i915))
> > + i915->sagv_block_time_us = -1;
> > }
> >
> > /*
> > @@ -8173,8 +8180,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
> > else if (GRAPHICS_VER(dev_priv) == 5)
> > ilk_get_mem_freq(dev_priv);
> >
> > - if (intel_has_sagv(dev_priv))
> > - skl_setup_sagv_block_time(dev_priv);
> > + intel_sagv_init(dev_priv);
> >
> > /* For FIFO watermark updates */
> > if (DISPLAY_VER(dev_priv) >= 9) {
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Treat SAGV block time 0 as SAGV disabled
On Wed, Mar 09, 2022 at 11:29:37AM +, Govindapillai, Vinod wrote:
> On Tue, 2022-03-08 at 19:32 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > For modern platforms the spec explicitly states that a
> > SAGV block time of zero means that SAGV is not supported.
> > Let's extend that to all platforms. Supposedly there should
> > be no systems where this isn't true, and it'll allow us to:
> > - use the same code regardless of older vs. newer platform
> > - wm latencies already treat 0 as disabled, so this fits well
> > with other related code
> > - make it a bit more clear when SAGV is used vs. not
> > - avoid overflows from adding U32_MAX with a u16 wm0 latency value
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 21c37115c36e..906501d6b298 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3682,7 +3682,7 @@ intel_sagv_block_time(struct drm_i915_private
> > *dev_priv)
> > &val, NULL);
> > if (ret) {
> > drm_dbg_kms(&dev_priv->drm, "Couldn't read SAGV block
> > time!\n");
> > - return -1;
> > + return 0;
> > }
> >
> > return val;
> > @@ -3691,8 +3691,7 @@ intel_sagv_block_time(struct drm_i915_private
> > *dev_priv)
> > } else if (DISPLAY_VER(dev_priv) == 9 && !IS_LP(dev_priv)) {
> > return 30;
> > } else {
> > - /* Default to an unusable block time */
> > - return -1;
> > + return 0;
> > }
> > }
> >
> > @@ -3704,7 +3703,7 @@ static void intel_sagv_init(struct drm_i915_private
> > *i915)
> > str_yes_no(intel_has_sagv(i915)), i915->sagv_block_time_us);
> >
> > if (!intel_has_sagv(i915))
> > - i915->sagv_block_time_us = -1;
> > + i915->sagv_block_time_us = 0;
>
> Hi Ville
>
> Currently we set the "sagv_status" as "I915_SAGV_NOT_CONTROLLED" based on the
> number of qgv points.
> So here i915->sagv_block_time_us will be set to 0 even if
> intel_sagv_block_time(i915) would have
> returned some valid values. Is that the desired behavior for sgav watermarks
> calcultations?
I don't think there's much point in calculating the sagv wm if we can't
use sagv anyway.
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs
== Series Details == Series: drm/i915/regs: move GEN12_SFC_DONE_MAX where it belongs URL : https://patchwork.freedesktop.org/series/101197/ State : success == Summary == CI Bug Log - changes from CI_DRM_11341 -> Patchwork_22521 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/index.html Participating hosts (44 -> 36) -- Additional (2): fi-tgl-1115g4 fi-icl-u2 Missing(10): bat-dg1-6 bat-dg1-5 bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-ctg-p8600 bat-rpls-2 bat-jsl-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_22521 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][3] ([fdo#109315]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@gem_lmem_swapp...@verify-random.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#1155]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][9] ([i915#1385] / [i915#62]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gt_lrc: - fi-rkl-guc: [PASS][10] -> [INCOMPLETE][11] ([i915#2373] / [i915#4983]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11341/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html * igt@kms_addfb_basic@too-wide: - fi-tgl-1115g4: NOTRUN -> [DMESG-WARN][12] ([i915#4002]) +87 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@kms_addfb_ba...@too-wide.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][16] ([fdo#109278]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html - fi-icl-u2: NOTRUN -> [SKIP][18] ([fdo#109285]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22521/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRU
Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait
Hi, On Wed, 9 Mar 2022, Takashi Iwai wrote: >> Takashi Iwai wrote: >>> The question is how often this problem hits. Basically it's a very >>> corner case, and I even think we may leave as is; that's a matter of >>> configuration, and lowering such a bar should expect some >>> side-effect. OTOH, if the problem happens in many cases, it's >>> beneficial to fix in the core part, indeed. I'm basicly helping out the intel-gfx folks here. This is now happening systematically in the intel-gfx CI. The hung-task timeout is configured to 30sec (in intel-gfx CI), and there's some new hw configs where this happens every time (I have a separate patch in progress [1] that tries to detect this case and skip the init, but this will require more time as there is risk of breaking existing configurations). [1] https://lists.freedesktop.org/archives/intel-gfx-trybot/2022-February/128278.html Tvrtko Ursulin wrote: > Takashi Iwai wrote: > > Complete behaviour change how? Isn't this something ran on probe so > > likelihood of anyone sending SIGKILL to the modprobe process is only > > the init process? And in that case what is the fundamental difference > [...] > The point is that it does change the actual behavior, and changing the > actual behavior just for working around the corner case like the above > wouldn't be justified without the proper evaluation. > > That said, if this behavior change is intentional and even desired, > that's a way to go. Let me try this out and test on a few configs (with and without the timeout occurring) and send a V3 if this seems ok. Br, Kai
