* [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification
@ 2020-05-02 4:57 Matt Roper
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10 Matt Roper
` (4 more replies)
0 siblings, 5 replies; 13+ messages in thread
From: Matt Roper @ 2020-05-02 4:57 UTC (permalink / raw)
To: intel-gfx; +Cc: chris
We're seeing some CI errors indicating that a workaround did not apply
properly on EHL/JSL. The workaround in question is updating a multicast
register, the failures are only seen on specific CI machines, and the
failures only seem to happen on resets and such rather than on initial
driver load. It seems likely that the culprit here is failure to steer
the multicast register readback on a SKU that has slice0 / subslice0
fused off.
This series makes a couple changes:
* Ensure setup of MCR steering is done at the beginning of the RCS
engine workaround list, not just the general GT workaround list.
* New multicast ranges are added for gen11 and gen12. Sadly this
information is still missing from the bspec (just like the updated
forcewake tables). The hardware guys have given us a spreadsheet
with both the forcewake and the multicast information while they work
on getting the spec properly updated, so that's where the new ranges
come from.
In addition to MCR and forcewake, there's supposed to be some more bspec
updates coming soon that deal with steering (i.e., different MCR ranges
should actually be using different registers to steer rather than just
the 0xFDC register we're familiar with); I don't have the full details
on that yet, so those updates will have to wait until we actually have
an updated spec.
References: https://gitlab.freedesktop.org/drm/intel/issues/1222
Matt Roper (3):
drm/i915: Setup multicast register steering for all gen >= 10
drm/i915: Setup MCR steering for RCS engine workarounds
drm/i915: Add MCR ranges for gen11 and gen12
drivers/gpu/drm/i915/gt/intel_workarounds.c | 57 ++++++++++++++++-----
1 file changed, 45 insertions(+), 12 deletions(-)
--
2.24.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10
2020-05-02 4:57 [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification Matt Roper
@ 2020-05-02 4:57 ` Matt Roper
2020-05-02 7:57 ` Chris Wilson
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds Matt Roper
` (3 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Matt Roper @ 2020-05-02 4:57 UTC (permalink / raw)
To: intel-gfx; +Cc: chris
Steering of multicast registers for workarounds is needed on all
platforms gen10 and above. Move the wa_init_mcr() call to the
higher-level gt_init_workarounds() rather than re-calling it for each
individual platform.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index adddc5c93b48..4a255de13394 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -870,8 +870,6 @@ wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
static void
cnl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
- wa_init_mcr(i915, wal);
-
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(i915, CNL_REVID_B0, CNL_REVID_B0))
wa_write_or(wal,
@@ -887,8 +885,6 @@ cnl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
static void
icl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
- wa_init_mcr(i915, wal);
-
/* WaInPlaceDecompressionHang:icl */
wa_write_or(wal,
GEN9_GAMT_ECO_REG_RW_IA,
@@ -943,8 +939,6 @@ icl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
static void
tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
- wa_init_mcr(i915, wal);
-
/* Wa_1409420604:tgl */
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
wa_write_or(wal,
@@ -961,6 +955,9 @@ tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
static void
gt_init_workarounds(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
+ if (INTEL_GEN(i915) >= 10)
+ wa_init_mcr(i915, wal);
+
if (IS_GEN(i915, 12))
tgl_gt_workarounds_init(i915, wal);
else if (IS_GEN(i915, 11))
--
2.24.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds
2020-05-02 4:57 [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification Matt Roper
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10 Matt Roper
@ 2020-05-02 4:57 ` Matt Roper
2020-05-04 11:43 ` Tvrtko Ursulin
2020-05-12 17:30 ` Daniele Ceraolo Spurio
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 3/3] drm/i915: Add MCR ranges for gen11 and gen12 Matt Roper
` (2 subsequent siblings)
4 siblings, 2 replies; 13+ messages in thread
From: Matt Roper @ 2020-05-02 4:57 UTC (permalink / raw)
To: intel-gfx; +Cc: chris
Reads of multicast registers give the value associated with
slice/subslice 0 by default unless we manually steer the reads to a
different slice/subslice. If slice/subslice 0 are fused off in hardware,
performing unsteered reads of multicast registers will return a value of
0 rather than the value we wrote into the multicast register.
To ensure we can properly readback and verify workarounds that touch
registers in a multicast range, we currently setup MCR steering to a
known-valid slice/subslice as the very first item in the GT workaround
list for gen10+. That steering will then be in place as we verify the
rest of the registers that show up in the GT workaround list, and at
initialization the steering will also still be in effect when we move on
to applying and verifying the workarounds in the RCS engine's workaround
list (which is where most of the multicast registers actually show up).
However we seem run into problems during resets where RCS engine
workarounds are applied without being preceded by application of the GT
workaround list and the steering isn't in place. Let's add the same MCR
steering to the beginning of the RCS engine's workaround list to ensure
that it's always in place and we don't get erroneous messages about RCS
engine workarounds failing to apply.
References: https://gitlab.freedesktop.org/drm/intel/issues/1222
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: chris@chris-wilson.co.uk
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 4a255de13394..b11b83546696 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
+ if (INTEL_GEN(i915) >= 10)
+ wa_init_mcr(i915, wal);
+
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
/*
* Wa_1607138336:tgl
--
2.24.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH v2 3/3] drm/i915: Add MCR ranges for gen11 and gen12
2020-05-02 4:57 [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification Matt Roper
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10 Matt Roper
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds Matt Roper
@ 2020-05-02 4:57 ` Matt Roper
2020-05-12 20:57 ` Daniele Ceraolo Spurio
2020-05-02 5:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Steer multicast register workaround verification (rev2) Patchwork
2020-05-02 6:50 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
4 siblings, 1 reply; 13+ messages in thread
From: Matt Roper @ 2020-05-02 4:57 UTC (permalink / raw)
To: intel-gfx; +Cc: chris
The multicast register ranges are slightly different for gen11 and gen12
than the table we have for gen8. This information never got updated in
the bspec, so this patch is based on a spreadsheet provided by the
hardware team while they work on getting the official documentation
updated.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 45 ++++++++++++++++++---
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b11b83546696..370607514e7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1668,10 +1668,12 @@ create_scratch(struct i915_address_space *vm, int count)
return ERR_PTR(err);
}
-static const struct {
+struct mcr_range {
u32 start;
u32 end;
-} mcr_ranges_gen8[] = {
+};
+
+static const struct mcr_range mcr_ranges_gen8[] = {
{ .start = 0x5500, .end = 0x55ff },
{ .start = 0x7000, .end = 0x7fff },
{ .start = 0x9400, .end = 0x97ff },
@@ -1680,11 +1682,42 @@ static const struct {
{},
};
+static const struct mcr_range mcr_ranges_gen11[] = {
+ { .start = 0x5500, .end = 0x55ff },
+ { .start = 0x7000, .end = 0x7fff },
+ { .start = 0x8140, .end = 0x815f },
+ { .start = 0x8c00, .end = 0x8cff },
+ { .start = 0x94d0, .end = 0x955f },
+ { .start = 0xb000, .end = 0xb3ff },
+ { .start = 0xdf00, .end = 0xe8ff },
+ { .start = 0x24400, .end = 0x24fff },
+ {},
+};
+
+static const struct mcr_range mcr_ranges_gen12[] = {
+ { .start = 0xb00, .end = 0xbff },
+ { .start = 0x1000, .end = 0x1fff },
+ { .start = 0x8150, .end = 0x815f },
+ { .start = 0x8700, .end = 0x87ff },
+ { .start = 0x9520, .end = 0x955f },
+ { .start = 0xb100, .end = 0xb3ff },
+ { .start = 0xde80, .end = 0xe8ff },
+ { .start = 0x24a00, .end = 0x24a7f },
+ {},
+};
+
static bool mcr_range(struct drm_i915_private *i915, u32 offset)
{
+ const struct mcr_range *range_list;
int i;
- if (INTEL_GEN(i915) < 8)
+ if (INTEL_GEN(i915) >= 12)
+ range_list = mcr_ranges_gen12;
+ else if (INTEL_GEN(i915) >= 11)
+ range_list = mcr_ranges_gen11;
+ else if (INTEL_GEN(i915) >= 8)
+ range_list = mcr_ranges_gen8;
+ else
return false;
/*
@@ -1692,9 +1725,9 @@ static bool mcr_range(struct drm_i915_private *i915, u32 offset)
* which only controls CPU initiated MMIO. Routing does not
* work for CS access so we cannot verify them on this path.
*/
- for (i = 0; mcr_ranges_gen8[i].start; i++)
- if (offset >= mcr_ranges_gen8[i].start &&
- offset <= mcr_ranges_gen8[i].end)
+ for (i = 0; range_list[i].start; i++)
+ if (offset >= range_list[i].start &&
+ offset <= range_list[i].end)
return true;
return false;
--
2.24.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for Steer multicast register workaround verification (rev2)
2020-05-02 4:57 [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification Matt Roper
` (2 preceding siblings ...)
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 3/3] drm/i915: Add MCR ranges for gen11 and gen12 Matt Roper
@ 2020-05-02 5:45 ` Patchwork
2020-05-02 6:50 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-05-02 5:45 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx
== Series Details ==
Series: Steer multicast register workaround verification (rev2)
URL : https://patchwork.freedesktop.org/series/76792/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8408 -> Patchwork_17548
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/index.html
Known issues
------------
Here are the changes found in Patchwork_17548 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@i915_selftest@live@gt_pm:
- fi-skl-6600u: [DMESG-FAIL][1] -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/fi-skl-6600u/igt@i915_selftest@live@gt_pm.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/fi-skl-6600u/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666
Participating hosts (51 -> 44)
------------------------------
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_8408 -> Patchwork_17548
CI-20190529: 20190529
CI_DRM_8408: 646ef402e5c4d091d216e27ad5121a8265ab8e00 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5626: f27fdfff026276ac75c69e487c929a843f66f6ca @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17548: bda4e1d81e65985f9dabd33dbe0d69761172e827 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
bda4e1d81e65 drm/i915: Add MCR ranges for gen11 and gen12
cef6afc905e3 drm/i915: Setup MCR steering for RCS engine workarounds
b9aa445528d4 drm/i915: Setup multicast register steering for all gen >= 10
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for Steer multicast register workaround verification (rev2)
2020-05-02 4:57 [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification Matt Roper
` (3 preceding siblings ...)
2020-05-02 5:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Steer multicast register workaround verification (rev2) Patchwork
@ 2020-05-02 6:50 ` Patchwork
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-05-02 6:50 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx
== Series Details ==
Series: Steer multicast register workaround verification (rev2)
URL : https://patchwork.freedesktop.org/series/76792/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8408_full -> Patchwork_17548_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_17548_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][1] -> [FAIL][2] ([i915#454])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb7/igt@i915_pm_dc@dc6-psr.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rps@waitboost:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#39])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-glk9/igt@i915_pm_rps@waitboost.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-glk2/igt@i915_pm_rps@waitboost.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +3 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-varying-size:
- shard-kbl: [PASS][7] -> [FAIL][8] ([IGT#5] / [i915#697])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-kbl1/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-kbl7/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([i915#1185] / [i915#250])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +3 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_psr@psr2_basic:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb2/igt@kms_psr@psr2_basic.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb5/igt@kms_psr@psr2_basic.html
#### Possible fixes ####
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +4 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-alpha-transparent:
- shard-kbl: [DMESG-WARN][17] ([i915#165] / [i915#78]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-alpha-transparent.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-kbl4/igt@kms_cursor_crc@pipe-c-cursor-alpha-transparent.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-apl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-apl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
- shard-skl: [FAIL][21] ([IGT#5]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [SKIP][23] ([fdo#109349]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb6/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
* {igt@kms_flip@busy-flip@c-edp1}:
- shard-skl: [FAIL][25] ([i915#275]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl4/igt@kms_flip@busy-flip@c-edp1.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl6/igt@kms_flip@busy-flip@c-edp1.html
* {igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1}:
- shard-skl: [FAIL][27] ([i915#46]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [FAIL][29] ([i915#1188]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl9/igt@kms_hdr@bpc-switch-suspend.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- shard-skl: [FAIL][31] ([i915#53]) -> [PASS][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl1/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl1/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][33] ([fdo#108145] / [i915#265]) -> [PASS][34] +2 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [SKIP][35] ([fdo#109441]) -> [PASS][36] +2 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb6/igt@kms_psr@psr2_sprite_blt.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][37] ([i915#69]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-skl1/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-skl2/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* {igt@perf@polling-parameterized}:
- shard-iclb: [FAIL][39] ([i915#1542]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb5/igt@perf@polling-parameterized.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb1/igt@perf@polling-parameterized.html
#### Warnings ####
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-apl: [FAIL][41] ([fdo#108145] / [i915#265] / [i915#95]) -> [FAIL][42] ([fdo#108145] / [i915#265])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-apl3/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-apl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][43] ([fdo#109642] / [fdo#111068]) -> [FAIL][44] ([i915#608])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8408/shard-iclb6/igt@kms_psr2_su@page_flip.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/shard-iclb2/igt@kms_psr2_su@page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#5]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/5
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[i915#1185]: https://gitlab.freedesktop.org/drm/intel/issues/1185
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#250]: https://gitlab.freedesktop.org/drm/intel/issues/250
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#275]: https://gitlab.freedesktop.org/drm/intel/issues/275
[i915#39]: https://gitlab.freedesktop.org/drm/intel/issues/39
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#46]: https://gitlab.freedesktop.org/drm/intel/issues/46
[i915#53]: https://gitlab.freedesktop.org/drm/intel/issues/53
[i915#608]: https://gitlab.freedesktop.org/drm/intel/issues/608
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#697]: https://gitlab.freedesktop.org/drm/intel/issues/697
[i915#78]: https://gitlab.freedesktop.org/drm/intel/issues/78
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_8408 -> Patchwork_17548
CI-20190529: 20190529
CI_DRM_8408: 646ef402e5c4d091d216e27ad5121a8265ab8e00 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5626: f27fdfff026276ac75c69e487c929a843f66f6ca @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17548: bda4e1d81e65985f9dabd33dbe0d69761172e827 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17548/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10 Matt Roper
@ 2020-05-02 7:57 ` Chris Wilson
0 siblings, 0 replies; 13+ messages in thread
From: Chris Wilson @ 2020-05-02 7:57 UTC (permalink / raw)
To: Matt Roper, intel-gfx
Quoting Matt Roper (2020-05-02 05:57:42)
> @@ -961,6 +955,9 @@ tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal)
> static void
> gt_init_workarounds(struct drm_i915_private *i915, struct i915_wa_list *wal)
> {
> + if (INTEL_GEN(i915) >= 10)
> + wa_init_mcr(i915, wal);
The interaction between the MCR steering and the replay of w/a is not
obvious, it could do with a comment to avoid future mistakes.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds Matt Roper
@ 2020-05-04 11:43 ` Tvrtko Ursulin
2020-05-04 23:34 ` Matt Roper
2020-05-12 17:30 ` Daniele Ceraolo Spurio
1 sibling, 1 reply; 13+ messages in thread
From: Tvrtko Ursulin @ 2020-05-04 11:43 UTC (permalink / raw)
To: Matt Roper, intel-gfx; +Cc: chris
On 02/05/2020 05:57, Matt Roper wrote:
> Reads of multicast registers give the value associated with
> slice/subslice 0 by default unless we manually steer the reads to a
> different slice/subslice. If slice/subslice 0 are fused off in hardware,
> performing unsteered reads of multicast registers will return a value of
> 0 rather than the value we wrote into the multicast register.
>
> To ensure we can properly readback and verify workarounds that touch
> registers in a multicast range, we currently setup MCR steering to a
> known-valid slice/subslice as the very first item in the GT workaround
> list for gen10+. That steering will then be in place as we verify the
> rest of the registers that show up in the GT workaround list, and at
> initialization the steering will also still be in effect when we move on
> to applying and verifying the workarounds in the RCS engine's workaround
> list (which is where most of the multicast registers actually show up).
>
> However we seem run into problems during resets where RCS engine
> workarounds are applied without being preceded by application of the GT
> workaround list and the steering isn't in place. Let's add the same MCR
> steering to the beginning of the RCS engine's workaround list to ensure
> that it's always in place and we don't get erroneous messages about RCS
> engine workarounds failing to apply.
>
> References: https://gitlab.freedesktop.org/drm/intel/issues/1222
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: chris@chris-wilson.co.uk
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 4a255de13394..b11b83546696 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = engine->i915;
>
> + if (INTEL_GEN(i915) >= 10)
> + wa_init_mcr(i915, wal);
> +
> if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
> /*
> * Wa_1607138336:tgl
>
No complaints, only a question - is live_engine_reset_workarounds able
to catch this, presumably sporadic, 0xfdc loss after engine reset?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds
2020-05-04 11:43 ` Tvrtko Ursulin
@ 2020-05-04 23:34 ` Matt Roper
2020-05-05 8:14 ` Tvrtko Ursulin
0 siblings, 1 reply; 13+ messages in thread
From: Matt Roper @ 2020-05-04 23:34 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, chris
On Mon, May 04, 2020 at 12:43:54PM +0100, Tvrtko Ursulin wrote:
>
> On 02/05/2020 05:57, Matt Roper wrote:
> > Reads of multicast registers give the value associated with
> > slice/subslice 0 by default unless we manually steer the reads to a
> > different slice/subslice. If slice/subslice 0 are fused off in hardware,
> > performing unsteered reads of multicast registers will return a value of
> > 0 rather than the value we wrote into the multicast register.
> >
> > To ensure we can properly readback and verify workarounds that touch
> > registers in a multicast range, we currently setup MCR steering to a
> > known-valid slice/subslice as the very first item in the GT workaround
> > list for gen10+. That steering will then be in place as we verify the
> > rest of the registers that show up in the GT workaround list, and at
> > initialization the steering will also still be in effect when we move on
> > to applying and verifying the workarounds in the RCS engine's workaround
> > list (which is where most of the multicast registers actually show up).
> >
> > However we seem run into problems during resets where RCS engine
> > workarounds are applied without being preceded by application of the GT
> > workaround list and the steering isn't in place. Let's add the same MCR
> > steering to the beginning of the RCS engine's workaround list to ensure
> > that it's always in place and we don't get erroneous messages about RCS
> > engine workarounds failing to apply.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/issues/1222
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Cc: chris@chris-wilson.co.uk
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 4a255de13394..b11b83546696 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> > {
> > struct drm_i915_private *i915 = engine->i915;
> > + if (INTEL_GEN(i915) >= 10)
> > + wa_init_mcr(i915, wal);
> > +
> > if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
> > /*
> > * Wa_1607138336:tgl
> >
>
> No complaints, only a question - is live_engine_reset_workarounds able to
> catch this, presumably sporadic, 0xfdc loss after engine reset?
From what I can see, it looks like that selftests uses a separate
ring-based approach to handling the workarounds rather than using the
CPU. It looks like that selftest just skips all MCR registers since we
can't steer ring accesses the way we can with the CPU.
Matt
>
> Regards,
>
> Tvrtko
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds
2020-05-04 23:34 ` Matt Roper
@ 2020-05-05 8:14 ` Tvrtko Ursulin
0 siblings, 0 replies; 13+ messages in thread
From: Tvrtko Ursulin @ 2020-05-05 8:14 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx, chris
On 05/05/2020 00:34, Matt Roper wrote:
> On Mon, May 04, 2020 at 12:43:54PM +0100, Tvrtko Ursulin wrote:
>> On 02/05/2020 05:57, Matt Roper wrote:
>>> Reads of multicast registers give the value associated with
>>> slice/subslice 0 by default unless we manually steer the reads to a
>>> different slice/subslice. If slice/subslice 0 are fused off in hardware,
>>> performing unsteered reads of multicast registers will return a value of
>>> 0 rather than the value we wrote into the multicast register.
>>>
>>> To ensure we can properly readback and verify workarounds that touch
>>> registers in a multicast range, we currently setup MCR steering to a
>>> known-valid slice/subslice as the very first item in the GT workaround
>>> list for gen10+. That steering will then be in place as we verify the
>>> rest of the registers that show up in the GT workaround list, and at
>>> initialization the steering will also still be in effect when we move on
>>> to applying and verifying the workarounds in the RCS engine's workaround
>>> list (which is where most of the multicast registers actually show up).
>>>
>>> However we seem run into problems during resets where RCS engine
>>> workarounds are applied without being preceded by application of the GT
>>> workaround list and the steering isn't in place. Let's add the same MCR
>>> steering to the beginning of the RCS engine's workaround list to ensure
>>> that it's always in place and we don't get erroneous messages about RCS
>>> engine workarounds failing to apply.
>>>
>>> References: https://gitlab.freedesktop.org/drm/intel/issues/1222
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>> Cc: chris@chris-wilson.co.uk
>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> index 4a255de13394..b11b83546696 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> @@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
>>> {
>>> struct drm_i915_private *i915 = engine->i915;
>>> + if (INTEL_GEN(i915) >= 10)
>>> + wa_init_mcr(i915, wal);
>>> +
>>> if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
>>> /*
>>> * Wa_1607138336:tgl
>>>
>>
>> No complaints, only a question - is live_engine_reset_workarounds able to
>> catch this, presumably sporadic, 0xfdc loss after engine reset?
>
>>From what I can see, it looks like that selftests uses a separate
> ring-based approach to handling the workarounds rather than using the
> CPU. It looks like that selftest just skips all MCR registers since we
> can't steer ring accesses the way we can with the CPU.
But 0xfdc is verified after engine reset with a mmio read. Because it is
in the GT list. Strange.. Ack on the series anyway.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds Matt Roper
2020-05-04 11:43 ` Tvrtko Ursulin
@ 2020-05-12 17:30 ` Daniele Ceraolo Spurio
2020-05-12 23:28 ` Matt Roper
1 sibling, 1 reply; 13+ messages in thread
From: Daniele Ceraolo Spurio @ 2020-05-12 17:30 UTC (permalink / raw)
To: Matt Roper, intel-gfx; +Cc: chris
On 5/1/20 9:57 PM, Matt Roper wrote:
> Reads of multicast registers give the value associated with
> slice/subslice 0 by default unless we manually steer the reads to a
> different slice/subslice. If slice/subslice 0 are fused off in hardware,
> performing unsteered reads of multicast registers will return a value of
> 0 rather than the value we wrote into the multicast register.
>
> To ensure we can properly readback and verify workarounds that touch
> registers in a multicast range, we currently setup MCR steering to a
> known-valid slice/subslice as the very first item in the GT workaround
> list for gen10+. That steering will then be in place as we verify the
> rest of the registers that show up in the GT workaround list, and at
> initialization the steering will also still be in effect when we move on
> to applying and verifying the workarounds in the RCS engine's workaround
> list (which is where most of the multicast registers actually show up).
>
> However we seem run into problems during resets where RCS engine
> workarounds are applied without being preceded by application of the GT
> workaround list and the steering isn't in place. Let's add the same MCR
> steering to the beginning of the RCS engine's workaround list to ensure
> that it's always in place and we don't get erroneous messages about RCS
> engine workarounds failing to apply.
>
Did you check with the HW team about this behavior? AFAIU from reading
the specs, the 0xfdc register should be nowhere close the render domain
and therefore it should not be impacted by RCS reset. If it really is
impacted, it might indicate that something funny is happening on the HW
and there might be other register in the area that are also incorrectly
losing their value, so IMO worth investigating.
Daniele
> References: https://gitlab.freedesktop.org/drm/intel/issues/1222
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: chris@chris-wilson.co.uk
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 4a255de13394..b11b83546696 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = engine->i915;
>
> + if (INTEL_GEN(i915) >= 10)
> + wa_init_mcr(i915, wal);
> +
> if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
> /*
> * Wa_1607138336:tgl
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Add MCR ranges for gen11 and gen12
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 3/3] drm/i915: Add MCR ranges for gen11 and gen12 Matt Roper
@ 2020-05-12 20:57 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 13+ messages in thread
From: Daniele Ceraolo Spurio @ 2020-05-12 20:57 UTC (permalink / raw)
To: Matt Roper, intel-gfx; +Cc: chris
On 5/1/20 9:57 PM, Matt Roper wrote:
> The multicast register ranges are slightly different for gen11 and gen12
> than the table we have for gen8. This information never got updated in
> the bspec, so this patch is based on a spreadsheet provided by the
> hardware team while they work on getting the official documentation
> updated.
>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 45 ++++++++++++++++++---
> 1 file changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index b11b83546696..370607514e7b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1668,10 +1668,12 @@ create_scratch(struct i915_address_space *vm, int count)
> return ERR_PTR(err);
> }
>
> -static const struct {
> +struct mcr_range {
> u32 start;
> u32 end;
> -} mcr_ranges_gen8[] = {
> +};
> +
> +static const struct mcr_range mcr_ranges_gen8[] = {
> { .start = 0x5500, .end = 0x55ff },
> { .start = 0x7000, .end = 0x7fff },
> { .start = 0x9400, .end = 0x97ff },
> @@ -1680,11 +1682,42 @@ static const struct {
> {},
> };
>
> +static const struct mcr_range mcr_ranges_gen11[] = {
> + { .start = 0x5500, .end = 0x55ff },
> + { .start = 0x7000, .end = 0x7fff },
> + { .start = 0x8140, .end = 0x815f },
> + { .start = 0x8c00, .end = 0x8cff },
> + { .start = 0x94d0, .end = 0x955f },
> + { .start = 0xb000, .end = 0xb3ff },
> + { .start = 0xdf00, .end = 0xe8ff },
> + { .start = 0x24400, .end = 0x24fff },
> + {},
> +};
> +
> +static const struct mcr_range mcr_ranges_gen12[] = {
> + { .start = 0xb00, .end = 0xbff },
> + { .start = 0x1000, .end = 0x1fff },
> + { .start = 0x8150, .end = 0x815f },
> + { .start = 0x8700, .end = 0x87ff },
> + { .start = 0x9520, .end = 0x955f },
> + { .start = 0xb100, .end = 0xb3ff },
> + { .start = 0xde80, .end = 0xe8ff },
> + { .start = 0x24a00, .end = 0x24a7f },
> + {},
> +};
> +
The tables match what's in the magic spreadsheet.
Given that the steering ranges usually match forcewake ranges, IMO
long-term we should aim to unify the 2 into a single table, but that's
something for another time.
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Daniele
> static bool mcr_range(struct drm_i915_private *i915, u32 offset)
> {
> + const struct mcr_range *range_list;
> int i;
>
> - if (INTEL_GEN(i915) < 8)
> + if (INTEL_GEN(i915) >= 12)
> + range_list = mcr_ranges_gen12;
> + else if (INTEL_GEN(i915) >= 11)
> + range_list = mcr_ranges_gen11;
> + else if (INTEL_GEN(i915) >= 8)
> + range_list = mcr_ranges_gen8;
> + else
> return false;
>
> /*
> @@ -1692,9 +1725,9 @@ static bool mcr_range(struct drm_i915_private *i915, u32 offset)
> * which only controls CPU initiated MMIO. Routing does not
> * work for CS access so we cannot verify them on this path.
> */
> - for (i = 0; mcr_ranges_gen8[i].start; i++)
> - if (offset >= mcr_ranges_gen8[i].start &&
> - offset <= mcr_ranges_gen8[i].end)
> + for (i = 0; range_list[i].start; i++)
> + if (offset >= range_list[i].start &&
> + offset <= range_list[i].end)
> return true;
>
> return false;
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds
2020-05-12 17:30 ` Daniele Ceraolo Spurio
@ 2020-05-12 23:28 ` Matt Roper
0 siblings, 0 replies; 13+ messages in thread
From: Matt Roper @ 2020-05-12 23:28 UTC (permalink / raw)
To: Daniele Ceraolo Spurio; +Cc: intel-gfx, chris
On Tue, May 12, 2020 at 10:30:31AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 5/1/20 9:57 PM, Matt Roper wrote:
> > Reads of multicast registers give the value associated with
> > slice/subslice 0 by default unless we manually steer the reads to a
> > different slice/subslice. If slice/subslice 0 are fused off in hardware,
> > performing unsteered reads of multicast registers will return a value of
> > 0 rather than the value we wrote into the multicast register.
> >
> > To ensure we can properly readback and verify workarounds that touch
> > registers in a multicast range, we currently setup MCR steering to a
> > known-valid slice/subslice as the very first item in the GT workaround
> > list for gen10+. That steering will then be in place as we verify the
> > rest of the registers that show up in the GT workaround list, and at
> > initialization the steering will also still be in effect when we move on
> > to applying and verifying the workarounds in the RCS engine's workaround
> > list (which is where most of the multicast registers actually show up).
> >
> > However we seem run into problems during resets where RCS engine
> > workarounds are applied without being preceded by application of the GT
> > workaround list and the steering isn't in place. Let's add the same MCR
> > steering to the beginning of the RCS engine's workaround list to ensure
> > that it's always in place and we don't get erroneous messages about RCS
> > engine workarounds failing to apply.
> >
>
> Did you check with the HW team about this behavior? AFAIU from reading the
> specs, the 0xfdc register should be nowhere close the render domain and
> therefore it should not be impacted by RCS reset. If it really is impacted,
> it might indicate that something funny is happening on the HW and there
> might be other register in the area that are also incorrectly losing their
> value, so IMO worth investigating.
The theory is that it might not be the RCS reset itself that causes us
to lose 0xFDC but rather something else that happened between the last
time we applied the steering (e.g., at init) and when we do the reset.
We've asked the hardware guys about this register not sticking, but
really the only thing we've heard back so far is "try checking the
steering." Presumably steering is good at startup since the workaround
sticks at that point, but then gets changed or cleared later by the time
we do the reset. Unfortunately none of our pre-merge CI machines or
local machines exhibit this problem, only the CI "re-run" machine, so we
don't have a good way to investigate this in a more direct manner.
Would re-applying the steering in the engine workaround list cause any
problems? It seems like in the worst case it would do nothing at all
and the problem would persist, but at least it would protect us in case
some other unknown event causes 0xfdc to be reset, and the eventual
results we get from CI re-runs would let us know if we're on the right
track or not.
Matt
>
> Daniele
>
> > References: https://gitlab.freedesktop.org/drm/intel/issues/1222
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Cc: chris@chris-wilson.co.uk
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 4a255de13394..b11b83546696 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> > {
> > struct drm_i915_private *i915 = engine->i915;
> > + if (INTEL_GEN(i915) >= 10)
> > + wa_init_mcr(i915, wal);
> > +
> > if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
> > /*
> > * Wa_1607138336:tgl
> >
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-05-12 23:28 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-02 4:57 [Intel-gfx] [PATCH v2 0/3] Steer multicast register workaround verification Matt Roper
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 1/3] drm/i915: Setup multicast register steering for all gen >= 10 Matt Roper
2020-05-02 7:57 ` Chris Wilson
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds Matt Roper
2020-05-04 11:43 ` Tvrtko Ursulin
2020-05-04 23:34 ` Matt Roper
2020-05-05 8:14 ` Tvrtko Ursulin
2020-05-12 17:30 ` Daniele Ceraolo Spurio
2020-05-12 23:28 ` Matt Roper
2020-05-02 4:57 ` [Intel-gfx] [PATCH v2 3/3] drm/i915: Add MCR ranges for gen11 and gen12 Matt Roper
2020-05-12 20:57 ` Daniele Ceraolo Spurio
2020-05-02 5:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Steer multicast register workaround verification (rev2) Patchwork
2020-05-02 6:50 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.