[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Clear stop-engine for a pardoned reset
== Series Details == Series: drm/i915: Clear stop-engine for a pardoned reset URL : https://patchwork.freedesktop.org/series/48202/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4666_full -> Patchwork_9943_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9943_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9943_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9943_full: === IGT changes === Warnings igt@kms_atomic_transition@plane-all-transition-fencing: shard-snb: PASS -> SKIP igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9943_full that come from known issues: === IGT changes === Issues hit igt@gem_workarounds@suspend-resume: shard-glk: PASS -> FAIL (fdo#103375) Possible fixes igt@gem_workarounds@suspend-resume: shard-apl: FAIL (fdo#103375) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4666 -> Patchwork_9943 CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9943: 614b7b2da5e1a413c0a2fc8e9915aee456a51c35 @ 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_9943/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit
Pushed to drm-misc-next with the whitespace fix. Thanks for the patch. Regards Manasi On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > This bit was added to DP Training Aux RD interval with DP 1.3. Via > descriptiion of the spec this field indicates the panels true > capabilities are described in DPCD address space 02200h through 022FFh. > > v2: version comment update > v3: version comment correction, commit message update > v4: white space correction > > Signed-off-by: Matt Atwood > --- > include/drm/drm_dp_helper.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c01564991a9f..44aaefdc8448 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -123,8 +123,9 @@ > # define DP_FRAMING_CHANGE_CAP (1 << 1) > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > > -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */ > +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > +# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */ > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */ > > #define DP_ADAPTER_CAP 0x00f /* 1.2 */ > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > -- > 2.17.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_sync: Exercise sync after context switch
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 146 +++
1 file changed, 146 insertions(+)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index 493ae61df..495ca3b53 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -409,6 +409,144 @@ store_ring(int fd, unsigned ring, int num_children, int
timeout)
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
}
+static void
+switch_ring(int fd, unsigned ring, int num_children, int timeout)
+{
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ unsigned engines[16];
+ const char *names[16];
+ int num_engines = 0;
+
+ gem_require_contexts(fd);
+
+ if (ring == ALL_ENGINES) {
+ for_each_physical_engine(fd, ring) {
+ if (!gem_can_store_dword(fd, ring))
+ continue;
+
+ names[num_engines] = e__->name;
+ engines[num_engines++] = ring;
+ if (num_engines == ARRAY_SIZE(engines))
+ break;
+ }
+
+ num_children *= num_engines;
+ } else {
+ gem_require_ring(fd, ring);
+ igt_require(gem_can_store_dword(fd, ring));
+ names[num_engines] = NULL;
+ engines[num_engines++] = ring;
+ }
+
+ intel_detect_and_clear_missed_interrupts(fd);
+ igt_fork(child, num_children) {
+ struct context {
+ struct drm_i915_gem_exec_object2 object[2];
+ struct drm_i915_gem_relocation_entry reloc[1024];
+ struct drm_i915_gem_execbuffer2 execbuf;
+ } contexts[2];
+ double start, elapsed;
+ unsigned long cycles;
+
+ for (int i = 0; i < ARRAY_SIZE(contexts); i++) {
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ const uint32_t sz = 32 << 10;
+ struct context *c = [i];
+ uint32_t *batch, *b;
+
+ memset(>execbuf, 0, sizeof(c->execbuf));
+ c->execbuf.buffers_ptr = to_user_pointer(c->object);
+ c->execbuf.flags = engines[child % num_engines];
+ c->execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
+ c->execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
+ if (gen < 6)
+ c->execbuf.flags |= I915_EXEC_SECURE;
+ c->execbuf.rsvd1 = gem_context_create(fd);
+
+ memset(c->object, 0, sizeof(c->object));
+ c->object[0].handle = gem_create(fd, 4096);
+ gem_write(fd, c->object[0].handle, 0, ,
sizeof(bbe));
+ c->execbuf.buffer_count = 1;
+ gem_execbuf(fd, >execbuf);
+
+ c->object[0].flags |= EXEC_OBJECT_WRITE;
+ c->object[1].handle = gem_create(fd, sz);
+
+ c->object[1].relocs_ptr = to_user_pointer(c->reloc);
+ c->object[1].relocation_count = 1024;
+
+ batch = gem_mmap__cpu(fd, c->object[1].handle, 0, sz,
+ PROT_WRITE | PROT_READ);
+ gem_set_domain(fd, c->object[1].handle,
+ I915_GEM_DOMAIN_CPU,
I915_GEM_DOMAIN_CPU);
+
+ memset(c->reloc, 0, sizeof(c->reloc));
+ b = batch;
+ for (int r = 0; r < 1024; r++) {
+ uint64_t offset;
+
+ c->reloc[r].presumed_offset =
c->object[0].offset;
+ c->reloc[r].offset = (b - batch + 1) *
sizeof(*batch);
+ c->reloc[r].delta = r * sizeof(uint32_t);
+ c->reloc[r].read_domains =
I915_GEM_DOMAIN_INSTRUCTION;
+ c->reloc[r].write_domain =
I915_GEM_DOMAIN_INSTRUCTION;
+
+ offset = c->object[0].offset +
c->reloc[r].delta;
+ *b++ = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22
: 0);
+ if (gen >= 8) {
+ *b++ = offset;
+ *b++ = offset >> 32;
+ } else if (gen >= 4) {
+ *b++ = 0;
+ *b++ = offset;
+ c->reloc[r].offset += sizeof(*batch);
+ } else {
+
Re: [Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit
On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > This bit was added to DP Training Aux RD interval with DP 1.3. Via > descriptiion of the spec this field indicates the panels true > capabilities are described in DPCD address space 02200h through 022FFh. > > v2: version comment update > v3: version comment correction, commit message update > v4: white space correction > > Signed-off-by: Matt Atwood > --- > include/drm/drm_dp_helper.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c01564991a9f..44aaefdc8448 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -123,8 +123,9 @@ > # define DP_FRAMING_CHANGE_CAP (1 << 1) > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > > -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */ > +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > +# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */ > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */ With the fix mentioned by Rodrigo about having a space as below: # define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7) /* DP 1.3 */ Reviewed-by: Manasi Navare Manasi > > #define DP_ADAPTER_CAP 0x00f /* 1.2 */ > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > -- > 2.17.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Icelake DMC v1.07
== Series Details ==
Series: Icelake DMC v1.07
URL : https://patchwork.freedesktop.org/series/48218/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4668 -> Patchwork_9946 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48218/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9946 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
igt@drv_selftest@live_workarounds:
fi-skl-6700k2: PASS -> DMESG-FAIL (fdo#107292)
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: PASS -> FAIL (fdo#103167)
Possible fixes
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@drv_selftest@live_workarounds:
{fi-cfl-8109u}: DMESG-FAIL (fdo#107292) -> PASS
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
fi-kbl-7560u: DMESG-FAIL (fdo#107292) -> PASS
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (54 -> 47) ==
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-glk-j4005 fi-icl-u
== Build changes ==
* Linux: CI_DRM_4668 -> Patchwork_9946
CI_DRM_4668: 8bae517a4dd2ab6ba57b880835fd253e169779f2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4596: d8e78990aa2bbb45574e31b3d7a3e1c40baaa372 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9946: 0ace8c3539260f155828970dd7836ad665e41ffb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0ace8c353926 firmware/dmc/icl: load v1.07 on icelake.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9946/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context URL : https://patchwork.freedesktop.org/series/48195/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4666_full -> Patchwork_9942_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9942_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9942_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9942_full: === IGT changes === Warnings igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9942_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_crc@cursor-128x128-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4666 -> Patchwork_9942 CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9942: 05ab51ff90fa2799a9851fff9ac9496167bc3fe6 @ 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_9942/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Icelake DMC v1.07 (rev2)
== Series Details == Series: Icelake DMC v1.07 (rev2) URL : https://patchwork.freedesktop.org/series/48207/ State : failure == Summary == Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] firmware/dmc/icl: load v1.07 on icelake.
Add Support to load DMC on Icelake.
While at it, also add support to load the firmware
during system resume.
v2: load firmware during system resume.(Imre)
v3: enable has_csr for icelake.(Jyoti)
Cc: Jyoti Yadav
Cc: Imre Deak
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_csr.c| 7 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index e931b48369dd..bbd331f1d5d9 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -600,7 +600,7 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN10_FEATURES, \
GEN(11), \
.ddb_size = 2048, \
- .has_csr = 0, \
+ .has_csr = 1, \
.has_logical_ring_elsq = 1
static const struct intel_device_info intel_icelake_11_info = {
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index cf9b600cca79..393d419afb91 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -34,6 +34,9 @@
* low-power state and comes back to normal.
*/
+#define I915_CSR_ICL "i915/icl_dmc_ver1_07.bin"
+#define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
+
#define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
MODULE_FIRMWARE(I915_CSR_GLK);
#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
@@ -301,6 +304,8 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
if (csr->fw_path == i915_modparams.dmc_firmware_path) {
/* Bypass version check for firmware override. */
required_version = csr->version;
+ } else if (IS_ICELAKE(dev_priv)) {
+ required_version = ICL_CSR_VERSION_REQUIRED;
} else if (IS_CANNONLAKE(dev_priv)) {
required_version = CNL_CSR_VERSION_REQUIRED;
} else if (IS_GEMINILAKE(dev_priv)) {
@@ -458,6 +463,8 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
if (i915_modparams.dmc_firmware_path)
csr->fw_path = i915_modparams.dmc_firmware_path;
+ else if (IS_ICELAKE(dev_priv))
+ csr->fw_path = I915_CSR_ICL;
else if (IS_CANNONLAKE(dev_priv))
csr->fw_path = I915_CSR_CNL;
else if (IS_GEMINILAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e209edbc561d..7686f4d32533 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3588,6 +3588,9 @@ static void icl_display_core_init(struct drm_i915_private
*dev_priv,
/* 7. Setup MBUS. */
icl_mbus_init(dev_priv);
+
+ if (resume && dev_priv->csr.dmc_payload)
+ intel_csr_load_program(dev_priv);
}
static void icl_display_core_uninit(struct drm_i915_private *dev_priv)
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/1] Icelake DMC v1.07
Adding The pull request in the Cover leteer: The following changes since commit fdd34681195afa70a63a9a6cf352513cf3b53896: linux-firmware: add firmware for mt76x0 (2018-08-14 10:35:03 -0400) are available in the git repository at: git://anongit.freedesktop.org/git/drm/drm-firmware.git/ master for you to fetch changes up to d79b57351cda7cb91e79c61175f53946937f0bcd: Merge remote-tracking branch 'official/master' (2018-08-13 21:25:53 -0500) Anusha Srivatsa (9): Merge remote-tracking branch 'official/master' into drm-firmware linux-firmware: Add GuC v11.98 for geminilake linux-firmware: Add HuC v3.00.2225 for geminilake Merge remote-tracking branch 'official/master' Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.05 for Icelake. Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.07 for Icelake. Merge remote-tracking branch 'official/master' WHENCE | 12 i915/glk_guc_ver11_98.bin | Bin 0 -> 154240 bytes i915/glk_huc_ver03_00_2225.bin | Bin 0 -> 220032 bytes i915/icl_dmc_ver1_05.bin | Bin 0 -> 25836 bytes i915/icl_dmc_ver1_07.bin | Bin 0 -> 25716 bytes 5 files changed, 12 insertions(+) create mode 100644 i915/glk_guc_ver11_98.bin create mode 100644 i915/glk_huc_ver03_00_2225.bin create mode 100644 i915/icl_dmc_ver1_05.bin create mode 100644 i915/icl_dmc_ver1_07.bin Anusha Srivatsa (1): firmware/dmc/icl: load v1.07 on icelake. drivers/gpu/drm/i915/i915_pci.c | 2 +- drivers/gpu/drm/i915/intel_csr.c| 7 +++ drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++ 3 files changed, 11 insertions(+), 1 deletion(-) -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/1] Icelake DMC v1.07
Adding The pull request in the Cover leteer: The following changes since commit fdd34681195afa70a63a9a6cf352513cf3b53896: linux-firmware: add firmware for mt76x0 (2018-08-14 10:35:03 -0400) are available in the git repository at: git://anongit.freedesktop.org/git/drm/drm-firmware.git/ master for you to fetch changes up to d79b57351cda7cb91e79c61175f53946937f0bcd: Merge remote-tracking branch 'official/master' (2018-08-13 21:25:53 -0500) Anusha Srivatsa (9): Merge remote-tracking branch 'official/master' into drm-firmware linux-firmware: Add GuC v11.98 for geminilake linux-firmware: Add HuC v3.00.2225 for geminilake Merge remote-tracking branch 'official/master' Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.05 for Icelake. Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.07 for Icelake. Merge remote-tracking branch 'official/master' WHENCE | 12 i915/glk_guc_ver11_98.bin | Bin 0 -> 154240 bytes i915/glk_huc_ver03_00_2225.bin | Bin 0 -> 220032 bytes i915/icl_dmc_ver1_05.bin | Bin 0 -> 25836 bytes i915/icl_dmc_ver1_07.bin | Bin 0 -> 25716 bytes 5 files changed, 12 insertions(+) create mode 100644 i915/glk_guc_ver11_98.bin create mode 100644 i915/glk_huc_ver03_00_2225.bin create mode 100644 i915/icl_dmc_ver1_05.bin create mode 100644 i915/icl_dmc_ver1_07.bin Anusha Srivatsa (1): firmware/dmc/icl: load v1.07 on icelake. drivers/gpu/drm/i915/i915_pci.c | 2 +- drivers/gpu/drm/i915/intel_csr.c| 7 +++ drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++ 3 files changed, 11 insertions(+), 1 deletion(-) -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Per context dynamic (sub)slice power-gating
== Series Details == Series: Per context dynamic (sub)slice power-gating URL : https://patchwork.freedesktop.org/series/48194/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4666_full -> Patchwork_9941_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9941_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9941_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9941_full: === IGT changes === Possible regressions igt@drv_selftest@mock_vma: shard-apl: PASS -> DMESG-FAIL +1 shard-snb: PASS -> DMESG-FAIL igt@gem_ctx_param@invalid-param-get: shard-apl: PASS -> FAIL shard-glk: PASS -> FAIL shard-hsw: PASS -> FAIL shard-kbl: PASS -> FAIL igt@gem_ctx_param@invalid-param-set: shard-kbl: PASS -> DMESG-FAIL +1 shard-hsw: PASS -> DMESG-FAIL +1 shard-snb: PASS -> FAIL +1 shard-glk: PASS -> DMESG-FAIL +1 Warnings igt@drv_selftest@live_evict: shard-snb: PASS -> SKIP +17 igt@drv_selftest@live_execlists: shard-hsw: PASS -> SKIP +17 igt@drv_selftest@live_objects: shard-glk: PASS -> SKIP +17 igt@drv_selftest@live_requests: shard-kbl: PASS -> SKIP +17 igt@drv_selftest@live_workarounds: shard-apl: PASS -> SKIP +17 igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9941_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@cursor-vs-flip-legacy: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: PASS -> FAIL (fdo#105363, fdo#102887) Possible fixes igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4666 -> Patchwork_9941 CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9941: 491e75be6beffef5d6503f91b4ce12d1fc3d7289 @ 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_9941/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Get DDI clock for ICL for MG PLL and TBT PLL
On Mon, 2018-08-13 at 22:19 +, Souza, Jose wrote:
> On Fri, 2018-07-27 at 13:04 -0700, Paulo Zanoni wrote:
> > From: Manasi Navare
> >
> > PLLs are the source clocks for the DDIs so in order to determine
> > the
> > ddi clock we need to check the PLL configuration.
> >
> > For MG PHy Ports (C - F), depending on whether it is a TBT PLL or
> > MG
> > PLL the link lock can be obtained from the the PLL divisors based
> > on
> > the specification.
> >
> > v2 (from Paulo):
> > * Make the algorithm look more like what's in the spec, also
> > document
> >where we differ form the spec and why.
> > * Make the code a little more consistent with our coding style.
> >
> > Cc: James Ausmus
> > Signed-off-by: Manasi Navare
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 5 ++
> > drivers/gpu/drm/i915/intel_ddi.c | 81
> > +++-
> > 2 files changed, 84 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e04ac47d53db..cd37e76d4d19 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9458,6 +9458,7 @@ enum skl_power_gate {
> > #define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_5(2 <<
> > 12)
> > #define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_7(3 <<
> > 12)
> > #define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) <<
> > 8)
> > +#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT8
> > #define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK (0xf <<
> > 8)
> > #define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
> > _MG_CLKTOP2_HSCLKCTL_PORT1
> > , \
> > @@ -9468,7 +9469,10 @@ enum skl_power_gate {
> > #define _MG_PLL_DIV0_PORT3 0x16AA00
> > #define _MG_PLL_DIV0_PORT4 0x16BA00
> > #define MG_PLL_DIV0_FRACNEN_H(1 <<
> > 30)
> > +#define MG_PLL_DIV0_FBDIV_FRAC_MASK (0x3fff
> > ff << 8)
> > +#define MG_PLL_DIV0_FBDIV_FRAC_SHIFT 8
> > #define MG_PLL_DIV0_FBDIV_FRAC(x)((x) <<
> > 8)
> > +#define MG_PLL_DIV0_FBDIV_INT_MASK (0xff
> > << 0)
> > #define MG_PLL_DIV0_FBDIV_INT(x) ((x) << 0)
> > #define MG_PLL_DIV0(port) _MMIO_PORT((port) - PORT_C,
> > _MG_PLL_DIV0_PORT1, \
> > _MG_PLL_DIV0_PORT2)
> > @@ -9483,6 +9487,7 @@ enum skl_power_gate {
> > #define MG_PLL_DIV1_DITHER_DIV_4 (2 << 12)
> > #define MG_PLL_DIV1_DITHER_DIV_8 (3 << 12)
> > #define MG_PLL_DIV1_NDIVRATIO(x) ((x) << 4)
> > +#define MG_PLL_DIV1_FBPREDIV_MASK(0xf <<
> > 0)
> > #define MG_PLL_DIV1_FBPREDIV(x) ((x) << 0)
> > #define MG_PLL_DIV1(port) _MMIO_PORT((port) - PORT_C,
> > _MG_PLL_DIV1_PORT1, \
> > _MG_PLL_DIV1_PORT2)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 0adc043529f2..a18d57046bcc 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1427,6 +1427,81 @@ static int cnl_calc_wrpll_link(struct
> > drm_i915_private *dev_priv,
> > return dco_freq / (p0 * p1 * p2 * 5);
> > }
> >
> > +static int icl_calc_tbt_pll_link(struct drm_i915_private
> > *dev_priv,
> > +enum port port)
> > +{
> > + u32 val = I915_READ(DDI_CLK_SEL(port)) & DDI_CLK_SEL_MASK;
> > +
> > + switch (val) {
> > + case DDI_CLK_SEL_NONE:
> > + return 0;
> > + case DDI_CLK_SEL_TBT_162:
> > + return 162000;
> > + case DDI_CLK_SEL_TBT_270:
> > + return 27;
> > + case DDI_CLK_SEL_TBT_540:
> > + return 54;
> > + case DDI_CLK_SEL_TBT_810:
> > + return 81;
> > + default:
> > + MISSING_CASE(val);
> > + return 0;
> > + }
> > +}
> > +
> > +static int icl_calc_mg_pll_link(struct drm_i915_private *dev_priv,
> > + enum port port)
> > +{
> > + u32 mg_pll_div0, mg_clktop_hsclkctl;
> > + u32 m1, m2_int, m2_frac, div1, div2, refclk;
> > + u64 tmp;
> > +
> > + refclk = dev_priv->cdclk.hw.ref;
> > +
> > + mg_pll_div0 = I915_READ(MG_PLL_DIV0(port));
> > + mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(port));
> > +
> > + m1 = I915_READ(MG_PLL_DIV1(port)) & MG_PLL_DIV1_FBPREDIV_MASK;
> > + m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
> > + m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
> > + (mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
> > + MG_PLL_DIV0_FBDIV_FRAC_SHIFT : 0;
> > +
> > + switch (mg_clktop_hsclkctl &
> > MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
> > + case MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_2:
> > + div1 = 2;
> > + break;
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Refind the active request before resetting
== Series Details == Series: drm/i915/execlists: Refind the active request before resetting URL : https://patchwork.freedesktop.org/series/48190/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4666_full -> Patchwork_9939_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9939_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9939_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9939_full: === IGT changes === Warnings igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9939_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_crc@cursor-128x128-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@gem_workarounds@suspend-resume: shard-apl: FAIL (fdo#103375) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4666 -> Patchwork_9939 CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9939: abcd9f36c4a4a0ef824bc92773504679bbfa7b7b @ 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_9939/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Icelake DMC v1.07
== Series Details == Series: Icelake DMC v1.07 URL : https://patchwork.freedesktop.org/series/48207/ State : failure == Summary == Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
>
> On 13/08/2018 10:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
> >>
> >> On 13/08/2018 09:16, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> From: Lionel Landwerlin
>
> Abstract the context image access a bit.
>
> Signed-off-by: Lionel Landwerlin
> Reviewed-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 34 +++-
> 1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 49597cf31707..ccb20230df2c 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -210,6 +210,7 @@
> #include "i915_oa_cflgt3.h"
> #include "i915_oa_cnl.h"
> #include "i915_oa_icl.h"
> +#include "intel_lrc_reg.h"
>
> /* HW requires this to be a power of two, between 128k and 16M,
> though driver
> * is currently generally designed assuming the largest 16M size is
> used such
> @@ -1636,27 +1637,25 @@ static void
> gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
> u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> /* The MMIO offsets for Flex EU registers aren't contiguous */
> - u32 flex_mmio[] = {
> - i915_mmio_reg_offset(EU_PERF_CNTL0),
> - i915_mmio_reg_offset(EU_PERF_CNTL1),
> - i915_mmio_reg_offset(EU_PERF_CNTL2),
> - i915_mmio_reg_offset(EU_PERF_CNTL3),
> - i915_mmio_reg_offset(EU_PERF_CNTL4),
> - i915_mmio_reg_offset(EU_PERF_CNTL5),
> - i915_mmio_reg_offset(EU_PERF_CNTL6),
> + i915_reg_t flex_regs[] = {
> + EU_PERF_CNTL0,
> + EU_PERF_CNTL1,
> + EU_PERF_CNTL2,
> + EU_PERF_CNTL3,
> + EU_PERF_CNTL4,
> + EU_PERF_CNTL5,
> + EU_PERF_CNTL6,
> };
> int i;
>
> - reg_state[ctx_oactxctrl] =
> i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> - reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent
> <<
> - GEN8_OA_TIMER_PERIOD_SHIFT) |
> -(dev_priv->perf.oa.periodic ?
> - GEN8_OA_TIMER_ENABLE : 0) |
> -GEN8_OA_COUNTER_RESUME;
> + CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
> + (dev_priv->perf.oa.period_exponent <<
> GEN8_OA_TIMER_PERIOD_SHIFT) |
> + (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
> + GEN8_OA_COUNTER_RESUME);
> >>>
> >>> I'll be honest but, I don't think it's CTX_REG() that helps improve the
> >>> readability here.
> >>>
> >>> The really odd part is that this sticks itself into a bare part of the
> >>> register state not surrounded by any LRI and after a BB_END. This
> >>> routine can only work for established contexts, it should not work for
> >>> execlists_init_reg_state.
> >>
> >> Unless I am missing something change is completely mechanical, so any
> >> question marks you have are already there, right? What do you suggest is
> >> the action here?
> >
> > Sure, the only thing I question of this patch itself is whether
> > CTX_REG() is simply too much horrible obfuscating magic.
>
> Turn a blind eye if the perceived badness factor is below some
> threshold? Following patch depends on this one, so if I have to drop
> this one, then I have to rework the next one etc.. well, it's not the
> worst problem, so yeah, whatever. Make a call and let me know.
The patch was fine, just worrying about the surrounding code.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
Quoting Tvrtko Ursulin (2018-08-14 19:44:09)
>
> On 14/08/2018 15:59, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-14 15:40:58)
> >> From: Chris Wilson
> >>
> >> We want to allow userspace to reconfigure the subslice configuration for
> >> its own use case. To do so, we expose a context parameter to allow
> >> adjustment of the RPCS register stored within the context image (and
> >> currently not accessible via LRI). If the context is adjusted before
> >> first use, the adjustment is for "free"; otherwise if the context is
> >> active we flush the context off the GPU (stalling all users) and forcing
> >> the GPU to save the context to memory where we can modify it and so
> >> ensure that the register is reloaded on next execution.
> >>
> >> The overhead of managing additional EU subslices can be significant,
> >> especially in multi-context workloads. Non-GPGPU contexts should
> >> preferably disable the subslices it is not using, and others should
> >> fine-tune the number to match their workload.
> >>
> >> We expose complete control over the RPCS register, allowing
> >> configuration of slice/subslice, via masks packed into a u64 for
> >> simplicity. For example,
> >>
> >> struct drm_i915_gem_context_param arg;
> >> struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
> >> .instance = 0, };
> >>
> >> memset(, 0, sizeof(arg));
> >> arg.ctx_id = ctx;
> >> arg.param = I915_CONTEXT_PARAM_SSEU;
> >> arg.value = (uintptr_t)
> >> if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0)
> >> {
> >> sseu.packed.subslice_mask = 0;
> >>
> >> drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> >> }
> >>
> >> could be used to disable all subslices where supported.
> >>
> >> v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
> >> (Lionel)
> >>
> >> v3: Add ability to program this per engine (Chris)
> >>
> >> v4: Move most get_sseu() into i915_gem_context.c (Lionel)
> >>
> >> v5: Validate sseu configuration against the device's capabilities (Lionel)
> >>
> >> v6: Change context powergating settings through MI_SDM on kernel context
> >> (Chris)
> >>
> >> v7: Synchronize the requests following a powergating setting change using
> >> a global
> >> dependency (Chris)
> >> Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
> >> Disable RPCS configuration setting for non capable users
> >> (Lionel/Tvrtko)
> >>
> >> v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
> >> s/dev_priv/i915/ (Tvrtko)
> >> Change uapi class/instance fields to u16 (Tvrtko)
> >> Bump mask fields to 64bits (Lionel)
> >> Don't return EPERM when dynamic sseu is disabled (Tvrtko)
> >>
> >> v9: Import context image into kernel context's ppgtt only when
> >> reconfiguring powergated slice/subslices (Chris)
> >> Use aliasing ppgtt when needed (Michel)
> >>
> >> Tvrtko Ursulin:
> >>
> >> v10:
> >> * Update for upstream changes.
> >> * Request submit needs a RPM reference.
> >> * Reject on !FULL_PPGTT for simplicity.
> >> * Pull out get/set param to helpers for readability and less indent.
> >> * Use i915_request_await_dma_fence in add_global_barrier to skip waits
> >> on the same timeline and avoid GEM_BUG_ON.
> >> * No need to explicitly assign a NULL pointer to engine in legacy mode.
> >> * No need to move gen8_make_rpcs up.
> >> * Factored out global barrier as prep patch.
> >> * Allow to only CAP_SYS_ADMIN if !Gen11.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> >> Issue: https://github.com/intel/media-driver/issues/267
> >> Signed-off-by: Chris Wilson
> >> Signed-off-by: Lionel Landwerlin
> >> Cc: Dmitry Rogozhkin
> >> Cc: Tvrtko Ursulin
> >> Cc: Zhipeng Gong
> >> Cc: Joonas Lahtinen
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> drivers/gpu/drm/i915/i915_gem_context.c | 187 +++-
> >> drivers/gpu/drm/i915/intel_lrc.c| 55 +++
> >> drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
> >> include/uapi/drm/i915_drm.h | 43 ++
> >> 4 files changed, 288 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> >> b/drivers/gpu/drm/i915/i915_gem_context.c
> >> index 8a12984e7495..6d6220634e9e 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >> @@ -773,6 +773,91 @@ int i915_gem_context_destroy_ioctl(struct drm_device
> >> *dev, void *data,
> >> return 0;
> >> }
> >>
> >> +static int
> >> +i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> >> + struct intel_engine_cs *engine,
> >> + struct intel_sseu sseu)
> >> +{
> >> + struct drm_i915_private *i915 = ctx->i915;
> >> + struct
[Intel-gfx] [PATCH 0/1] Icelake DMC v1.07
Adding The pull request in the Cover leteer: The following changes since commit fdd34681195afa70a63a9a6cf352513cf3b53896: linux-firmware: add firmware for mt76x0 (2018-08-14 10:35:03 -0400) are available in the git repository at: git://anongit.freedesktop.org/git/drm/drm-firmware.git/ master for you to fetch changes up to d79b57351cda7cb91e79c61175f53946937f0bcd: Merge remote-tracking branch 'official/master' (2018-08-13 21:25:53 -0500) Anusha Srivatsa (9): Merge remote-tracking branch 'official/master' into drm-firmware linux-firmware: Add GuC v11.98 for geminilake linux-firmware: Add HuC v3.00.2225 for geminilake Merge remote-tracking branch 'official/master' Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.05 for Icelake. Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.07 for Icelake. Merge remote-tracking branch 'official/master' WHENCE | 12 i915/glk_guc_ver11_98.bin | Bin 0 -> 154240 bytes i915/glk_huc_ver03_00_2225.bin | Bin 0 -> 220032 bytes i915/icl_dmc_ver1_05.bin | Bin 0 -> 25836 bytes i915/icl_dmc_ver1_07.bin | Bin 0 -> 25716 bytes 5 files changed, 12 insertions(+) create mode 100644 i915/glk_guc_ver11_98.bin create mode 100644 i915/glk_huc_ver03_00_2225.bin create mode 100644 i915/icl_dmc_ver1_05.bin create mode 100644 i915/icl_dmc_ver1_07.bin Anusha Srivatsa (1): firmware/dmc/icl: load v1.07 on icelake. drivers/gpu/drm/i915/i915_pci.c | 2 +- drivers/gpu/drm/i915/intel_csr.c| 7 +++ drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++ 3 files changed, 11 insertions(+), 1 deletion(-) -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
On 13/08/2018 10:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
On 13/08/2018 09:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 49597cf31707..ccb20230df2c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
-(dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
-GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
I'll be honest but, I don't think it's CTX_REG() that helps improve the
readability here.
The really odd part is that this sticks itself into a bare part of the
register state not surrounded by any LRI and after a BB_END. This
routine can only work for established contexts, it should not work for
execlists_init_reg_state.
Unless I am missing something change is completely mechanical, so any
question marks you have are already there, right? What do you suggest is
the action here?
Sure, the only thing I question of this patch itself is whether
CTX_REG() is simply too much horrible obfuscating magic.
Turn a blind eye if the perceived badness factor is below some
threshold? Following patch depends on this one, so if I have to drop
this one, then I have to rework the next one etc.. well, it's not the
worst problem, so yeah, whatever. Make a call and let me know.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 14/08/2018 15:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 15:40:58)
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t)
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Cc: Dmitry Rogozhkin
Cc: Tvrtko Ursulin
Cc: Zhipeng Gong
Cc: Joonas Lahtinen
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 187 +++-
drivers/gpu/drm/i915/intel_lrc.c| 55 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 43 ++
4 files changed, 288 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8a12984e7495..6d6220634e9e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -773,6 +773,91 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ struct i915_request *rq;
+ struct intel_ring *ring;
+ int ret;
+
+ lockdep_assert_held(>drm.struct_mutex);
+
+ /* Submitting requests etc needs the hw awake. */
+ intel_runtime_pm_get(i915);
+
+ i915_retire_requests(i915);
?
I wondered myself but did not make myself dig through all the history of
the series. Cannot think that it does anything useful in the current design.
+
+ /* Now use the RCS to actually reconfigure. */
+ engine = i915->engine[RCS];
? Modifying registers stored in another engine's context image.
Well, I was hoping design was
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/7] gem_wsim: Check sleep times
Quoting Tvrtko Ursulin (2018-08-14 19:27:08) > To not use it is to reimplement existing handy helpers - not ideal. The problem was that they were overly handy so I tried to avoid them in benchmarks/ after being burnt too often. > To split the test bits from useful helpers sounds like quite a task. Nah, it's a drop in the ocean compared to writing the benchmarking framework / integrating into an existing one like ezbench. > To wean gem_wsim off most igt_ stuff needs decision to be made on the > former - what is core api, and what is test related. > > To me problems outweigh the benefit. :( If gem_wsim was under tools, > like intel_gpu_top, then yeah, it would be justifiable. Since it is in > benchmarks I don't think we should bother. I dream one day we will get microbenchmarks as part of CI. Not only would that require a radical overhaul of the benchmarks/ but a substantial investment of hw & maintenance. In my dream, I also have a vision of like-for-like comparisons against other drivers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy
On 14/08/18 11:27, Chris Wilson wrote: Quoting Antonio Argenziano (2018-08-10 19:11:02) On 10/08/18 10:51, Chris Wilson wrote: Quoting Antonio Argenziano (2018-08-10 18:41:22) How does the test fail if the sync goes wrong? Hang detector on the queued batch? We have a hang detector for both missed wakeups and GPU hangs. As tests goes it's fairly tame, but in essence this entire file is about trying to trick the HW+driver into not sending an interrupt back to userspace. Just a very narrow stress test, over and over again from slightly different angles. I see. Reviewed-by: Antonio Argenziano Was that a general r-b for the very similar series or just this last patch? I've only read this last patch, I'll have a look at the rest. Antonio -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] igt/gem_sync: Exercising waiting while keeping the GPU busy
Quoting Antonio Argenziano (2018-08-10 19:11:02) > > > On 10/08/18 10:51, Chris Wilson wrote: > > Quoting Antonio Argenziano (2018-08-10 18:41:22) > >> How does the test fail if the sync goes wrong? Hang detector on the > >> queued batch? > > > > We have a hang detector for both missed wakeups and GPU hangs. As tests > > goes it's fairly tame, but in essence this entire file is about trying > > to trick the HW+driver into not sending an interrupt back to userspace. > > Just a very narrow stress test, over and over again from slightly > > different angles. > > I see. > > Reviewed-by: Antonio Argenziano Was that a general r-b for the very similar series or just this last patch? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/7] gem_wsim: Check sleep times
On 14/08/2018 16:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 16:21:08)
On 14/08/2018 16:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 16:05:13)
From: Tvrtko Ursulin
Notice in more places if we are running behind.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 52 ++-
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 80f180829241..ead91b0f009b 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -1718,6 +1718,21 @@ static bool sync_deps(struct workload *wrk, struct
w_step *w)
return synced;
}
+static unsigned int measured_usleep(unsigned int usec)
+{
+ struct timespec ts = { };
+ unsigned int slept;
+
+ slept = igt_nsec_elapsed();
+ igt_assert(slept == 0);
+ do {
+ usleep(usec - slept);
+ slept = igt_nsec_elapsed() / 1000;
+ } while (slept < usec);
+
+ return igt_nsec_elapsed();
+}
+
static void *run_workload(void *data)
{
struct workload *wrk = (struct workload *)data;
@@ -1739,7 +1754,7 @@ static void *run_workload(void *data)
count++) {
unsigned int cur_seqno = wrk->sync_seqno;
- clock_gettime(CLOCK_MONOTONIC, >repeat_start);
+ igt_gettime(>repeat_start);
Were you already linking against libigt?
This code is not set up to hit an igt_assert()...
This code meaning gem_wsim? There's a lot of asserts in it already, and
when they trigger traceback looks fine. What do you think is missing?
We have different values of fine ;) Looks nothing but a mess for me.
I don't think igt itself has much value outside of being the test
runner, we've baked too much knowledge of it being a test harness into
the code (and in many cases work to reduce those assumptions). I'd
rather libigtcore be distinct and not bring in the interlinked
igt_subtest+igt_assert.
To not use it is to reimplement existing handy helpers - not ideal.
To split the test bits from useful helpers sounds like quite a task.
To wean gem_wsim off most igt_ stuff needs decision to be made on the
former - what is core api, and what is test related.
To me problems outweigh the benefit. :( If gem_wsim was under tools,
like intel_gpu_top, then yeah, it would be justifiable. Since it is in
benchmarks I don't think we should bother.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clear stop-engine for a pardoned reset
Quoting Patchwork (2018-08-14 18:48:08)
> == Series Details ==
>
> Series: drm/i915: Clear stop-engine for a pardoned reset
> URL : https://patchwork.freedesktop.org/series/48202/
> State : success
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9943 =
>
> == Summary - SUCCESS ==
>
> No regressions found.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/48202/revisions/1/mbox/
>
> == Known issues ==
>
> Here are the changes found in Patchwork_9943 that come from known issues:
>
> === IGT changes ===
>
> Issues hit
>
> igt@drv_selftest@live_hangcheck:
> {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#106560)
A different bug at last! That's a missed CS interrupt of some
description instead.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clear stop-engine for a pardoned reset
== Series Details ==
Series: drm/i915: Clear stop-engine for a pardoned reset
URL : https://patchwork.freedesktop.org/series/48202/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9943 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48202/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9943 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
{fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#106560)
Possible fixes
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
igt@drv_selftest@live_workarounds:
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
fi-cnl-psr: DMESG-FAIL (fdo#107292) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 49) ==
Additional (1): fi-glk-j4005
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4666 -> Patchwork_9943
CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9943: 614b7b2da5e1a413c0a2fc8e9915aee456a51c35 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
614b7b2da5e1 drm/i915: Clear stop-engine for a pardoned reset
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9943/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: remove confusing GPIO vs PCH_GPIO
On Fri, Jul 27, 2018 at 12:36:47PM -0700, Lucas De Marchi wrote:
> Instead of defining all registers twice, define just a PCH_GPIO_BASE
> that has the same address as PCH_GPIO_A and use that to calculate all
> the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> the same thing.
>
> v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
> macro to return a particular gpio address and move the enum out of
> i915_reg.h (suggested by Jani)
>
> v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
> actually need to be changed (suggested by Daniel/Ville)
>
> v4: Move definition of i915_gpio to intel_display.h and remove
> GMBUS/GPIO handling from gvt since now they have their own
> defines.
>
> Signed-off-by: Lucas De Marchi
> ---
Adding people that should have been in CC. Let me know if there's
anything missing.
Lucas De Marchi
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> drivers/gpu/drm/i915/i915_reg.h | 24 +---
> drivers/gpu/drm/i915/intel_display.h | 16
> drivers/gpu/drm/i915/intel_i2c.c | 16
> 4 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0f49f9988dfa..19ad2a52ab04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1604,7 +1604,8 @@ struct drm_i915_private {
> struct mutex gmbus_mutex;
>
> /**
> - * Base address of the gmbus and gpio block.
> + * Base address of where the gmbus and gpio blocks are located (either
> + * on PCH or on SoC for platforms without PCH).
>*/
> uint32_t gpio_mmio_base;
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 07606677168c..827d442e1b12 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3168,18 +3168,9 @@ enum i915_power_well_id {
> /*
> * GPIO regs
> */
> -#define GPIOA_MMIO(0x5010)
> -#define GPIOB_MMIO(0x5014)
> -#define GPIOC_MMIO(0x5018)
> -#define GPIOD_MMIO(0x501c)
> -#define GPIOE_MMIO(0x5020)
> -#define GPIOF_MMIO(0x5024)
> -#define GPIOG_MMIO(0x5028)
> -#define GPIOH_MMIO(0x502c)
> -#define GPIOJ_MMIO(0x5034)
> -#define GPIOK_MMIO(0x5038)
> -#define GPIOL_MMIO(0x503C)
> -#define GPIOM_MMIO(0x5040)
> +#define GPIO(gpio) _MMIO(dev_priv->gpio_mmio_base + 0x5010 + \
> + 4 * (gpio))
> +
> # define GPIO_CLOCK_DIR_MASK (1 << 0)
> # define GPIO_CLOCK_DIR_IN (0 << 1)
> # define GPIO_CLOCK_DIR_OUT (1 << 1)
> @@ -7574,6 +7565,8 @@ enum {
>
> /* PCH */
>
> +#define PCH_DISPLAY_BASE 0xcu
> +
> /* south display engine interrupt: IBX */
> #define SDE_AUDIO_POWER_D(1 << 27)
> #define SDE_AUDIO_POWER_C(1 << 26)
> @@ -7868,13 +7861,6 @@ enum {
> #define ICP_TC_HPD_LONG_DETECT(tc_port)(2 << (tc_port) * 4)
> #define ICP_TC_HPD_SHORT_DETECT(tc_port) (1 << (tc_port) * 4)
>
> -#define PCH_GPIOA _MMIO(0xc5010)
> -#define PCH_GPIOB _MMIO(0xc5014)
> -#define PCH_GPIOC _MMIO(0xc5018)
> -#define PCH_GPIOD _MMIO(0xc501c)
> -#define PCH_GPIOE _MMIO(0xc5020)
> -#define PCH_GPIOF _MMIO(0xc5024)
> -
> #define _PCH_DPLL_A 0xc6014
> #define _PCH_DPLL_B 0xc6018
> #define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 0a79a46d5805..e7f49f107e57 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -25,6 +25,22 @@
> #ifndef _INTEL_DISPLAY_H_
> #define _INTEL_DISPLAY_H_
>
> +enum i915_gpio {
> + GPIOA,
> + GPIOB,
> + GPIOC,
> + GPIOD,
> + GPIOE,
> + GPIOF,
> + GPIOG,
> + GPIOH,
> + __GPIOI_UNUSED,
> + GPIOJ,
> + GPIOK,
> + GPIOL,
> + GPIOM,
> +};
> +
> enum pipe {
> INVALID_PIPE = -1,
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index bef32b7c248e..33d87ab93fdd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -37,7 +37,7 @@
>
> struct gmbus_pin {
> const char *name;
> - i915_reg_t reg;
> + enum i915_gpio gpio;
> };
>
> /* Map gmbus pin pairs to names and registers. */
> @@ -121,8 +121,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
> *dev_priv,
> else
> size = ARRAY_SIZE(gmbus_pins);
>
> - return pin < size &&
> -
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Clear STOP_RING bit before restoring the context
== Series Details == Series: drm/i915/execlists: Clear STOP_RING bit before restoring the context URL : https://patchwork.freedesktop.org/series/48187/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4665_full -> Patchwork_9938_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9938_full that come from known issues: === IGT changes === Issues hit igt@gem_workarounds@suspend-resume: shard-glk: NOTRUN -> FAIL (fdo#103375) Possible fixes igt@drv_suspend@shrink: shard-glk: INCOMPLETE (k.org#198133, fdo#103359, fdo#106886) -> PASS igt@gem_workarounds@suspend-resume: shard-apl: FAIL (fdo#103375) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4665 -> Patchwork_9938 CI_DRM_4665: 3a43bf5efa33be9f88d70427dbfba4db4377eaf6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9938: 3155a2f9cb8cd0b001fbaae9ab67afa10051d1d8 @ 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_9938/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] docs: fix typo sharding->sharing
On Fri, Aug 03, 2018 at 12:07:43PM +0300, Petri Latvala wrote:
> On Thu, Aug 02, 2018 at 03:09:37PM -0700, Lucas De Marchi wrote:
> > I was grepping for shard as the tests run on CI, but the only occurrence
> > was this one which seems to be a typo since it's about prime tests.
> >
> > Fixes: 76bce773 ("docs: Update documentation generation with missing
> > entries")
> > Signed-off-by: Lucas De Marchi
>
> Reviewed-by: Petri Latvala
just a heads up that this is not yet applied...
thanks
Lucas De Marchi
>
>
> > ---
> > docs/reference/igt-gpu-tools/igt_test_programs.xml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > index ec05d53e..95c4653e 100644
> > --- a/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > +++ b/docs/reference/igt-gpu-tools/igt_test_programs.xml
> > @@ -229,7 +229,7 @@
> >
> >
> >Prime Tests
> > - Tests for buffer sharding
> > + Tests for buffer sharing
> >
> >
> >
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Clear stop-engine for a pardoned reset
If we pardon a per-engine reset, we may leave the STOP_RING bit asserted
in RING_MI_MODE resulting in the engine hanging. Unconditionally clear
it on the per-engine exit path as we know that either we skipped the
reset and so need the cancellation, or the reset was successful and the
cancellation is a no-op, or there was an error and we will follow up
with a full-reset or wedging (both of which will stop the engines again
as required).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 10 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9dce55182c3a..4f2a9c39 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2079,6 +2079,7 @@ int i915_reset_engine(struct intel_engine_cs *engine,
const char *msg)
goto out;
out:
+ intel_engine_cancel_stop_cs(engine);
i915_gem_reset_finish_engine(engine);
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 99d5a24219c1..8628567d8f6e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -788,6 +788,16 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
return err;
}
+void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ I915_WRITE_FW(RING_MI_MODE(engine->mmio_base),
+ _MASKED_BIT_DISABLE(STOP_RING));
+}
+
const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
{
switch (type) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 9090885d57de..3f6920dd7880 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -906,6 +906,7 @@ int intel_init_blt_ring_buffer(struct intel_engine_cs
*engine);
int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
+void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
u64 intel_engine_get_last_batch_head(const struct intel_engine_cs *engine);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 14/08/18 17:05, Lionel Landwerlin wrote: On 14/08/18 16:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-08-14 16:11:36) On 14/08/18 15:59, Chris Wilson wrote: And I'd still recommend not using indirect access if we can apply the changes immediately. -Chris Hangs on Gen9 :( How does modifying the context image of an idle (unpinned) context cause a hang? -Chris I thought you meant a context modifying it's own RPCS register... no? - Lionel Oh I get it now... Sorry, forget me :) - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Quoting Patchwork (2018-08-14 16:53:29)
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit
> before restoring the context
> URL : https://patchwork.freedesktop.org/series/48195/
> State : success
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9942 =
>
> == Summary - SUCCESS ==
>
> No regressions found.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/48195/revisions/1/mbox/
>
> == Known issues ==
>
> Here are the changes found in Patchwork_9942 that come from known issues:
>
> === IGT changes ===
>
> Issues hit
>
> igt@drv_selftest@live_hangcheck:
> {fi-bdw-samus}: PASS -> DMESG-FAIL (fdo#106560)
Barking up the wrong tree. Hah, case of the mistaken reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Increase LSPCON timeout
== Series Details == Series: Increase LSPCON timeout URL : https://patchwork.freedesktop.org/series/48183/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4665_full -> Patchwork_9937_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9937_full that come from known issues: === IGT changes === Issues hit igt@gem_workarounds@suspend-resume: shard-glk: NOTRUN -> FAIL (fdo#103375) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-glk: INCOMPLETE (fdo#106886, k.org#198133, fdo#103359) -> PASS igt@gem_workarounds@suspend-resume: shard-apl: FAIL (fdo#103375) -> PASS fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4665 -> Patchwork_9937 CI_DRM_4665: 3a43bf5efa33be9f88d70427dbfba4db4377eaf6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9937: 977c85e40247ce7d9dc570748f6bbea3473bad75 @ 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_9937/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 14/08/18 16:18, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-08-14 16:11:36) On 14/08/18 15:59, Chris Wilson wrote: And I'd still recommend not using indirect access if we can apply the changes immediately. -Chris Hangs on Gen9 :( How does modifying the context image of an idle (unpinned) context cause a hang? -Chris I thought you meant a context modifying it's own RPCS register... no? - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit
before restoring the context
URL : https://patchwork.freedesktop.org/series/48195/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9942 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48195/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9942 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
{fi-bdw-samus}: PASS -> DMESG-FAIL (fdo#106560)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
Possible fixes
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 49) ==
Additional (1): fi-glk-j4005
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4666 -> Patchwork_9942
CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9942: 05ab51ff90fa2799a9851fff9ac9496167bc3fe6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
05ab51ff90fa drm/i915/execlists: Refind the active request before resetting
0f52a4d43d9b drm/i915/execlists: Clear STOP_RING bit before restoring the
context
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9942/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Per context dynamic (sub)slice power-gating
== Series Details ==
Series: Per context dynamic (sub)slice power-gating
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9941 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48194/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9941 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-skl-6700hq: PASS -> DMESG-FAIL (fdo#106560, fdo#107174)
Possible fixes
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: DMESG-FAIL (fdo#106947, fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 49) ==
Additional (1): fi-glk-j4005
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4666 -> Patchwork_9941
CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9941: 491e75be6beffef5d6503f91b4ce12d1fc3d7289 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
491e75be6bef drm/i915: Expose RPCS (SSEU) configuration to userspace
46adb8a4a966 drm/i915: Explicitly mark Global GTT address spaces
128663cebf31 drm/i915: Add global barrier support
19449778b5b3 drm/i915/perf: lock powergating configuration to default when
active
e3d46c7d1eb6 drm/i915/perf: reuse intel_lrc ctx regs macro
5802b42315f5 drm/i915/perf: simplify configure all context function
f2e29d92ffdf drm/i915: Record the sseu configuration per-context & engine
6a364f5371a6 drm/i915: Program RPCS for Broadwell
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9941/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/7] gem_wsim: Check sleep times
Quoting Tvrtko Ursulin (2018-08-14 16:21:08)
>
> On 14/08/2018 16:09, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-14 16:05:13)
> >> From: Tvrtko Ursulin
> >>
> >> Notice in more places if we are running behind.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> benchmarks/gem_wsim.c | 52 ++-
> >> 1 file changed, 46 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> >> index 80f180829241..ead91b0f009b 100644
> >> --- a/benchmarks/gem_wsim.c
> >> +++ b/benchmarks/gem_wsim.c
> >> @@ -1718,6 +1718,21 @@ static bool sync_deps(struct workload *wrk, struct
> >> w_step *w)
> >> return synced;
> >> }
> >>
> >> +static unsigned int measured_usleep(unsigned int usec)
> >> +{
> >> + struct timespec ts = { };
> >> + unsigned int slept;
> >> +
> >> + slept = igt_nsec_elapsed();
> >> + igt_assert(slept == 0);
> >> + do {
> >> + usleep(usec - slept);
> >> + slept = igt_nsec_elapsed() / 1000;
> >> + } while (slept < usec);
> >> +
> >> + return igt_nsec_elapsed();
> >> +}
> >> +
> >> static void *run_workload(void *data)
> >> {
> >> struct workload *wrk = (struct workload *)data;
> >> @@ -1739,7 +1754,7 @@ static void *run_workload(void *data)
> >> count++) {
> >> unsigned int cur_seqno = wrk->sync_seqno;
> >>
> >> - clock_gettime(CLOCK_MONOTONIC, >repeat_start);
> >> + igt_gettime(>repeat_start);
> >
> > Were you already linking against libigt?
> > This code is not set up to hit an igt_assert()...
>
> This code meaning gem_wsim? There's a lot of asserts in it already, and
> when they trigger traceback looks fine. What do you think is missing?
We have different values of fine ;) Looks nothing but a mess for me.
I don't think igt itself has much value outside of being the test
runner, we've baked too much knowledge of it being a test harness into
the code (and in many cases work to reduce those assumptions). I'd
rather libigtcore be distinct and not bring in the interlinked
igt_subtest+igt_assert.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
Quoting Tvrtko Ursulin (2018-08-14 15:40:58)
> +static int
> +i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine,
> + struct intel_sseu sseu)
> +{
> + struct drm_i915_private *i915 = ctx->i915;
> + struct i915_request *rq;
> + struct intel_ring *ring;
> + int ret;
> +
> + lockdep_assert_held(>drm.struct_mutex);
> +
> + /* Submitting requests etc needs the hw awake. */
> + intel_runtime_pm_get(i915);
> +
> + i915_retire_requests(i915);
> +
> + /* Now use the RCS to actually reconfigure. */
> + engine = i915->engine[RCS];
> +
> + rq = i915_request_alloc(engine, i915->kernel_context);
> + if (IS_ERR(rq)) {
> + ret = PTR_ERR(rq);
> + goto out_put;
> + }
> +
> + ret = engine->emit_rpcs_config(rq, ctx, sseu);
> + if (ret)
> + goto out_add;
> +
> + /* Queue this switch after all other activity */
> + list_for_each_entry(ring, >gt.active_rings, active_link) {
> + struct i915_request *prev;
> +
> + prev = last_request_on_engine(ring->timeline, engine);
> + if (prev)
> + i915_sw_fence_await_sw_fence_gfp(>submit,
> +>submit,
> +I915_FENCE_GFP);
> + }
> +
> + i915_gem_set_global_barrier(i915, rq);
> +
> +out_add:
> + i915_request_add(rq);
> +out_put:
> + intel_runtime_pm_put(i915);
> +
> + return ret;
Looks like we should be able to hook this up to a selftest to confirm
the modification does land in the target context image, and a SRM to
confirm it loaded.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/7] gem_wsim: Check sleep times
On 14/08/2018 16:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-14 16:05:13)
From: Tvrtko Ursulin
Notice in more places if we are running behind.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 52 ++-
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 80f180829241..ead91b0f009b 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -1718,6 +1718,21 @@ static bool sync_deps(struct workload *wrk, struct
w_step *w)
return synced;
}
+static unsigned int measured_usleep(unsigned int usec)
+{
+ struct timespec ts = { };
+ unsigned int slept;
+
+ slept = igt_nsec_elapsed();
+ igt_assert(slept == 0);
+ do {
+ usleep(usec - slept);
+ slept = igt_nsec_elapsed() / 1000;
+ } while (slept < usec);
+
+ return igt_nsec_elapsed();
+}
+
static void *run_workload(void *data)
{
struct workload *wrk = (struct workload *)data;
@@ -1739,7 +1754,7 @@ static void *run_workload(void *data)
count++) {
unsigned int cur_seqno = wrk->sync_seqno;
- clock_gettime(CLOCK_MONOTONIC, >repeat_start);
+ igt_gettime(>repeat_start);
Were you already linking against libigt?
This code is not set up to hit an igt_assert()...
This code meaning gem_wsim? There's a lot of asserts in it already, and
when they trigger traceback looks fine. What do you think is missing?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
Quoting Lionel Landwerlin (2018-08-14 16:11:36) > On 14/08/18 15:59, Chris Wilson wrote: > > And I'd still recommend not using indirect access if we can apply the > > changes immediately. > > -Chris > > > > Hangs on Gen9 :( How does modifying the context image of an idle (unpinned) context cause a hang? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating
== Series Details == Series: Per context dynamic (sub)slice power-gating URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3684:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3698:16: warning: expression using sizeof(void) Commit: drm/i915/perf: simplify configure all context function Okay! Commit: drm/i915/perf: reuse intel_lrc ctx regs macro Okay! Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: Add global barrier support -drivers/gpu/drm/i915/selftests/../i915_drv.h:3698:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3725:16: warning: expression using sizeof(void) Commit: drm/i915: Explicitly mark Global GTT address spaces Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/7] gem_wsim: Stop keeping batches mapped
On 14/08/2018 16:13, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-08-14 16:05:16) From: Tvrtko Ursulin The reason, which I assume was there at some point, to keep the batches persistently memory mapped does not appear to be there. So unmap them after creation and remove the unused structure members. Signed-off-by: Tvrtko Ursulin --- benchmarks/gem_wsim.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c index 34758419254a..24f518a7770f 100644 --- a/benchmarks/gem_wsim.c +++ b/benchmarks/gem_wsim.c @@ -128,7 +128,6 @@ struct w_step struct drm_i915_gem_relocation_entry reloc[4]; unsigned long bb_sz; uint32_t bb_handle; - uint32_t *mapped_batch; uint32_t *seqno_value; uint32_t *seqno_address; uint32_t *rt0_value; @@ -136,7 +135,6 @@ struct w_step uint32_t *rt1_address; uint32_t *latch_value; uint32_t *latch_address; - unsigned int mapped_len; }; DECLARE_EWMA(uint64_t, rt, 4, 2) @@ -755,8 +753,7 @@ terminate_bb(struct w_step *w, unsigned int flags) *cs = bbe; - w->mapped_batch = ptr; - w->mapped_len = mmap_len; + munmap(ptr, mmap_len); The mapped_batch/ptr contains seqno_value/seqno_address etc which is used after terminate_bb(). Oh dear, I was blind.. Thanks for being sharp as always. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating
== Series Details == Series: Per context dynamic (sub)slice power-gating URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6a364f5371a6 drm/i915: Program RPCS for Broadwell f2e29d92ffdf drm/i915: Record the sseu configuration per-context & engine 5802b42315f5 drm/i915/perf: simplify configure all context function e3d46c7d1eb6 drm/i915/perf: reuse intel_lrc ctx regs macro 19449778b5b3 drm/i915/perf: lock powergating configuration to default when active 128663cebf31 drm/i915: Add global barrier support 46adb8a4a966 drm/i915: Explicitly mark Global GTT address spaces -:44: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #44: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:335: + bool is_ggtt:1; total: 0 errors, 1 warnings, 0 checks, 25 lines checked 491e75be6bef drm/i915: Expose RPCS (SSEU) configuration to userspace -:40: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #40: v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel) total: 0 errors, 1 warnings, 0 checks, 340 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/7] gem_wsim: Stop keeping batches mapped
Quoting Tvrtko Ursulin (2018-08-14 16:05:16) > From: Tvrtko Ursulin > > The reason, which I assume was there at some point, to keep the batches > persistently memory mapped does not appear to be there. So unmap them > after creation and remove the unused structure members. > > Signed-off-by: Tvrtko Ursulin > --- > benchmarks/gem_wsim.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c > index 34758419254a..24f518a7770f 100644 > --- a/benchmarks/gem_wsim.c > +++ b/benchmarks/gem_wsim.c > @@ -128,7 +128,6 @@ struct w_step > struct drm_i915_gem_relocation_entry reloc[4]; > unsigned long bb_sz; > uint32_t bb_handle; > - uint32_t *mapped_batch; > uint32_t *seqno_value; > uint32_t *seqno_address; > uint32_t *rt0_value; > @@ -136,7 +135,6 @@ struct w_step > uint32_t *rt1_address; > uint32_t *latch_value; > uint32_t *latch_address; > - unsigned int mapped_len; > }; > > DECLARE_EWMA(uint64_t, rt, 4, 2) > @@ -755,8 +753,7 @@ terminate_bb(struct w_step *w, unsigned int flags) > > *cs = bbe; > > - w->mapped_batch = ptr; > - w->mapped_len = mmap_len; > + munmap(ptr, mmap_len); The mapped_batch/ptr contains seqno_value/seqno_address etc which is used after terminate_bb(). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Clear STOP_RING bit
before restoring the context
URL : https://patchwork.freedesktop.org/series/48191/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9940 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9940 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9940, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48191/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9940:
=== IGT changes ===
Possible regressions
igt@drv_selftest@live_hangcheck:
{fi-bdw-samus}: PASS -> DMESG-FAIL
fi-cnl-psr: PASS -> DMESG-FAIL
fi-bdw-5557u: PASS -> DMESG-FAIL
fi-skl-gvtdvm: PASS -> DMESG-FAIL
fi-cfl-guc: PASS -> DMESG-FAIL
fi-cfl-8700k: PASS -> DMESG-FAIL
{fi-cfl-8109u}: PASS -> DMESG-FAIL
fi-cfl-s3: PASS -> DMESG-FAIL
fi-whl-u: PASS -> DMESG-FAIL
fi-bsw-n3050: PASS -> DMESG-FAIL
fi-bdw-gvtdvm: PASS -> DMESG-FAIL
{fi-icl-u}: PASS -> DMESG-FAIL
== Known issues ==
Here are the changes found in Patchwork_9940 that come from known issues:
=== IGT changes ===
Issues hit
igt@debugfs_test@read_all_entries:
{fi-icl-u}: PASS -> DMESG-FAIL (fdo#107411)
igt@drv_selftest@live_hangcheck:
{fi-kbl-8809g}: PASS -> DMESG-FAIL (fdo#106947)
fi-kbl-7500u: PASS -> DMESG-FAIL (fdo#106947)
fi-skl-6700hq: PASS -> DMESG-FAIL (fdo#107174)
fi-skl-6700k2: PASS -> DMESG-FAIL (fdo#107174)
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
fi-skl-6600u: PASS -> DMESG-FAIL (fdo#107174)
fi-kbl-r: PASS -> DMESG-FAIL (fdo#106947)
fi-kbl-guc: PASS -> DMESG-FAIL (fdo#106947)
fi-skl-6770hq: PASS -> DMESG-FAIL (fdo#107174)
fi-skl-6260u: PASS -> DMESG-FAIL (fdo#107174)
{fi-skl-iommu}: PASS -> DMESG-FAIL (fdo#107174)
fi-glk-j4005: NOTRUN -> DMESG-FAIL (fdo#106947)
fi-kbl-x1275: PASS -> DMESG-FAIL (fdo#106947)
fi-kbl-7567u: PASS -> DMESG-FAIL (fdo#106947)
fi-glk-dsi: PASS -> DMESG-FAIL (fdo#106947)
igt@drv_selftest@live_requests:
fi-bxt-j4205: PASS -> INCOMPLETE (fdo#103927)
fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)
{fi-bsw-kefka}: PASS -> INCOMPLETE (fdo#105876)
igt@drv_selftest@live_workarounds:
{fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)
{fi-bsw-kefka}: PASS -> DMESG-FAIL (fdo#107292)
fi-bxt-j4205: PASS -> DMESG-FAIL (fdo#107292)
fi-bxt-dsi: NOTRUN -> DMESG-FAIL (fdo#107292)
{fi-bdw-samus}: PASS -> DMESG-FAIL (fdo#107292)
fi-bdw-gvtdvm: PASS -> DMESG-FAIL (fdo#107292)
{fi-icl-u}: PASS -> DMESG-FAIL (fdo#107292)
fi-bdw-5557u: PASS -> DMESG-FAIL (fdo#107292)
igt@gem_exec_reloc@basic-gtt-read-noreloc:
{fi-icl-u}: PASS -> DMESG-WARN (fdo#107411) +77
igt@kms_pipe_crc_basic@read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362) +1
Possible fixes
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@drv_selftest@live_workarounds:
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#105876 https://bugs.freedesktop.org/show_bug.cgi?id=105876
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107411 https://bugs.freedesktop.org/show_bug.cgi?id=107411
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 49) ==
Additional (1): fi-glk-j4005
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4666 -> Patchwork_9940
CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 14/08/18 15:59, Chris Wilson wrote: And I'd still recommend not using indirect access if we can apply the changes immediately. -Chris Hangs on Gen9 :( - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/7] gem_wsim: Check sleep times
Quoting Tvrtko Ursulin (2018-08-14 16:05:13)
> From: Tvrtko Ursulin
>
> Notice in more places if we are running behind.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> benchmarks/gem_wsim.c | 52 ++-
> 1 file changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> index 80f180829241..ead91b0f009b 100644
> --- a/benchmarks/gem_wsim.c
> +++ b/benchmarks/gem_wsim.c
> @@ -1718,6 +1718,21 @@ static bool sync_deps(struct workload *wrk, struct
> w_step *w)
> return synced;
> }
>
> +static unsigned int measured_usleep(unsigned int usec)
> +{
> + struct timespec ts = { };
> + unsigned int slept;
> +
> + slept = igt_nsec_elapsed();
> + igt_assert(slept == 0);
> + do {
> + usleep(usec - slept);
> + slept = igt_nsec_elapsed() / 1000;
> + } while (slept < usec);
> +
> + return igt_nsec_elapsed();
> +}
> +
> static void *run_workload(void *data)
> {
> struct workload *wrk = (struct workload *)data;
> @@ -1739,7 +1754,7 @@ static void *run_workload(void *data)
> count++) {
> unsigned int cur_seqno = wrk->sync_seqno;
>
> - clock_gettime(CLOCK_MONOTONIC, >repeat_start);
> + igt_gettime(>repeat_start);
Were you already linking against libigt?
This code is not set up to hit an igt_assert()...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/7] gem_wsim: Make workload commands case sensitive
From: Tvrtko Ursulin
Need namespace for new commands and I never documented they are case
insensitive so it is fine.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index ead91b0f009b..e5eb1ef70a35 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -310,7 +310,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
if ((field = strtok_r(fstart, ".", )) != NULL) {
fstart = NULL;
- if (!strcasecmp(field, "d")) {
+ if (!strcmp(field, "d")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
@@ -326,7 +326,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.delay = tmp;
goto add_step;
}
- } else if (!strcasecmp(field, "p")) {
+ } else if (!strcmp(field, "p")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
@@ -342,7 +342,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.period = tmp;
goto add_step;
}
- } else if (!strcasecmp(field, "s")) {
+ } else if (!strcmp(field, "s")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
@@ -359,7 +359,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.target = tmp;
goto add_step;
}
- } else if (!strcasecmp(field, "t")) {
+ } else if (!strcmp(field, "t")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
@@ -375,7 +375,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.throttle = tmp;
goto add_step;
}
- } else if (!strcasecmp(field, "q")) {
+ } else if (!strcmp(field, "q")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
@@ -391,7 +391,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.throttle = tmp;
goto add_step;
}
- } else if (!strcasecmp(field, "a")) {
+ } else if (!strcmp(field, "a")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
tmp = atoi(field);
@@ -407,7 +407,7 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.target = tmp;
goto add_step;
}
- } else if (!strcasecmp(field, "f")) {
+ } else if (!strcmp(field, "f")) {
step.type = SW_FENCE;
goto add_step;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 7/7] gem_wsim: Fix BCS usage under VCS2 remap warning
From: Tvrtko Ursulin
Need to check we actually are in VCS2 remapping mode!
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index fd268b3ab456..850c8972f6eb 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -661,7 +661,7 @@ add_step:
}
}
- if (bcs_used && verbose)
+ if (bcs_used && (flags & VCS2REMAP) && verbose)
printf("BCS usage in workload with VCS2 remapping enabled!\n");
return wrk;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 5/7] gem_wsim: Make batches preemptable by default
From: Tvrtko Ursulin
MI_NOOP cannot be preempted which means up to now gem_wsim workloads were
preemptable on batch buffer granularity only.
Add MI_ARB_CHK every 100us so the new default is mid-batch preemption.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 20
1 file changed, 20 insertions(+)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 24f518a7770f..f60c086a3f1e 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -683,6 +683,25 @@ static unsigned long get_bb_sz(unsigned int duration)
nop_calibration_us, sizeof(uint32_t));
}
+static void
+init_bb(struct w_step *w, unsigned int flags)
+{
+ /* Preemption point every 100us. */
+ const unsigned int arb_period = get_bb_sz(100) / sizeof(uint32_t);
+ unsigned int i;
+ uint32_t *ptr;
+
+ gem_set_domain(fd, w->bb_handle,
+ I915_GEM_DOMAIN_WC, I915_GEM_DOMAIN_WC);
+
+ ptr = gem_mmap__wc(fd, w->bb_handle, 0, w->bb_sz, PROT_WRITE);
+
+ for (i = arb_period; i < w->bb_sz / sizeof(uint32_t); i += arb_period)
+ ptr[i] = 0x5 << 23; /* MI_ARB_CHK */
+
+ munmap(ptr, w->bb_sz);
+}
+
static void
terminate_bb(struct w_step *w, unsigned int flags)
{
@@ -836,6 +855,7 @@ alloc_step_batch(struct workload *wrk, struct w_step *w,
unsigned int flags)
w->bb_sz = get_bb_sz(w->duration.max);
w->bb_handle = w->obj[j].handle = gem_create(fd, w->bb_sz);
+ init_bb(w, flags);
terminate_bb(w, flags);
if (flags & SEQNO) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 6/7] gem_wsim: Per context preemption point control
From: Tvrtko Ursulin
Allow workloads to specify frequency of preemption points per context.
New workload command ('X') is added to allow this.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 84 --
benchmarks/wsim/README | 18 -
2 files changed, 98 insertions(+), 4 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index f60c086a3f1e..fd268b3ab456 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -83,7 +83,8 @@ enum w_type
QD_THROTTLE,
SW_FENCE,
SW_FENCE_SIGNAL,
- CTX_PRIORITY
+ CTX_PRIORITY,
+ PREEMPTION
};
struct deps
@@ -122,6 +123,7 @@ struct w_step
unsigned int idx;
struct igt_list rq_link;
unsigned int request;
+ unsigned int preempt_us;
struct drm_i915_gem_execbuffer2 eb;
struct drm_i915_gem_exec_object2 *obj;
@@ -441,6 +443,42 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
} else if (!strcmp(field, "f")) {
step.type = SW_FENCE;
goto add_step;
+ } else if (!strcmp(field, "X")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", )) !=
+ NULL) {
+ tmp = atoi(field);
+ if (tmp <= 0 && nr == 0) {
+ if (verbose)
+ fprintf(stderr,
+ "Invalid
context at step %u!\n",
+ nr_steps);
+ return NULL;
+ } else if (tmp < 0 && nr == 1) {
+ if (verbose)
+ fprintf(stderr,
+ "Invalid
preemption period at step %u!\n",
+ nr_steps);
+ return NULL;
+ }
+
+ if (nr == 0) {
+ step.context = tmp;
+ } else if (nr == 1) {
+ step.period = tmp;
+ } else {
+ if (verbose)
+ fprintf(stderr,
+ "Invalid
preemption format at step %u!\n",
+ nr_steps);
+ return NULL;
+ }
+
+ nr++;
+ }
+
+ step.type = PREEMPTION;
+ goto add_step;
}
tmp = atoi(field);
@@ -686,11 +724,14 @@ static unsigned long get_bb_sz(unsigned int duration)
static void
init_bb(struct w_step *w, unsigned int flags)
{
- /* Preemption point every 100us. */
- const unsigned int arb_period = get_bb_sz(100) / sizeof(uint32_t);
+ const unsigned int arb_period =
+ get_bb_sz(w->preempt_us) / sizeof(uint32_t);
unsigned int i;
uint32_t *ptr;
+ if (!arb_period)
+ return;
+
gem_set_domain(fd, w->bb_handle,
I915_GEM_DOMAIN_WC, I915_GEM_DOMAIN_WC);
@@ -965,6 +1006,41 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
}
}
+ /* Record default preemption. */
+ for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
+ if (w->type == BATCH)
+ w->preempt_us = 100;
+ }
+
+ /*
+* Scan for contexts with modified preemption config and record their
+* preemption period for the following steps belonging to the same
+* context.
+*/
+ for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
+ struct w_step *w2;
+ int j;
+
+ if (w->type != PREEMPTION)
+ continue;
+
+ for (j = i + 1; j < wrk->nr_steps; j++) {
+ w2 = >steps[j];
+
+ if (w2->context != w->context)
+ continue;
+ else if (w2->type == PREEMPTION)
+ break;
+
[Intel-gfx] [PATCH i-g-t 1/7] gem_wsim: Check sleep times
From: Tvrtko Ursulin
Notice in more places if we are running behind.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 52 ++-
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 80f180829241..ead91b0f009b 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -1718,6 +1718,21 @@ static bool sync_deps(struct workload *wrk, struct
w_step *w)
return synced;
}
+static unsigned int measured_usleep(unsigned int usec)
+{
+ struct timespec ts = { };
+ unsigned int slept;
+
+ slept = igt_nsec_elapsed();
+ igt_assert(slept == 0);
+ do {
+ usleep(usec - slept);
+ slept = igt_nsec_elapsed() / 1000;
+ } while (slept < usec);
+
+ return igt_nsec_elapsed();
+}
+
static void *run_workload(void *data)
{
struct workload *wrk = (struct workload *)data;
@@ -1739,7 +1754,7 @@ static void *run_workload(void *data)
count++) {
unsigned int cur_seqno = wrk->sync_seqno;
- clock_gettime(CLOCK_MONOTONIC, >repeat_start);
+ igt_gettime(>repeat_start);
for (i = 0, w = wrk->steps; wrk->run && (i < wrk->nr_steps);
i++, w++) {
@@ -1751,13 +1766,14 @@ static void *run_workload(void *data)
} else if (w->type == PERIOD) {
struct timespec now;
- clock_gettime(CLOCK_MONOTONIC, );
+ igt_gettime();
do_sleep = w->period -
elapsed_us(>repeat_start, );
if (do_sleep < 0) {
- if (verbose > 1)
- printf("%u: Dropped period @
%u/%u (%dus late)!\n",
- wrk->id, count, i,
do_sleep);
+ if (verbose > 1 &&
+ -do_sleep > 10 * w->period / 100)
+ printf("%u: Missed period @
%u/%u (%dus late)!\n",
+ wrk->id, count, i,
-do_sleep);
continue;
}
} else if (w->type == SYNC) {
@@ -1793,7 +1809,31 @@ static void *run_workload(void *data)
}
if (do_sleep || w->type == PERIOD) {
- usleep(do_sleep);
+ long slept = measured_usleep(do_sleep) / 1000;
+
+ if ( w->type == PERIOD) {
+ struct timespec now;
+
+ igt_gettime();
+
+ slept = elapsed_us(>repeat_start,
+ );
+
+ if (verbose > 1 &&
+ slept > (110 * w->period / 100))
+ printf("%u: Overslept period by
%ldus @ %u/%u! (%uus)\n",
+ wrk->id,
+ -slept, count,
+ i, w->period);
+ } else {
+ if (verbose > 1 &&
+ slept > (110 * do_sleep / 100))
+ printf("%u: Overslept by %ldus
@ %u/%u! (%uus)\n",
+ wrk->id,
+ slept - do_sleep, count,
+ i, do_sleep);
+ }
+
continue;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/7] gem_wsim: Stop keeping batches mapped
From: Tvrtko Ursulin
The reason, which I assume was there at some point, to keep the batches
persistently memory mapped does not appear to be there. So unmap them
after creation and remove the unused structure members.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 34758419254a..24f518a7770f 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -128,7 +128,6 @@ struct w_step
struct drm_i915_gem_relocation_entry reloc[4];
unsigned long bb_sz;
uint32_t bb_handle;
- uint32_t *mapped_batch;
uint32_t *seqno_value;
uint32_t *seqno_address;
uint32_t *rt0_value;
@@ -136,7 +135,6 @@ struct w_step
uint32_t *rt1_address;
uint32_t *latch_value;
uint32_t *latch_address;
- unsigned int mapped_len;
};
DECLARE_EWMA(uint64_t, rt, 4, 2)
@@ -755,8 +753,7 @@ terminate_bb(struct w_step *w, unsigned int flags)
*cs = bbe;
- w->mapped_batch = ptr;
- w->mapped_len = mmap_len;
+ munmap(ptr, mmap_len);
}
static const unsigned int eb_engine_map[NUM_ENGINES] = {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/7] gem_wsim: Context priority support
From: Tvrtko Ursulin
A new workload command ('P') is added which enables per context dynamic
priority control.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 48 +-
benchmarks/wsim/README | 18
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index e5eb1ef70a35..34758419254a 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -82,7 +82,8 @@ enum w_type
THROTTLE,
QD_THROTTLE,
SW_FENCE,
- SW_FENCE_SIGNAL
+ SW_FENCE_SIGNAL,
+ CTX_PRIORITY
};
struct deps
@@ -114,6 +115,7 @@ struct w_step
int target;
int throttle;
int fence_signal;
+ int priority;
};
/* Implementation details */
@@ -162,6 +164,7 @@ struct workload
unsigned int nr_ctxs;
struct {
uint32_t id;
+ int priority;
unsigned int static_vcs;
} *ctx_list;
@@ -342,6 +345,36 @@ parse_workload(struct w_arg *arg, unsigned int flags,
struct workload *app_w)
step.period = tmp;
goto add_step;
}
+ } else if (!strcmp(field, "P")) {
+ unsigned int nr = 0;
+ while ((field = strtok_r(fstart, ".", )) !=
+ NULL) {
+ tmp = atoi(field);
+ if (tmp <= 0 && nr == 0) {
+ if (verbose)
+ fprintf(stderr,
+ "Invalid
context at step %u!\n",
+ nr_steps);
+ return NULL;
+ }
+
+ if (nr == 0) {
+ step.context = tmp;
+ } else if (nr == 1) {
+ step.priority = tmp;
+ } else {
+ if (verbose)
+ fprintf(stderr,
+ "Invalid
priority format at step %u!\n",
+ nr_steps);
+ return NULL;
+ }
+
+ nr++;
+ }
+
+ step.type = CTX_PRIORITY;
+ goto add_step;
} else if (!strcmp(field, "s")) {
if ((field = strtok_r(fstart, ".", )) !=
NULL) {
@@ -1806,6 +1839,19 @@ static void *run_workload(void *data)
inc = cur_seqno - wrk->sync_seqno;
sw_sync_timeline_inc(wrk->sync_timeline, inc);
continue;
+ } else if (w->type == CTX_PRIORITY) {
+ if (w->priority !=
wrk->ctx_list[w->context].priority) {
+ struct drm_i915_gem_context_param param
= {
+ .ctx_id =
wrk->ctx_list[w->context].id,
+ .param =
I915_CONTEXT_PARAM_PRIORITY,
+ .value = w->priority,
+ };
+
+ gem_context_set_param(fd, );
+ wrk->ctx_list[w->context].priority =
+ w->priority;
+ }
+ continue;
}
if (do_sleep || w->type == PERIOD) {
diff --git a/benchmarks/wsim/README b/benchmarks/wsim/README
index 01766d37564f..fd9bff3401af 100644
--- a/benchmarks/wsim/README
+++ b/benchmarks/wsim/README
@@ -3,6 +3,7 @@ Workload descriptor format
ctx.engine.duration_us.dependency.wait,...
..[-].[/][...].<0|1>,...
+P..
d|p|s|t|q|a.,...
f
@@ -22,6 +23,7 @@ Additional workload steps are also supported:
'q' - Throttle to n max queue depth.
'f' - Create a sync fence.
'a' - Advance the previously created sync fence.
+ 'P' - Context priority.
Engine ids: RCS, BCS, VCS, VCS1, VCS2, VECS
@@ -110,3 +112,19 @@ created at the second step. They are submitted ahead of
time while still not
[Intel-gfx] [PATCH i-g-t 0/7] gem_wsim fixes and new features
From: Tvrtko Ursulin A bag of new features and a couple fixes which came to be as I was testing the dynamic SSEU story. Tvrtko Ursulin (7): gem_wsim: Check sleep times gem_wsim: Make workload commands case sensitive gem_wsim: Context priority support gem_wsim: Stop keeping batches mapped gem_wsim: Make batches preemptable by default gem_wsim: Per context preemption point control gem_wsim: Fix BCS usage under VCS2 remap warning benchmarks/gem_wsim.c | 219 + benchmarks/wsim/README | 34 +++ 2 files changed, 234 insertions(+), 19 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
Quoting Tvrtko Ursulin (2018-08-14 15:40:58)
> From: Chris Wilson
>
> We want to allow userspace to reconfigure the subslice configuration for
> its own use case. To do so, we expose a context parameter to allow
> adjustment of the RPCS register stored within the context image (and
> currently not accessible via LRI). If the context is adjusted before
> first use, the adjustment is for "free"; otherwise if the context is
> active we flush the context off the GPU (stalling all users) and forcing
> the GPU to save the context to memory where we can modify it and so
> ensure that the register is reloaded on next execution.
>
> The overhead of managing additional EU subslices can be significant,
> especially in multi-context workloads. Non-GPGPU contexts should
> preferably disable the subslices it is not using, and others should
> fine-tune the number to match their workload.
>
> We expose complete control over the RPCS register, allowing
> configuration of slice/subslice, via masks packed into a u64 for
> simplicity. For example,
>
> struct drm_i915_gem_context_param arg;
> struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
> .instance = 0, };
>
> memset(, 0, sizeof(arg));
> arg.ctx_id = ctx;
> arg.param = I915_CONTEXT_PARAM_SSEU;
> arg.value = (uintptr_t)
> if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
> sseu.packed.subslice_mask = 0;
>
> drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> }
>
> could be used to disable all subslices where supported.
>
> v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
>
> v3: Add ability to program this per engine (Chris)
>
> v4: Move most get_sseu() into i915_gem_context.c (Lionel)
>
> v5: Validate sseu configuration against the device's capabilities (Lionel)
>
> v6: Change context powergating settings through MI_SDM on kernel context
> (Chris)
>
> v7: Synchronize the requests following a powergating setting change using a
> global
> dependency (Chris)
> Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
> Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
>
> v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
> s/dev_priv/i915/ (Tvrtko)
> Change uapi class/instance fields to u16 (Tvrtko)
> Bump mask fields to 64bits (Lionel)
> Don't return EPERM when dynamic sseu is disabled (Tvrtko)
>
> v9: Import context image into kernel context's ppgtt only when
> reconfiguring powergated slice/subslices (Chris)
> Use aliasing ppgtt when needed (Michel)
>
> Tvrtko Ursulin:
>
> v10:
> * Update for upstream changes.
> * Request submit needs a RPM reference.
> * Reject on !FULL_PPGTT for simplicity.
> * Pull out get/set param to helpers for readability and less indent.
> * Use i915_request_await_dma_fence in add_global_barrier to skip waits
>on the same timeline and avoid GEM_BUG_ON.
> * No need to explicitly assign a NULL pointer to engine in legacy mode.
> * No need to move gen8_make_rpcs up.
> * Factored out global barrier as prep patch.
> * Allow to only CAP_SYS_ADMIN if !Gen11.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> Issue: https://github.com/intel/media-driver/issues/267
> Signed-off-by: Chris Wilson
> Signed-off-by: Lionel Landwerlin
> Cc: Dmitry Rogozhkin
> Cc: Tvrtko Ursulin
> Cc: Zhipeng Gong
> Cc: Joonas Lahtinen
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 187 +++-
> drivers/gpu/drm/i915/intel_lrc.c| 55 +++
> drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
> include/uapi/drm/i915_drm.h | 43 ++
> 4 files changed, 288 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 8a12984e7495..6d6220634e9e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -773,6 +773,91 @@ int i915_gem_context_destroy_ioctl(struct drm_device
> *dev, void *data,
> return 0;
> }
>
> +static int
> +i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
> + struct intel_engine_cs *engine,
> + struct intel_sseu sseu)
> +{
> + struct drm_i915_private *i915 = ctx->i915;
> + struct i915_request *rq;
> + struct intel_ring *ring;
> + int ret;
> +
> + lockdep_assert_held(>drm.struct_mutex);
> +
> + /* Submitting requests etc needs the hw awake. */
> + intel_runtime_pm_get(i915);
> +
> + i915_retire_requests(i915);
?
> +
> + /* Now use the RCS to actually reconfigure. */
> + engine = i915->engine[RCS];
? Modifying registers stored in another engine's context image.
> +
> + rq =
Re: [Intel-gfx] [PATCH 5/8] drm/i915/perf: lock powergating configuration to default when active
Hey Tvrtko,
Thanks for taking over this series.
I've been talking to developers using the i915/perf interface and from
their point of view, they expect the system to be in a stable
configuration when doing measurements.
One issue with this patch on Gen11 is that it will lock the system in a
configuration that isn't workable for media workloads (all subslices
enabled).
So I think we should set the value for the locked configuration per
generation (gen8-10: all slices/subslices, gen11: only subslices that
contain VME samplers) so that we always get a functional configurations
for all workloads.
Could we want to select that configuration when opening perf?
Another question is how do we expose the selected value to the user. But
that can be solved in a different series.
Cheers,
-
Lionel
On 14/08/18 15:40, Tvrtko Ursulin wrote:
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
drivers/gpu/drm/i915/i915_perf.c | 23 ++-
drivers/gpu/drm/i915/intel_lrc.c | 11 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
4 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6049c3f911b..5c12d2676435 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3851,4 +3851,19 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline struct intel_sseu
+intel_engine_prepare_sseu(struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ /*
+* If i915/perf is active, we want a stable powergating configuration
+* on the system. The most natural configuration to take in that case
+* is the default (i.e maximum the hardware can do).
+*/
+ return i915->perf.oa.exclusive_stream ?
+ intel_device_default_sseu(i915) : sseu;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ccb20230df2c..c2fc2399e0ed 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1631,7 +1631,8 @@ static void hsw_disable_metric_set(struct
drm_i915_private *dev_priv)
*/
static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 *reg_state,
- const struct i915_oa_config
*oa_config)
+ const struct i915_oa_config
*oa_config,
+ struct intel_sseu sseu)
{
struct drm_i915_private *dev_priv = ctx->i915;
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
@@ -1677,6 +1678,9 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(_INFO(dev_priv)->sseu, sseu));
}
/*
@@ -1807,6 +1811,7 @@ static int
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Add global barrier support
Chris, for this one please let me know if it is okay to give you
authorship and to add your S-o-B.
Tvrtko
On 14/08/2018 15:40, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Global barrier is a facility to allow serialization between different
timelines.
After calling i915_gem_set_global_barrier on a request, all following
submissions on any engine will be set up as depending on this global
barrier. Once the global barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
-
This code was part of the larger SSEU patch but I extracted it to be
separate for ease of review and clarity. I think it originates from Chris
Wilson so permission pending I will change the author and add appropriate
S-o-B.
-
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 27 +++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_request.c | 16
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c12d2676435..643089ba01b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,16 @@ struct drm_i915_private {
u32 active_requests;
u32 request_serial;
+ /**
+* Global barrier for the ability to serialize ordering between
+* different timelines.
+*
+* Users can call i915_gem_set_global_barrier which will make
+* all subsequent submission be execute only after this barrier
+* has been completed.
+*/
+ struct i915_gem_active global_barrier;
+
/**
* Is the GPU currently considered idle, or busy executing
* userspace requests? Whilst idle, we allow runtime power
@@ -3230,6 +3240,23 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
return container_of(vm, struct i915_hw_ppgtt, vm);
}
+/**
+ * i915_gem_set_global_barrier - orders submission on different timelines
+ * @i915: i915 device private
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions, regardless of the engine/timeline. Subsequent requests will not
+ * be submitted to GPU until the global barrier has been completed.
+ */
+static inline void
+i915_gem_set_global_barrier(struct drm_i915_private *i915,
+ struct i915_request *rq)
+{
+ lockdep_assert_held(>drm.struct_mutex);
+ i915_gem_active_set(>gt.global_barrier, rq);
+}
+
/* i915_gem_fence_reg.c */
struct drm_i915_fence_reg *
i915_reserve_fence(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..be462ef65786 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5752,6 +5752,8 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
+ init_request_active(_priv->gt.global_barrier, NULL);
+
INIT_LIST_HEAD(_priv->gt.timelines);
INIT_LIST_HEAD(_priv->gt.active_rings);
INIT_LIST_HEAD(_priv->gt.closed_vma);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 09ed48833b54..8b45f74dc748 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -644,6 +644,18 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static int add_global_barrier(struct i915_request *rq)
+{
+ struct i915_request *barrier;
+
+ barrier = i915_gem_active_raw(>i915->gt.global_barrier,
+ >i915->drm.struct_mutex);
+ if (barrier)
+ return i915_request_await_dma_fence(rq, >fence);
+
+ return 0;
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -806,6 +818,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_global_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
/* Unconditionally invalidate GPU caches and TLBs. */
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
if (ret)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Refind the active request before resetting
== Series Details ==
Series: drm/i915/execlists: Refind the active request before resetting
URL : https://patchwork.freedesktop.org/series/48190/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4666 -> Patchwork_9939 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48190/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9939 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
Possible fixes
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
igt@drv_selftest@live_workarounds:
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL (fdo#107372) -> DMESG-WARN (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (53 -> 48) ==
Additional (1): fi-glk-j4005
Missing(6): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4666 -> Patchwork_9939
CI_DRM_4666: 26f5eeef80e4332958ea855e90a4d015a9481e3f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9939: abcd9f36c4a4a0ef824bc92773504679bbfa7b7b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
abcd9f36c4a4 drm/i915/execlists: Refind the active request before resetting
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9939/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 0/8] Per context dynamic (sub)slice power-gating
On 14/08/18 15:40, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Updated series after continuing Lionel's work. Userspace for the feature is the media-driver project on GitHub. Please see https://github.com/intel/media-driver/pull/271/commits. Headline changes: 1. No more master allow/disallow sysfs switch. Feature is unconditionally enabled for Gen11 and on other platforms it requires CAP_SYS_ADMIN. *** To be discussed if this is a good idea or not. *** 2. Two new patches due a) breaking out the global barrier, and b) fixing one GEM_BUG_ON regarding incorrent kernel context classification by i915_is_ggtt. Otherwise please see individial patch change logs. Main topic for the cover letter though is addressing the question of dynamic slice re-configuration performance impact. Introduction into this problem space is that changing the (sub)slice configuration has a cost at context switch time in the order of tens of milli- seconds. (It varies per Gen and with different slice count transitions.) So the question is whether a malicious unprivileged workload can negatively impact other clients. To try and answer this question I have extended gem_wsim and creating some test workloads. (Note that my testing was done on a Gen9 system. Overall message could be the same on Gen11 but needs to be verified.) First test was a simulated video playback client running in parallel with a simulated game of both medium and high complexity (uses around 60% or 90% of the render engine respectively, and 7% of the blitter engine). I had two flavours of the playback client, one which runs normally and one which requests reduced slice configuration. Both workloads are targetting to run at 60fps. Second test is the same but against a heavier simulated game workload, the one which uses around 90% of the render engine. Results are achieved frames per second as observed from the game client: No player Normal player SSEU enabled player Medium game 59.659.6 59.6 Heavy game 59.758.4 58.1 Here we can see that the medium workload was not affected either by the normal or SSEU player, while the heavy workload did see a performance hit. Both with the video player running in parallel, and slighlty larger when the player was SSEU enabled. Second test is running a malicious client (or clients) in parallel to the same simulated game workloads. These clients try to trigger many context switches by using multiple contexts with dependencies set up so request coalescing is defeated as much as possible. I tested both with normal and SSEU enabled malicious clients: DoS client SSEU DoS client Medium game 59.5 59.6 Heavy game 57.8 55.4 For here we can see a similar picture as with the first test. Medium game client is not affected by either DoS client, while the heavy game client is, more so with the SSEU enabled attacker. From both tests I think the conclusion is that dynamic SSEU switching does increase the magnitude of performance loss, especially with over-subscribed engines, due cost being proportional to context switch frequency. Likelyhood is that it slightly lowers the utilization level at which this starts to happen, but does not introduce a completely new vector of attack - that is - where it was possible to DoS a system from an unprivileged client, it still is. In both cases (SSEU enabled or not), a malicious client has the option to grind the system to a halt, albeit it may need fewer submission threads to do so when it is SSEU enabled. For reference, gem_wsim workloads used to test this (even though the number of people familiar with them is quite low): Medium game workload: 1.RCS.1000-2000.0.0 1.RCS.1000-2000.0.0 1.RCS.1000-2000.0.0 1.RCS.1000-2000.0.0 1.RCS.1000-2000.0.0 P.2.1 2.BCS.1000.-2.0 2.RCS.2000.-1.1 p.16667 Heavy game workload: 1.RCS.500.0.0 1.RCS.2000.0.0 1.RCS.2000.0.0 1.RCS.2000.0.0 1.RCS.2000.0.0 1.RCS.2000.0.0 1.RCS.2000.0.0 P.2.1 2.BCS.1000.-2.0 2.RCS.2000.-1.1 p.16667 Normal video player: 1.VCS.5000-1.0.0 2.RCS.1000-2000.-1.0 P.3.1 3.BCS.1000.-2.0 p.16667 SSEU enabled video player: S.1.1 S.2.1 1.VCS.5000-1.0.0 2.RCS.1000-2000.-1.0 P.3.1 3.BCS.1000.-2.0 p.16667 Malicious client: 1.RCS.1.0.0 2.RCS.1.-1.0 SSEU enabled malicious client: S.2.1 1.RCS.1.0.0 2.RCS.1.-1.0 Regards, Tvrtko Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (3): drm/i915/perf: simplify configure all context function drm/i915/perf: reuse intel_lrc ctx regs macro drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (2): drm/i915: Add global barrier support drm/i915: Explicitly mark Global GTT address spaces
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Before a reset, we set the STOP_RING bit of RING_MI_MODE to freeze the
engine. However, sometimes we observe that upon restart, the engine
freezes again with the STOP_RING bit still asserted. By inspection, we
know that the register itself is cleared by the GPU reset, so that bit
must be preserved inside the context image and reloaded from there. A
simple fix (as the RING_MI_MODE is at a fixed offset in a valid context)
is to clobber the STOP_RING bit inside the image before replaying the
request.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michel Thierry
Cc: Michał Winiarski
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 17 +++--
drivers/gpu/drm/i915/intel_lrc_reg.h | 2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f90c74038ef..37fe842de639 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1918,6 +1918,20 @@ static void execlists_reset(struct intel_engine_cs
*engine,
spin_unlock_irqrestore(>timeline.lock, flags);
+ if (!request)
+ return;
+
+ regs = request->hw_context->lrc_reg_state;
+
+ /*
+* After a reset, the context may have preserved the STOP bit
+* of RING_MI_MODE we used to freeze the active engine before
+* the reset. If that bit is restored the ring stops instead
+* of being executed.
+*/
+ regs[CTX_MI_MODE + 1] |= STOP_RING << 16;
+ regs[CTX_MI_MODE + 1] &= ~STOP_RING;
+
/*
* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
@@ -1929,7 +1943,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* and have to at least restore the RING register in the context
* image back to the expected values to skip over the guilty request.
*/
- if (!request || request->fence.error != -EIO)
+ if (request->fence.error != -EIO)
return;
/*
@@ -1940,7 +1954,6 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* future request will be after userspace has had the opportunity
* to recreate its own state.
*/
- regs = request->hw_context->lrc_reg_state;
if (engine->pinned_default_state) {
memcpy(regs, /* skip restoring the vanilla PPHWSP */
engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h
b/drivers/gpu/drm/i915/intel_lrc_reg.h
index 5ef932d810a7..3b155ecbfa92 100644
--- a/drivers/gpu/drm/i915/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -39,6 +39,8 @@
#define CTX_R_PWR_CLK_STATE0x42
#define CTX_END0x44
+#define CTX_MI_MODE0x54
+
#define CTX_REG(reg_state, pos, reg, val) do { \
u32 *reg_state__ = (reg_state); \
const u32 pos__ = (pos); \
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Refind the active request before resetting
When resetting the context image after a GPU reset, it is vital that we
do inspect the context image that was active at the time of the hang.
Even a 'pardoned' context may still have some residual corruption (e.g.
the STOP_RING bit) from issuing the GPU reset that we need to fixup
before continuing.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 37fe842de639..246daacb545e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -322,9 +322,10 @@ static void unwind_wa_tail(struct i915_request *rq)
assert_ring_tail_valid(rq->ring, rq->tail);
}
-static void __unwind_incomplete_requests(struct intel_engine_cs *engine)
+static struct i915_request *
+__unwind_incomplete_requests(struct intel_engine_cs *engine)
{
- struct i915_request *rq, *rn;
+ struct i915_request *rq, *rn, *active = NULL;
struct i915_priolist *uninitialized_var(p);
int last_prio = I915_PRIORITY_INVALID;
@@ -334,7 +335,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
>timeline.requests,
link) {
if (i915_request_completed(rq))
- return;
+ break;
__i915_request_unsubmit(rq);
unwind_wa_tail(rq);
@@ -347,7 +348,11 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
GEM_BUG_ON(p->priority != rq_prio(rq));
list_add(>sched.link, >requests);
+
+ active = rq;
}
+
+ return active;
}
void
@@ -1911,7 +1916,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
execlists_cancel_port_requests(execlists);
/* Push back any incomplete requests for replay after the reset. */
- __unwind_incomplete_requests(engine);
+ request = __unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
reset_csb_pointers(>execlists);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915/perf: reuse intel_lrc ctx regs macro
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 49597cf31707..ccb20230df2c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
-(dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
-GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
+ for (i = 0; i < ARRAY_SIZE(flex_regs); i++) {
u32 state_offset = ctx_flexeu0 + i * 2;
- u32 mmio = flex_mmio[i];
+ u32 mmio = i915_mmio_reg_offset(flex_regs[i]);
/*
* This arbitrary default will select the 'EU FPU0 Pipeline
@@ -1676,8 +1675,7 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
}
}
- reg_state[state_offset] = mmio;
- reg_state[state_offset+1] = value;
+ CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/perf: simplify configure all context function
From: Lionel Landwerlin
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0376338d1f8d..49597cf31707 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1819,7 +1819,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
if (ret)
- goto out;
+ return ret;
/*
* The OA register config is setup through the context image. This image
@@ -1838,7 +1838,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
wait_flags,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto out;
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, _priv->contexts.list, link) {
@@ -1850,10 +1850,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
continue;
regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
- if (IS_ERR(regs)) {
- ret = PTR_ERR(regs);
- goto out;
- }
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
@@ -1863,7 +1861,6 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
i915_gem_object_unpin_map(ce->state->obj);
}
- out:
return ret;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Program RPCS for Broadwell
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f90c74038ef..d3ffb268a7a1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2489,13 +2489,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
{
u32 rpcs = 0;
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_GEN(dev_priv) < 9)
- return 0;
-
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 0/8] Per context dynamic (sub)slice power-gating
From: Tvrtko Ursulin Updated series after continuing Lionel's work. Userspace for the feature is the media-driver project on GitHub. Please see https://github.com/intel/media-driver/pull/271/commits. Headline changes: 1. No more master allow/disallow sysfs switch. Feature is unconditionally enabled for Gen11 and on other platforms it requires CAP_SYS_ADMIN. *** To be discussed if this is a good idea or not. *** 2. Two new patches due a) breaking out the global barrier, and b) fixing one GEM_BUG_ON regarding incorrent kernel context classification by i915_is_ggtt. Otherwise please see individial patch change logs. Main topic for the cover letter though is addressing the question of dynamic slice re-configuration performance impact. Introduction into this problem space is that changing the (sub)slice configuration has a cost at context switch time in the order of tens of milli- seconds. (It varies per Gen and with different slice count transitions.) So the question is whether a malicious unprivileged workload can negatively impact other clients. To try and answer this question I have extended gem_wsim and creating some test workloads. (Note that my testing was done on a Gen9 system. Overall message could be the same on Gen11 but needs to be verified.) First test was a simulated video playback client running in parallel with a simulated game of both medium and high complexity (uses around 60% or 90% of the render engine respectively, and 7% of the blitter engine). I had two flavours of the playback client, one which runs normally and one which requests reduced slice configuration. Both workloads are targetting to run at 60fps. Second test is the same but against a heavier simulated game workload, the one which uses around 90% of the render engine. Results are achieved frames per second as observed from the game client: No player Normal player SSEU enabled player Medium game 59.659.6 59.6 Heavy game 59.758.4 58.1 Here we can see that the medium workload was not affected either by the normal or SSEU player, while the heavy workload did see a performance hit. Both with the video player running in parallel, and slighlty larger when the player was SSEU enabled. Second test is running a malicious client (or clients) in parallel to the same simulated game workloads. These clients try to trigger many context switches by using multiple contexts with dependencies set up so request coalescing is defeated as much as possible. I tested both with normal and SSEU enabled malicious clients: DoS client SSEU DoS client Medium game 59.5 59.6 Heavy game 57.8 55.4 For here we can see a similar picture as with the first test. Medium game client is not affected by either DoS client, while the heavy game client is, more so with the SSEU enabled attacker. From both tests I think the conclusion is that dynamic SSEU switching does increase the magnitude of performance loss, especially with over-subscribed engines, due cost being proportional to context switch frequency. Likelyhood is that it slightly lowers the utilization level at which this starts to happen, but does not introduce a completely new vector of attack - that is - where it was possible to DoS a system from an unprivileged client, it still is. In both cases (SSEU enabled or not), a malicious client has the option to grind the system to a halt, albeit it may need fewer submission threads to do so when it is SSEU enabled. Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (3): drm/i915/perf: simplify configure all context function drm/i915/perf: reuse intel_lrc ctx regs macro drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (2): drm/i915: Add global barrier support drm/i915: Explicitly mark Global GTT address spaces drivers/gpu/drm/i915/i915_drv.h | 56 +++ drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_context.c | 189 +++- drivers/gpu/drm/i915/i915_gem_context.h | 4 + drivers/gpu/drm/i915/i915_gem_gtt.c | 2 + drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +- drivers/gpu/drm/i915/i915_perf.c| 68 + drivers/gpu/drm/i915/i915_request.c | 16 ++ drivers/gpu/drm/i915/i915_request.h | 10 ++ drivers/gpu/drm/i915/intel_lrc.c| 87 --- drivers/gpu/drm/i915/intel_lrc.h| 3 + drivers/gpu/drm/i915/intel_ringbuffer.h | 4 + include/uapi/drm/i915_drm.h | 43 ++ 13 files changed, 439 insertions(+), 50 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t)
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Cc: Dmitry Rogozhkin
Cc: Tvrtko Ursulin
Cc: Zhipeng Gong
Cc: Joonas Lahtinen
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 187 +++-
drivers/gpu/drm/i915/intel_lrc.c| 55 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 43 ++
4 files changed, 288 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8a12984e7495..6d6220634e9e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -773,6 +773,91 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ struct i915_request *rq;
+ struct intel_ring *ring;
+ int ret;
+
+ lockdep_assert_held(>drm.struct_mutex);
+
+ /* Submitting requests etc needs the hw awake. */
+ intel_runtime_pm_get(i915);
+
+ i915_retire_requests(i915);
+
+ /* Now use the RCS to actually reconfigure. */
+ engine = i915->engine[RCS];
+
+ rq = i915_request_alloc(engine, i915->kernel_context);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ goto out_put;
+ }
+
+ ret = engine->emit_rpcs_config(rq, ctx, sseu);
+ if (ret)
+ goto out_add;
+
+ /* Queue this switch after all other activity */
+ list_for_each_entry(ring, >gt.active_rings,
[Intel-gfx] [PATCH 7/8] drm/i915: Explicitly mark Global GTT address spaces
From: Tvrtko Ursulin
So far we have been relying on vm->file pointer being NULL to declare
something GGTT.
This has the unfortunate consequence that the default kernel context is
also declared GGTT and interferes with the following patch which wants to
instantiate VMA's and execute requests against the kernel context.
Change the is_ggtt test to use an explicit flag in struct address_space to
solve this issue.
Note that the bit used is free since there is an alignment hole in the
struct.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4137af4bd8f5..64151ad2a02b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3610,6 +3610,8 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
mutex_lock(_priv->drm.struct_mutex);
i915_address_space_init(>vm, dev_priv);
+ ggtt->vm.is_ggtt = true;
+
/* Only VLV supports read-only GGTT mappings */
ggtt->vm.has_read_only = IS_VALLEYVIEW(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index dd161c187a68..d8dd4d9280bd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -331,6 +331,9 @@ struct i915_address_space {
struct pagestash free_pages;
+ /* Global GTT */
+ bool is_ggtt:1;
+
/* Some systems require uncached updates of the page directories */
bool pt_kmap_wc:1;
@@ -364,7 +367,7 @@ struct i915_address_space {
I915_SELFTEST_DECLARE(bool scrub_64K);
};
-#define i915_is_ggtt(V) (!(V)->file)
+#define i915_is_ggtt(vm) ((vm)->is_ggtt)
static inline bool
i915_vm_is_48bit(const struct i915_address_space *vm)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/perf: lock powergating configuration to default when active
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
drivers/gpu/drm/i915/i915_perf.c | 23 ++-
drivers/gpu/drm/i915/intel_lrc.c | 11 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
4 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6049c3f911b..5c12d2676435 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3851,4 +3851,19 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline struct intel_sseu
+intel_engine_prepare_sseu(struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ /*
+* If i915/perf is active, we want a stable powergating configuration
+* on the system. The most natural configuration to take in that case
+* is the default (i.e maximum the hardware can do).
+*/
+ return i915->perf.oa.exclusive_stream ?
+ intel_device_default_sseu(i915) : sseu;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ccb20230df2c..c2fc2399e0ed 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1631,7 +1631,8 @@ static void hsw_disable_metric_set(struct
drm_i915_private *dev_priv)
*/
static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 *reg_state,
- const struct i915_oa_config
*oa_config)
+ const struct i915_oa_config
*oa_config,
+ struct intel_sseu sseu)
{
struct drm_i915_private *dev_priv = ctx->i915;
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
@@ -1677,6 +1678,9 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(_INFO(dev_priv)->sseu, sseu));
}
/*
@@ -1807,6 +1811,7 @@ static int gen8_switch_to_updated_kernel_context(struct
drm_i915_private *dev_pr
static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
const struct i915_oa_config *oa_config)
{
+ struct intel_sseu default_sseu = intel_device_default_sseu(dev_priv);
struct intel_engine_cs *engine = dev_priv->engine[RCS];
struct i915_gem_context *ctx;
int ret;
@@ -1854,7 +1859,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
- gen8_update_reg_state_unlocked(ctx, regs, oa_config);
+ gen8_update_reg_state_unlocked(ctx, regs, oa_config,
+ oa_config ? default_sseu :
ce->sseu);
[Intel-gfx] [PATCH 2/8] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10 ++
drivers/gpu/drm/i915/intel_lrc.c| 22 +++---
5 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5fa13887b911..d6049c3f911b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3445,6 +3445,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)_priv->info;
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = _INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f15a039772db..8a12984e7495 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -291,6 +291,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = >__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(dev_priv);
}
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 851dad6decd7..1e51c2a46644 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -157,6 +158,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 9898301ab7ef..eb6f8cce16c4 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d3ffb268a7a1..7b2f2d6bb057 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2484,8 +2484,8 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu,
+struct intel_sseu ctx_sseu)
{
u32 rpcs = 0;
@@ -2495,24 +2495,23 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu.slice_mask) <<
[Intel-gfx] [PATCH 6/8] drm/i915: Add global barrier support
From: Tvrtko Ursulin
Global barrier is a facility to allow serialization between different
timelines.
After calling i915_gem_set_global_barrier on a request, all following
submissions on any engine will be set up as depending on this global
barrier. Once the global barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
-
This code was part of the larger SSEU patch but I extracted it to be
separate for ease of review and clarity. I think it originates from Chris
Wilson so permission pending I will change the author and add appropriate
S-o-B.
-
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 27 +++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_request.c | 16
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c12d2676435..643089ba01b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,16 @@ struct drm_i915_private {
u32 active_requests;
u32 request_serial;
+ /**
+* Global barrier for the ability to serialize ordering between
+* different timelines.
+*
+* Users can call i915_gem_set_global_barrier which will make
+* all subsequent submission be execute only after this barrier
+* has been completed.
+*/
+ struct i915_gem_active global_barrier;
+
/**
* Is the GPU currently considered idle, or busy executing
* userspace requests? Whilst idle, we allow runtime power
@@ -3230,6 +3240,23 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
return container_of(vm, struct i915_hw_ppgtt, vm);
}
+/**
+ * i915_gem_set_global_barrier - orders submission on different timelines
+ * @i915: i915 device private
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions, regardless of the engine/timeline. Subsequent requests will not
+ * be submitted to GPU until the global barrier has been completed.
+ */
+static inline void
+i915_gem_set_global_barrier(struct drm_i915_private *i915,
+ struct i915_request *rq)
+{
+ lockdep_assert_held(>drm.struct_mutex);
+ i915_gem_active_set(>gt.global_barrier, rq);
+}
+
/* i915_gem_fence_reg.c */
struct drm_i915_fence_reg *
i915_reserve_fence(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0453eb42a1a3..be462ef65786 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5752,6 +5752,8 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
+ init_request_active(_priv->gt.global_barrier, NULL);
+
INIT_LIST_HEAD(_priv->gt.timelines);
INIT_LIST_HEAD(_priv->gt.active_rings);
INIT_LIST_HEAD(_priv->gt.closed_vma);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 09ed48833b54..8b45f74dc748 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -644,6 +644,18 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static int add_global_barrier(struct i915_request *rq)
+{
+ struct i915_request *barrier;
+
+ barrier = i915_gem_active_raw(>i915->gt.global_barrier,
+ >i915->drm.struct_mutex);
+ if (barrier)
+ return i915_request_await_dma_fence(rq, >fence);
+
+ return 0;
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -806,6 +818,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_global_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
/* Unconditionally invalidate GPU caches and TLBs. */
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
if (ret)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Before a reset, we set the STOP_RING bit of RING_MI_MODE to freeze the
engine. However, sometimes we observe that upon restart, the engine
freezes again with the STOP_RING bit still asserted. By inspection, we
know that the register itself is cleared by the GPU reset, so that bit
must be preserved inside the context image and reloaded from there. A
simple fix (as the RING_MI_MODE is at a fixed offset in a valid context)
is to clobber the STOP_RING bit inside the image before replaying the
request.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michel Thierry
Cc: Michał Winiarski
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 17 +++--
drivers/gpu/drm/i915/intel_lrc_reg.h | 2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f90c74038ef..37fe842de639 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1918,6 +1918,20 @@ static void execlists_reset(struct intel_engine_cs
*engine,
spin_unlock_irqrestore(>timeline.lock, flags);
+ if (!request)
+ return;
+
+ regs = request->hw_context->lrc_reg_state;
+
+ /*
+* After a reset, the context may have preserved the STOP bit
+* of RING_MI_MODE we used to freeze the active engine before
+* the reset. If that bit is restored the ring stops instead
+* of being executed.
+*/
+ regs[CTX_MI_MODE + 1] |= STOP_RING << 16;
+ regs[CTX_MI_MODE + 1] &= ~STOP_RING;
+
/*
* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
@@ -1929,7 +1943,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* and have to at least restore the RING register in the context
* image back to the expected values to skip over the guilty request.
*/
- if (!request || request->fence.error != -EIO)
+ if (request->fence.error != -EIO)
return;
/*
@@ -1940,7 +1954,6 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* future request will be after userspace has had the opportunity
* to recreate its own state.
*/
- regs = request->hw_context->lrc_reg_state;
if (engine->pinned_default_state) {
memcpy(regs, /* skip restoring the vanilla PPHWSP */
engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h
b/drivers/gpu/drm/i915/intel_lrc_reg.h
index 5ef932d810a7..3b155ecbfa92 100644
--- a/drivers/gpu/drm/i915/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -39,6 +39,8 @@
#define CTX_R_PWR_CLK_STATE0x42
#define CTX_END0x44
+#define CTX_MI_MODE0x54
+
#define CTX_REG(reg_state, pos, reg, val) do { \
u32 *reg_state__ = (reg_state); \
const u32 pos__ = (pos); \
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Refind the active request before resetting
When resetting the context image after a GPU reset, it is vital that we do inspect the context image that was active at the time of the hang. Even a 'pardoned' context may still have some residual corruption (e.g. the STOP_RING bit) from issuing the GPU reset that we need to fixup before continuing. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 37fe842de639..de0cde3a19f6 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1918,6 +1918,8 @@ static void execlists_reset(struct intel_engine_cs *engine, spin_unlock_irqrestore(>timeline.lock, flags); + /* Only adjust the actual context image clobbered by the reset */ + request = i915_gem_find_active_request(engine); if (!request) return; -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] igt/pm_rpm: Test reaquisition of runtime-pm after module reload
On Fri, Aug 10, 2018 at 08:01:16AM +0100, Chris Wilson wrote:
> It doesn't work right now and desperately needs to be fixed...
>
> Signed-off-by: Chris Wilson
On both patches:
Reviewed-by: Imre Deak
> ---
> tests/intel-ci/fast-feedback.testlist | 1 +
> tests/pm_rpm.c| 28 ---
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/tests/intel-ci/fast-feedback.testlist
> b/tests/intel-ci/fast-feedback.testlist
> index 1f3b95357..c625904d5 100644
> --- a/tests/intel-ci/fast-feedback.testlist
> +++ b/tests/intel-ci/fast-feedback.testlist
> @@ -272,3 +272,4 @@ igt@vgem_basic@unload
> igt@drv_module_reload@basic-reload
> igt@drv_module_reload@basic-no-display
> igt@drv_module_reload@basic-reload-inject
> +igt@pm_rpm@module-reload
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index 1fbdda4ed..79cdf969a 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -692,7 +692,7 @@ static void setup_pc8(void)
> has_pc8 = true;
> }
>
> -static void setup_environment(void)
> +static bool setup_environment(void)
> {
> drm_fd = drm_open_driver_master(DRIVER_INTEL);
> debugfs = igt_debugfs_dir(drm_fd);
> @@ -710,7 +710,7 @@ static void setup_environment(void)
> igt_require(has_runtime_pm);
>
> disable_all_screens(_data);
> - igt_require(wait_for_suspended());
> + return wait_for_suspended();
> }
>
> static void restore_environment(void)
> @@ -1905,7 +1905,7 @@ int main(int argc, char *argv[])
>* PC8+. We don't want bug reports from cases where the machine is just
>* not properly configured. */
> igt_fixture
> - setup_environment();
> + igt_require(setup_environment());
>
> if (stay)
> igt_subtest("stay")
> @@ -2026,5 +2026,27 @@ int main(int argc, char *argv[])
> igt_fixture
> teardown_environment();
>
> + igt_subtest("module-reload") {
> + igt_debug("Reload w/o display\n");
> + igt_i915_driver_unload();
> + igt_assert_eq(igt_i915_driver_load("disable_display=1"), 0);
> +
> + igt_assert(setup_environment());
> + basic_subtest();
> + drm_resources_equal_subtest();
> + pci_d3_state_subtest();
> + teardown_environment();
> +
> + igt_debug("Reload as normal\n");
> + igt_i915_driver_unload();
> + igt_assert_eq(igt_i915_driver_load(NULL), 0);
> +
> + igt_assert(setup_environment());
> + basic_subtest();
> + drm_resources_equal_subtest();
> + pci_d3_state_subtest();
> + teardown_environment();
> + }
> +
> igt_exit();
> }
> --
> 2.18.0
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Refind the active request before resetting
When resetting the context image after a GPU reset, it is vital that we
do inspect the context image that was active at the time of the hang.
Even a 'pardoned' context may still have some residual corruption (e.g.
the STOP_RING bit) from issuing the GPU reset that we need to fixup
before continuing.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 37fe842de639..246daacb545e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -322,9 +322,10 @@ static void unwind_wa_tail(struct i915_request *rq)
assert_ring_tail_valid(rq->ring, rq->tail);
}
-static void __unwind_incomplete_requests(struct intel_engine_cs *engine)
+static struct i915_request *
+__unwind_incomplete_requests(struct intel_engine_cs *engine)
{
- struct i915_request *rq, *rn;
+ struct i915_request *rq, *rn, *active = NULL;
struct i915_priolist *uninitialized_var(p);
int last_prio = I915_PRIORITY_INVALID;
@@ -334,7 +335,7 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
>timeline.requests,
link) {
if (i915_request_completed(rq))
- return;
+ break;
__i915_request_unsubmit(rq);
unwind_wa_tail(rq);
@@ -347,7 +348,11 @@ static void __unwind_incomplete_requests(struct
intel_engine_cs *engine)
GEM_BUG_ON(p->priority != rq_prio(rq));
list_add(>sched.link, >requests);
+
+ active = rq;
}
+
+ return active;
}
void
@@ -1911,7 +1916,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
execlists_cancel_port_requests(execlists);
/* Push back any incomplete requests for replay after the reset. */
- __unwind_incomplete_requests(engine);
+ request = __unwind_incomplete_requests(engine);
/* Following the reset, we need to reload the CSB read/write pointers */
reset_csb_pointers(>execlists);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] igt/pm_rpm: Test incomplete(debug) suspends vs rpm
Quoting Imre Deak (2018-08-14 14:52:16)
> On Fri, Aug 10, 2018 at 08:01:15AM +0100, Chris Wilson wrote:
> > Check that we restore runtime pm around debug suspends and hibernates.
> >
> > v2: Differentiate between external test setup failure and one of
> > interest
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/pm_rpm.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> > index 4268bb19a..1fbdda4ed 100644
> > --- a/tests/pm_rpm.c
> > +++ b/tests/pm_rpm.c
> > @@ -707,8 +707,10 @@ static void setup_environment(void)
> >
> > igt_info("Runtime PM support: %d\n", has_runtime_pm);
> > igt_info("PC8 residency support: %d\n", has_pc8);
> > -
> > igt_require(has_runtime_pm);
> > +
> > + disable_all_screens(_data);
> > + igt_require(wait_for_suspended());
>
> For some subtests (e.g. basic-rte) this check is the only (real)
> purpose. So shouldn't this be added to specific subtests instead (e.g.
> the system suspend ones) to avoid converting fail to skip?
The flip flop from PASS/SKIP is still significant, so I don't worry too
much. With a little tweak, it shall be done.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] igt/pm_rpm: Test incomplete(debug) suspends vs rpm
On Fri, Aug 10, 2018 at 08:01:15AM +0100, Chris Wilson wrote:
> Check that we restore runtime pm around debug suspends and hibernates.
>
> v2: Differentiate between external test setup failure and one of
> interest
>
> Signed-off-by: Chris Wilson
> ---
> tests/pm_rpm.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index 4268bb19a..1fbdda4ed 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -707,8 +707,10 @@ static void setup_environment(void)
>
> igt_info("Runtime PM support: %d\n", has_runtime_pm);
> igt_info("PC8 residency support: %d\n", has_pc8);
> -
> igt_require(has_runtime_pm);
> +
> + disable_all_screens(_data);
> + igt_require(wait_for_suspended());
For some subtests (e.g. basic-rte) this check is the only (real)
purpose. So shouldn't this be added to specific subtests instead (e.g.
the system suspend ones) to avoid converting fail to skip?
Otherwise looks ok.
> }
>
> static void restore_environment(void)
> @@ -1372,10 +1374,11 @@ static void __attribute__((noreturn))
> stay_subtest(void)
> sleep(600);
> }
>
> -static void system_suspend_subtest(void)
> +static void system_suspend_subtest(int state, int debug)
> {
> disable_all_screens_and_wait(_data);
> - igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
> +
> + igt_system_suspend_autoresume(state, debug);
> igt_assert(wait_for_suspended());
> }
>
> @@ -1992,12 +1995,19 @@ int main(int argc, char *argv[])
> WAIT_STATUS | WAIT_EXTRA);
>
> /* System suspend */
> + igt_subtest("system-suspend-devices")
> + system_suspend_subtest(SUSPEND_STATE_MEM, SUSPEND_TEST_DEVICES);
> igt_subtest("system-suspend")
> - system_suspend_subtest();
> + system_suspend_subtest(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
> igt_subtest("system-suspend-execbuf")
> system_suspend_execbuf_subtest();
> igt_subtest("system-suspend-modeset")
> system_suspend_modeset_subtest();
> + igt_subtest("system-hibernate-devices")
> + system_suspend_subtest(SUSPEND_STATE_DISK,
> +SUSPEND_TEST_DEVICES);
> + igt_subtest("system-hibernate")
> + system_suspend_subtest(SUSPEND_STATE_DISK, SUSPEND_TEST_NONE);
>
> /* GEM stress */
> igt_subtest("gem-execbuf-stress")
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Clear STOP_RING bit before restoring the context
== Series Details ==
Series: drm/i915/execlists: Clear STOP_RING bit before restoring the context
URL : https://patchwork.freedesktop.org/series/48187/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4665 -> Patchwork_9938 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48187/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9938 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-kbl-7567u: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: PASS -> FAIL (fdo#103167)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
igt@drv_selftest@live_workarounds:
fi-cnl-psr: DMESG-FAIL (fdo#107292) -> PASS
fi-skl-6700k2: DMESG-FAIL (fdo#107292) -> PASS
igt@kms_chamelium@dp-crc-fast:
fi-kbl-7500u: DMESG-FAIL (fdo#103841) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL (fdo#107372) -> DMESG-WARN (fdo#107372)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
== Participating hosts (54 -> 49) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4665 -> Patchwork_9938
CI_DRM_4665: 3a43bf5efa33be9f88d70427dbfba4db4377eaf6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9938: 3155a2f9cb8cd0b001fbaae9ab67afa10051d1d8 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3155a2f9cb8c drm/i915/execlists: Clear STOP_RING bit before restoring the
context
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9938/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Quoting Mika Kuoppala (2018-08-14 14:42:41) > Chris Wilson writes: > > > Before a reset, we set the STOP_RING bit of RING_MI_MODE to freeze the > > engine. However, sometimes we observe that upon restart, the engine > > freezes again with the STOP_RING bit still asserted. By inspection, we > > know that the register itself is cleared by the GPU reset, so that bit > > must be preserved inside the context image and reloaded from there. A > > simple fix (as the RING_MI_MODE is at a fixed offset in a valid context) > > is to clobber the STOP_RING bit inside the image before replaying the > > request. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Michel Thierry > > Cc: Michał Winiarski > > --- > > drivers/gpu/drm/i915/intel_lrc.c | 17 +++-- > > drivers/gpu/drm/i915/intel_lrc_reg.h | 2 ++ > > 2 files changed, 17 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > > b/drivers/gpu/drm/i915/intel_lrc.c > > index 3f90c74038ef..37fe842de639 100644 > > --- a/drivers/gpu/drm/i915/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -1918,6 +1918,20 @@ static void execlists_reset(struct intel_engine_cs > > *engine, > > > > spin_unlock_irqrestore(>timeline.lock, flags); > > > > + if (!request) > > + return; > > + > > + regs = request->hw_context->lrc_reg_state; > > + > > + /* > > + * After a reset, the context may have preserved the STOP bit > > + * of RING_MI_MODE we used to freeze the active engine before > > + * the reset. If that bit is restored the ring stops instead > > + * of being executed. > > + */ > > + regs[CTX_MI_MODE + 1] |= STOP_RING << 16; > > + regs[CTX_MI_MODE + 1] &= ~STOP_RING; > > Ok, I did go and pondered if this is truely the simplest > way. Forcing the start outside a context would not > be simpler and would be slower. > > Nice find and it will has potential to explain our some troubles > of re-enabling engines. > > Did you find out this by looking at the error states or what? We're dumping sufficient info between the set-wedged and GEM_TRACE to track the MI_MODE bits; e.g. commit 9a4dc80399b1630cea0f1ad8ef0417436cbb95d0 Author: Chris Wilson Date: Fri May 18 11:09:33 2018 +0100 drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0x_] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338]
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Quoting Chris Wilson (2018-08-14 14:11:50) > Before a reset, we set the STOP_RING bit of RING_MI_MODE to freeze the > engine. However, sometimes we observe that upon restart, the engine > freezes again with the STOP_RING bit still asserted. By inspection, we > know that the register itself is cleared by the GPU reset, so that bit > must be preserved inside the context image and reloaded from there. A > simple fix (as the RING_MI_MODE is at a fixed offset in a valid context) > is to clobber the STOP_RING bit inside the image before replaying the > request. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Michel Thierry > Cc: Michał Winiarski Note that we need to improve the active request tracking before this is 100% reliable. One patch at a time; though you can look at the i915_reset.c restructuring series to see what I have in mind. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Chris Wilson writes:
> Before a reset, we set the STOP_RING bit of RING_MI_MODE to freeze the
> engine. However, sometimes we observe that upon restart, the engine
> freezes again with the STOP_RING bit still asserted. By inspection, we
> know that the register itself is cleared by the GPU reset, so that bit
> must be preserved inside the context image and reloaded from there. A
> simple fix (as the RING_MI_MODE is at a fixed offset in a valid context)
> is to clobber the STOP_RING bit inside the image before replaying the
> request.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Michel Thierry
> Cc: Michał Winiarski
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 17 +++--
> drivers/gpu/drm/i915/intel_lrc_reg.h | 2 ++
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3f90c74038ef..37fe842de639 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1918,6 +1918,20 @@ static void execlists_reset(struct intel_engine_cs
> *engine,
>
> spin_unlock_irqrestore(>timeline.lock, flags);
>
> + if (!request)
> + return;
> +
> + regs = request->hw_context->lrc_reg_state;
> +
> + /*
> + * After a reset, the context may have preserved the STOP bit
> + * of RING_MI_MODE we used to freeze the active engine before
> + * the reset. If that bit is restored the ring stops instead
> + * of being executed.
> + */
> + regs[CTX_MI_MODE + 1] |= STOP_RING << 16;
> + regs[CTX_MI_MODE + 1] &= ~STOP_RING;
Ok, I did go and pondered if this is truely the simplest
way. Forcing the start outside a context would not
be simpler and would be slower.
Nice find and it will has potential to explain our some troubles
of re-enabling engines.
Did you find out this by looking at the error states or what?
Reviewed-by: Mika Kuoppala
> +
> /*
>* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
> @@ -1929,7 +1943,7 @@ static void execlists_reset(struct intel_engine_cs
> *engine,
>* and have to at least restore the RING register in the context
>* image back to the expected values to skip over the guilty request.
>*/
> - if (!request || request->fence.error != -EIO)
> + if (request->fence.error != -EIO)
> return;
>
> /*
> @@ -1940,7 +1954,6 @@ static void execlists_reset(struct intel_engine_cs
> *engine,
>* future request will be after userspace has had the opportunity
>* to recreate its own state.
>*/
> - regs = request->hw_context->lrc_reg_state;
> if (engine->pinned_default_state) {
> memcpy(regs, /* skip restoring the vanilla PPHWSP */
> engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
> diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h
> b/drivers/gpu/drm/i915/intel_lrc_reg.h
> index 5ef932d810a7..3b155ecbfa92 100644
> --- a/drivers/gpu/drm/i915/intel_lrc_reg.h
> +++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
> @@ -39,6 +39,8 @@
> #define CTX_R_PWR_CLK_STATE 0x42
> #define CTX_END 0x44
>
> +#define CTX_MI_MODE 0x54
> +
> #define CTX_REG(reg_state, pos, reg, val) do { \
> u32 *reg_state__ = (reg_state); \
> const u32 pos__ = (pos); \
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: set DP Main Stream Attribute for color range on DDI platforms
On Tue, Aug 14, 2018 at 09:00:01AM +0300, Jani Nikula wrote:
> Since Haswell we have no color range indication either in the pipe or
> port registers for DP. Instead, there's a separate register for setting
> the DP Main Stream Attributes (MSA) directly. The MSA register
> definition makes no references to colorimetry, just a vague reference to
> the DP spec. The connection to the color range was lost.
>
> Apparently we've failed to set the proper MSA bit for limited, or CEA,
> range ever since the first DDI platforms. We've started setting other
> MSA parameters since commit dae847991a43 ("drm/i915: add
> intel_ddi_set_pipe_settings").
>
> Without the crucial bit of information, the DP sink has no way of
> knowing the source is actually transmitting limited range RGB, leading
> to "washed out" colors. With the colorimetry information, compliant
> sinks should be able to handle the limited range properly. Native
> (i.e. non-LSPCON) HDMI was not affected because we do pass the color
> range via AVI infoframes.
>
> Though not the root cause, the problem was made worse for DDI platforms
> with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the
> "Broadcast RGB" property"), which selects limited range RGB
> automatically based on the mode, as per the DP, HDMI and CEA specs.
>
> After all these years, the fix boils down to flipping one bit.
>
> [Per testing reports, this fixes DP sinks, but not the LSPCON. My
> educated guess is that the LSPCON fails to turn the CEA range MSA into
> AVI infoframes for HDMI.]
>
> Reported-by: Michał Kopeć
> Reported-by: N. W.
> Reported-by: Nicholas Stommel
> Reported-by: Tom Yan
> Tested-by: Nicholas Stommel
> References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Cc: # v3.9+
> Signed-off-by: Jani Nikula
wow! and that was hard to review as well...
I finally found the bit defined and set for this case on
"Table 2-96: MISC1 and MISC0 Fields for Pixel Encoding/Colorimetry Format
Indication"
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 4
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 17575cfc22b5..0c9f03dda569 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9246,6 +9246,7 @@ enum skl_power_gate {
> #define TRANS_MSA_10_BPC(2 << 5)
> #define TRANS_MSA_12_BPC(3 << 5)
> #define TRANS_MSA_16_BPC(4 << 5)
> +#define TRANS_MSA_CEA_RANGE (1 << 3)
>
> /* LCPLL Control */
> #define LCPLL_CTL_MMIO(0x130040)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0adc043529f2..6f7be066c8f2 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1685,6 +1685,10 @@ void intel_ddi_set_pipe_settings(const struct
> intel_crtc_state *crtc_state)
> WARN_ON(transcoder_is_dsi(cpu_transcoder));
>
> temp = TRANS_MSA_SYNC_CLK;
> +
> + if (crtc_state->limited_color_range)
> + temp |= TRANS_MSA_CEA_RANGE;
> +
> switch (crtc_state->pipe_bpp) {
> case 18:
> temp |= TRANS_MSA_6_BPC;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Clear STOP_RING bit before restoring the context
Before a reset, we set the STOP_RING bit of RING_MI_MODE to freeze the
engine. However, sometimes we observe that upon restart, the engine
freezes again with the STOP_RING bit still asserted. By inspection, we
know that the register itself is cleared by the GPU reset, so that bit
must be preserved inside the context image and reloaded from there. A
simple fix (as the RING_MI_MODE is at a fixed offset in a valid context)
is to clobber the STOP_RING bit inside the image before replaying the
request.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michel Thierry
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/intel_lrc.c | 17 +++--
drivers/gpu/drm/i915/intel_lrc_reg.h | 2 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f90c74038ef..37fe842de639 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1918,6 +1918,20 @@ static void execlists_reset(struct intel_engine_cs
*engine,
spin_unlock_irqrestore(>timeline.lock, flags);
+ if (!request)
+ return;
+
+ regs = request->hw_context->lrc_reg_state;
+
+ /*
+* After a reset, the context may have preserved the STOP bit
+* of RING_MI_MODE we used to freeze the active engine before
+* the reset. If that bit is restored the ring stops instead
+* of being executed.
+*/
+ regs[CTX_MI_MODE + 1] |= STOP_RING << 16;
+ regs[CTX_MI_MODE + 1] &= ~STOP_RING;
+
/*
* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
@@ -1929,7 +1943,7 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* and have to at least restore the RING register in the context
* image back to the expected values to skip over the guilty request.
*/
- if (!request || request->fence.error != -EIO)
+ if (request->fence.error != -EIO)
return;
/*
@@ -1940,7 +1954,6 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* future request will be after userspace has had the opportunity
* to recreate its own state.
*/
- regs = request->hw_context->lrc_reg_state;
if (engine->pinned_default_state) {
memcpy(regs, /* skip restoring the vanilla PPHWSP */
engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h
b/drivers/gpu/drm/i915/intel_lrc_reg.h
index 5ef932d810a7..3b155ecbfa92 100644
--- a/drivers/gpu/drm/i915/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -39,6 +39,8 @@
#define CTX_R_PWR_CLK_STATE0x42
#define CTX_END0x44
+#define CTX_MI_MODE0x54
+
#define CTX_REG(reg_state, pos, reg, val) do { \
u32 *reg_state__ = (reg_state); \
const u32 pos__ = (pos); \
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Keep upto half of RAM reserved for test runner
Halve our estimated available RAM for use by the tests to avoid nasty
situations where the test runner may force us into swap.
Rumour has it that the new runner isn't quite so bloated as piglit...
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
Cc: Petri Latvala
---
lib/intel_os.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/intel_os.c b/lib/intel_os.c
index 29a27272e..4037440fd 100644
--- a/lib/intel_os.c
+++ b/lib/intel_os.c
@@ -329,8 +329,11 @@ int __intel_check_memory(uint64_t count, uint64_t size,
unsigned mode,
mode & CHECK_SWAP ? " + swap": "");
total = 0;
- if (mode & (CHECK_RAM | CHECK_SWAP))
- total += intel_get_avail_ram_mb();
+ if (mode & (CHECK_RAM | CHECK_SWAP)) {
+ total = intel_get_avail_ram_mb();
+ /* Keep some in reserve for the runner. */
+ total -= min(total / 2, 1000);
+ }
if (mode & CHECK_SWAP)
total += intel_get_total_swap_mb();
total *= 1024 * 1024;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Increase LSPCON timeout
== Series Details ==
Series: Increase LSPCON timeout
URL : https://patchwork.freedesktop.org/series/48183/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4665 -> Patchwork_9937 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48183/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9937 that come from known issues:
=== IGT changes ===
Issues hit
igt@debugfs_test@read_all_entries:
{fi-icl-u}: PASS -> DMESG-FAIL (fdo#107411)
igt@drv_selftest@live_hangcheck:
fi-kbl-guc: PASS -> INCOMPLETE (fdo#106693, fdo#107207)
igt@gem_exec_reloc@basic-gtt-read-noreloc:
{fi-icl-u}: PASS -> DMESG-WARN (fdo#107411) +77
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: PASS -> FAIL (fdo#103167)
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
igt@drv_selftest@live_workarounds:
fi-cnl-psr: DMESG-FAIL (fdo#107292) -> PASS
fi-skl-6700k2: DMESG-FAIL (fdo#107292) -> PASS
igt@kms_chamelium@dp-crc-fast:
fi-kbl-7500u: DMESG-FAIL (fdo#103841) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: DMESG-WARN (fdo#107372) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106693 https://bugs.freedesktop.org/show_bug.cgi?id=106693
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107207 https://bugs.freedesktop.org/show_bug.cgi?id=107207
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107372 https://bugs.freedesktop.org/show_bug.cgi?id=107372
fdo#107411 https://bugs.freedesktop.org/show_bug.cgi?id=107411
== Participating hosts (54 -> 49) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4665 -> Patchwork_9937
CI_DRM_4665: 3a43bf5efa33be9f88d70427dbfba4db4377eaf6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4594: b0263e5d0563a81a42cf66e7d3b84662d3222862 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9937: 977c85e40247ce7d9dc570748f6bbea3473bad75 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
977c85e40247 Increase LSPCON timeout
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9937/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915: Disable runtime-pm using lowlevel functions if !HAS_RC6
Chris Wilson writes: > If we cannot setup rc6, we cannot let the GPU suspend itself as it > cannot save its state (to a powercontext). As such, we must disable > runtime-pm, but we should do so using the low-level pm-runtime function > which leaves our own debugging functions intact (and continue to detect > errors in our runtime-pm handling should we ever be able to enable rc6). > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [drm][i915] Increase LSPCON timeout
100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
settle. This causes dropped display modes at driver initialisation.
Increase timeout to 1000 ms.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Signed-off-by: Fredrik Schön
---
drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 8ae8f42f430a..be1b08f589a4 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct
intel_lspcon *lspcon,
DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
lspcon_mode_name(mode));
- wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
+ wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode,
1000);
if (current_mode != mode)
DRM_ERROR("LSPCON mode hasn't settled\n");
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Kick waiters on resetting legacy rings (rev2)
== Series Details == Series: drm/i915: Kick waiters on resetting legacy rings (rev2) URL : https://patchwork.freedesktop.org/series/47362/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4664_full -> Patchwork_9936_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9936_full that come from known issues: === IGT changes === Possible fixes igt@drv_suspend@shrink: shard-snb: FAIL (fdo#106886) -> PASS shard-glk: INCOMPLETE (fdo#103359, k.org#198133, fdo#106886) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4664 -> Patchwork_9936 CI_DRM_4664: 19e458884fe1d8d10e453529933199250cc8821f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4593: c88e219c6e890d89b7836c5e248ffedf334d55a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9936: f715468550d11fafc82dda24553e61664bae43ce @ 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_9936/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915: Disable runtime-pm using lowlevel functions if !HAS_RC6
Quoting Mika Kuoppala (2018-08-14 13:06:45)
> Chris Wilson writes:
>
> > If we cannot setup rc6, we cannot let the GPU suspend itself as it
> > cannot save its state (to a powercontext). As such, we must disable
> > runtime-pm, but we should do so using the low-level pm-runtime function
> > which leaves our own debugging functions intact (and continue to detect
> > errors in our runtime-pm handling should we ever be able to enable rc6).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 9a01560c5bd1..d99e5fabe93c 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -26,6 +26,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include "i915_drv.h"
> > #include "intel_drv.h"
> > @@ -8181,7 +8182,7 @@ void intel_init_gt_powersave(struct drm_i915_private
> > *dev_priv)
> >*/
> > if (!sanitize_rc6(dev_priv)) {
> > DRM_INFO("RC6 disabled, disabling runtime PM support\n");
> > - intel_runtime_pm_get(dev_priv);
> > + pm_runtime_get(_priv->drm.pdev->dev);
>
> Should this be pm_runtime_get_sync()?
It can be. It's already active at this point so there's no difference in
practice.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915: Disable runtime-pm using lowlevel functions if !HAS_RC6
Chris Wilson writes:
> If we cannot setup rc6, we cannot let the GPU suspend itself as it
> cannot save its state (to a powercontext). As such, we must disable
> runtime-pm, but we should do so using the low-level pm-runtime function
> which leaves our own debugging functions intact (and continue to detect
> errors in our runtime-pm handling should we ever be able to enable rc6).
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9a01560c5bd1..d99e5fabe93c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -26,6 +26,7 @@
> */
>
> #include
> +#include
> #include
> #include "i915_drv.h"
> #include "intel_drv.h"
> @@ -8181,7 +8182,7 @@ void intel_init_gt_powersave(struct drm_i915_private
> *dev_priv)
>*/
> if (!sanitize_rc6(dev_priv)) {
> DRM_INFO("RC6 disabled, disabling runtime PM support\n");
> - intel_runtime_pm_get(dev_priv);
> + pm_runtime_get(_priv->drm.pdev->dev);
Should this be pm_runtime_get_sync()?
-Mika
> }
>
> mutex_lock(_priv->pcu_lock);
> @@ -8233,7 +8234,7 @@ void intel_cleanup_gt_powersave(struct drm_i915_private
> *dev_priv)
> valleyview_cleanup_gt_powersave(dev_priv);
>
> if (!HAS_RC6(dev_priv))
> - intel_runtime_pm_put(dev_priv);
> + pm_runtime_put(_priv->drm.pdev->dev);
> }
>
> /**
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev12)
== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev12) URL : https://patchwork.freedesktop.org/series/36068/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4664_full -> Patchwork_9935_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9935_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9935_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9935_full: === IGT changes === Warnings igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: shard-hsw: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9935_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363, fdo#102887) Possible fixes igt@drv_suspend@shrink: shard-glk: INCOMPLETE (k.org#198133, fdo#103359, fdo#106886) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4664 -> Patchwork_9935 CI_DRM_4664: 19e458884fe1d8d10e453529933199250cc8821f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4593: c88e219c6e890d89b7836c5e248ffedf334d55a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9935: 7219dd268d7576d29248c4936d1e11d20fd92c5b @ 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_9935/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Kick waiters on resetting legacy rings
Quoting Mika Kuoppala (2018-08-14 12:38:18)
> Chris Wilson writes:
>
> > This reapplies commit 39f3be162c46 ("drm/i915: Kick waiters on resetting
> > legacy rings") after the improved gem_eio was run across all machines we
> > found that gen3 and early gen4 still lost the immediate interrupt
> > following reset, and the HWSTAM w/a applied to gen6+ is inadequate.
> >
> > Unlike the later gen, on gen3/4 the principle (and only tests to fail so
> > far) are the wait vs reset test cases, whereas the reset stress case
> > works fine (which was the predominantly failing case for gen6+). That is
> > enough to suggest the underlying issue is sufficiently different to
> > support the difference in HWSTAM efficacy.
> >
> > Testcase: igt/gem_eio/wait-10ms
> > References: 39f3be162c46 ("drm/i915: Kick waiters on resetting legacy
> > rings")
> > References: a69ab52b0358 ("drm/i915: Remove extra waiter kick on legacy
> > resets")
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index b65cf7832b39..d40f55a8dc34 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -537,6 +537,8 @@ static int init_ring_common(struct intel_engine_cs
> > *engine)
> > if (INTEL_GEN(dev_priv) > 2)
> > I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
> >
> > + /* Papering over lost _interrupts_ immediately following the restart
> > */
> > + intel_engine_wakeup(engine);
>
> We came, we toggled, we learned. Onwards!
The pessimist in me says if this again boils down to a timing bug, we
need to find another w/a. It's a shame that HWSTAM wasn't it (even
remembering the bit differences between gen, as a last resort I tested
with HWSTAM==0 i.e. no mask).
Until then, ignorance is bliss.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Kick waiters on resetting legacy rings
Chris Wilson writes:
> This reapplies commit 39f3be162c46 ("drm/i915: Kick waiters on resetting
> legacy rings") after the improved gem_eio was run across all machines we
> found that gen3 and early gen4 still lost the immediate interrupt
> following reset, and the HWSTAM w/a applied to gen6+ is inadequate.
>
> Unlike the later gen, on gen3/4 the principle (and only tests to fail so
> far) are the wait vs reset test cases, whereas the reset stress case
> works fine (which was the predominantly failing case for gen6+). That is
> enough to suggest the underlying issue is sufficiently different to
> support the difference in HWSTAM efficacy.
>
> Testcase: igt/gem_eio/wait-10ms
> References: 39f3be162c46 ("drm/i915: Kick waiters on resetting legacy rings")
> References: a69ab52b0358 ("drm/i915: Remove extra waiter kick on legacy
> resets")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index b65cf7832b39..d40f55a8dc34 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -537,6 +537,8 @@ static int init_ring_common(struct intel_engine_cs
> *engine)
> if (INTEL_GEN(dev_priv) > 2)
> I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
>
> + /* Papering over lost _interrupts_ immediately following the restart */
> + intel_engine_wakeup(engine);
We came, we toggled, we learned. Onwards!
Reviewed-by: Mika Kuoppala
> out:
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>
> --
> 2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Kick waiters on resetting legacy rings (rev2)
== Series Details == Series: drm/i915: Kick waiters on resetting legacy rings (rev2) URL : https://patchwork.freedesktop.org/series/47362/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4664 -> Patchwork_9936 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/47362/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9936 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_workarounds: fi-cnl-psr: PASS -> DMESG-FAIL (fdo#107292) Possible fixes igt@drv_selftest@live_coherency: fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS igt@drv_selftest@live_hangcheck: fi-skl-guc: DMESG-FAIL (fdo#106685, fdo#107174) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_chamelium@dp-crc-fast: fi-kbl-7500u: DMESG-FAIL (fdo#103841) -> PASS fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164 fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174 fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292 == Participating hosts (54 -> 49) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4664 -> Patchwork_9936 CI_DRM_4664: 19e458884fe1d8d10e453529933199250cc8821f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4593: c88e219c6e890d89b7836c5e248ffedf334d55a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9936: f715468550d11fafc82dda24553e61664bae43ce @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f715468550d1 drm/i915: Kick waiters on resetting legacy rings == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9936/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Kick waiters on resetting legacy rings (rev2)
== Series Details ==
Series: drm/i915: Kick waiters on resetting legacy rings (rev2)
URL : https://patchwork.freedesktop.org/series/47362/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f715468550d1 drm/i915: Kick waiters on resetting legacy rings
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
References: 39f3be162c46 ("drm/i915: Kick waiters on resetting legacy rings")
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 39f3be162c46 ("drm/i915: Kick
waiters on resetting legacy rings")'
#18:
References: 39f3be162c46 ("drm/i915: Kick waiters on resetting legacy rings")
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a69ab52b0358 ("drm/i915: Remove
extra waiter kick on legacy resets")'
#19:
References: a69ab52b0358 ("drm/i915: Remove extra waiter kick on legacy resets")
total: 2 errors, 1 warnings, 0 checks, 8 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev12)
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev12)
URL : https://patchwork.freedesktop.org/series/36068/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4664 -> Patchwork_9935 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/36068/revisions/12/mbox/
== Known issues ==
Here are the changes found in Patchwork_9935 that come from known issues:
=== IGT changes ===
Issues hit
igt@debugfs_test@read_all_entries:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: PASS -> DMESG-WARN (fdo#107425)
igt@drv_selftest@live_workarounds:
{fi-bsw-kefka}: PASS -> DMESG-FAIL (fdo#107292)
fi-skl-6700k2: PASS -> DMESG-FAIL (fdo#107292)
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: PASS -> FAIL (fdo#103191, fdo#107362)
Possible fixes
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#107174, fdo#106685) -> PASS
igt@gem_exec_suspend@basic-s4-devices:
fi-kbl-7500u: DMESG-WARN (fdo#107139, fdo#105128) -> PASS
igt@kms_chamelium@dp-crc-fast:
fi-kbl-7500u: DMESG-FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685
fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (54 -> 49) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4664 -> Patchwork_9935
CI_DRM_4664: 19e458884fe1d8d10e453529933199250cc8821f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4593: c88e219c6e890d89b7836c5e248ffedf334d55a2 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9935: 7219dd268d7576d29248c4936d1e11d20fd92c5b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7219dd268d75 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
68ef036f97ec drm/i915: Write AVI infoframes for Parade LSPCON
035c33d9a65a drm/i915: Write AVI infoframes for MCA LSPCON
db069f765d9f drm/i915: Add AVI infoframe support for LSPCON
98b9089d8e0b drm/i915: Check LSPCON vendor OUI
d6d1c36b536f drm/i915: Add CRTC output format YCBCR 4:4:4
f3f948d3f545 drm/i915: Add CRTC output format YCBCR 4:2:0
b34adc8cecfb drm/i915: Introduce CRTC output format
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9935/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Kick waiters on resetting legacy rings
This reapplies commit 39f3be162c46 ("drm/i915: Kick waiters on resetting
legacy rings") after the improved gem_eio was run across all machines we
found that gen3 and early gen4 still lost the immediate interrupt
following reset, and the HWSTAM w/a applied to gen6+ is inadequate.
Unlike the later gen, on gen3/4 the principle (and only tests to fail so
far) are the wait vs reset test cases, whereas the reset stress case
works fine (which was the predominantly failing case for gen6+). That is
enough to suggest the underlying issue is sufficiently different to
support the difference in HWSTAM efficacy.
Testcase: igt/gem_eio/wait-10ms
References: 39f3be162c46 ("drm/i915: Kick waiters on resetting legacy rings")
References: a69ab52b0358 ("drm/i915: Remove extra waiter kick on legacy resets")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b65cf7832b39..d40f55a8dc34 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -537,6 +537,8 @@ static int init_ring_common(struct intel_engine_cs *engine)
if (INTEL_GEN(dev_priv) > 2)
I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
+ /* Papering over lost _interrupts_ immediately following the restart */
+ intel_engine_wakeup(engine);
out:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 6/8] drm/i915: Write AVI infoframes for MCA LSPCON
From: "Sharma, Shashank"
As LSPCON is a DP branch device, LSPCON vendors define
specific methods to pass AVI infoframes to the the chip.
This patch adds:
- a generic wrapper function for writing AVI infoframes for
all LSPCON devices.
- a vendor specific function to wrire AVI infoframes into
MCA LSPCON devices.
V2: Rebase
V3: Added r-b from Maarten
V4: Rebase
V5: Rebase
V6: Rebase
V7: Fixed checkpatch warnings for alignment
V8: Rebase
V9: Added the retry logic, with 50ms incremental delays while
writing AVI IF
V10: Changed the return value check
V11: Fixed checkpatch warning
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Reviewed-by: Maarten Lankhorst
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h| 4 ++
drivers/gpu/drm/i915/intel_hdmi.c | 2 +
drivers/gpu/drm/i915/intel_lspcon.c | 88 +
3 files changed, 94 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 509c659..2cc0775 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2193,6 +2193,10 @@ void intel_color_load_luts(struct drm_crtc_state
*crtc_state);
bool lspcon_init(struct intel_digital_port *intel_dig_port);
void lspcon_resume(struct intel_lspcon *lspcon);
void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
+void lspcon_write_infoframe(struct drm_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ const void *buf, ssize_t len);
void lspcon_set_infoframes(struct drm_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9f2fac8..2e1b6e8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2312,6 +2312,8 @@ void intel_infoframe_init(struct intel_digital_port
*intel_dig_port)
intel_dig_port->infoframe_enabled = g4x_infoframe_enabled;
} else if (HAS_DDI(dev_priv)) {
if (intel_dig_port->lspcon.active) {
+ intel_dig_port->write_infoframe =
+ lspcon_write_infoframe;
intel_dig_port->set_infoframes = lspcon_set_infoframes;
intel_dig_port->infoframe_enabled =
lspcon_infoframe_enabled;
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 1edca590..3ee10ab 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -31,6 +31,12 @@
#define LSPCON_VENDOR_PARADE_OUI 0x001CF8
#define LSPCON_VENDOR_MCA_OUI 0x0060AD
+/* AUX addresses to write MCA AVI IF */
+#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
+#define LSPCON_MCA_AVI_IF_CTRL 0x5DF
+#define LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
+#define LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
+
static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
{
struct intel_digital_port *dig_port =
@@ -234,6 +240,88 @@ static void lspcon_resume_in_pcon_wa(struct intel_lspcon
*lspcon)
DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
}
+static bool _lspcon_write_avi_infoframe_mca(struct drm_dp_aux *aux,
+ const uint8_t *buffer, ssize_t len)
+{
+ int ret;
+ uint32_t val = 0;
+ uint32_t retry;
+ uint16_t reg;
+ const uint8_t *data = buffer;
+
+ reg = LSPCON_MCA_AVI_IF_WRITE_OFFSET;
+ while (val < len) {
+ /* DPCD write for AVI IF can fail on a slow FW day, so retry */
+ for (retry = 0; retry < 5; retry++) {
+ ret = drm_dp_dpcd_write(aux, reg, (void *)data, 1);
+ if (ret == 1) {
+ break;
+ } else if (retry < 4) {
+ mdelay(50);
+ continue;
+ } else {
+ DRM_ERROR("DPCD write failed, add:0x%x\n", reg);
+ return false;
+ }
+ }
+ val++; reg++; data++;
+ }
+
+ val = 0;
+ reg = LSPCON_MCA_AVI_IF_CTRL;
+ ret = drm_dp_dpcd_read(aux, reg, , 1);
+ if (ret < 0) {
+ DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
+ return false;
+ }
+
+ /* Indicate LSPCON chip about infoframe, clear bit 1 and set bit 0 */
+ val &= ~LSPCON_MCA_AVI_IF_HANDLED;
+ val |= LSPCON_MCA_AVI_IF_KICKOFF;
+
+ ret = drm_dp_dpcd_write(aux, reg, , 1);
+ if (ret < 0) {
+ DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
+ return false;
+ }
+
+ val =
[Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev11)
== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev11) URL : https://patchwork.freedesktop.org/series/36068/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4664 -> Patchwork_9934 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/36068/revisions/11/mbox/ == Known issues == Here are the changes found in Patchwork_9934 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: fi-skl-6600u: PASS -> DMESG-FAIL (fdo#106560, fdo#107174) igt@drv_selftest@live_workarounds: fi-cnl-psr: PASS -> DMESG-FAIL (fdo#107292) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@drv_selftest@live_hangcheck: fi-skl-guc: DMESG-FAIL (fdo#107174, fdo#106685) -> PASS igt@kms_chamelium@dp-crc-fast: fi-kbl-7500u: DMESG-FAIL (fdo#103841) -> PASS fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685 fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174 fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292 == Participating hosts (54 -> 48) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4664 -> Patchwork_9934 CI_DRM_4664: 19e458884fe1d8d10e453529933199250cc8821f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4593: c88e219c6e890d89b7836c5e248ffedf334d55a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9934: 718980d15cf88d899a98a7025de083cc49e9b71f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 718980d15cf8 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON e2a2a436e94b drm/i915: Write AVI infoframes for Parade LSPCON 10899f3f2fd2 drm/i915: Write AVI infoframes for MCA LSPCON 78358522aa0e drm/i915: Add AVI infoframe support for LSPCON 4bbb3f453eff drm/i915: Check LSPCON vendor OUI 264fd343ba9e drm/i915: Add CRTC output format YCBCR 4:4:4 2cc560ee9457 drm/i915: Add CRTC output format YCBCR 4:2:0 b96e44106d65 drm/i915: Introduce CRTC output format == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9934/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev11)
== Series Details ==
Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev11)
URL : https://patchwork.freedesktop.org/series/36068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b96e44106d65 drm/i915: Introduce CRTC output format
2cc560ee9457 drm/i915: Add CRTC output format YCBCR 4:2:0
264fd343ba9e drm/i915: Add CRTC output format YCBCR 4:4:4
4bbb3f453eff drm/i915: Check LSPCON vendor OUI
78358522aa0e drm/i915: Add AVI infoframe support for LSPCON
10899f3f2fd2 drm/i915: Write AVI infoframes for MCA LSPCON
-:94: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#94: FILE: drivers/gpu/drm/i915/intel_lspcon.c:254:
+ while (val < len) {
+
-:98: CHECK:BRACES: braces {} should be used on all arms of this statement
#98: FILE: drivers/gpu/drm/i915/intel_lspcon.c:258:
+ if (ret == 1)
[...]
+ else if (retry < 4) {
[...]
+ } else {
[...]
total: 0 errors, 0 warnings, 2 checks, 119 lines checked
e2a2a436e94b drm/i915: Write AVI infoframes for Parade LSPCON
718980d15cf8 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 8/8] drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
LSPCON chips can generate YCBCR outputs, if asked nicely :).
In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes
Whereas for YCBCR 4:4:4 outputs, the source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:4:4 in AVI infoframes
So for both 4:2:0 as well as 4:4:4 outputs, we are driving the
pipe for YCBCR 4:4:4 output, but AVI infoframe's color space
information indicates LSPCON FW to start scaling down from YCBCR
4:4:4 and generate YCBCR 4:2:0 output. As the scaling is done by
LSPCON device, we need not to reserve a scaler for 4:2:0 outputs.
V2: rebase
V3: Addressed review comments from Ville
- add enum crtc_output_format instead of bool ycbcr420
- use crtc_output_format=4:4:4 for modeset of LSPCON 4:2:0 output
cases in this way we will have YCBCR 4:4:4 framework ready (except
the ABI part)
V4: Added r-b from Maarten (for v3)
Addressed review comments from Ville:
- Do not add a non-atomic state variable to determine lspcon output.
Instead add bool in CRTC state to indicate lspcon based scaling.
V5: Addressed review comments from Ville:
- Change the state bool name from external scaling to something more
relavent.
- Keep the info and adjusted_mode structures const.
- use crtc_state instead of pipe_config.
- Push all the config change into lspcon_ycbcr420_config function.
V6: Rebase, small changes to accommodate changes in patch 2.
V7: Fixed checkpatch warnings for alignment
V8: Rebase
PS: Ignored following warnings to match the current formatting:
drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
-:53: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#53: FILE: drivers/gpu/drm/i915/i915_reg.h:8721:
+#define TRANS_MSA_SAMPLING_444(2<<1)
^
-:54: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#54: FILE: drivers/gpu/drm/i915/i915_reg.h:8722:
+#define TRANS_MSA_CLRSP_YCBCR (2<<3)
V9: Rebase
V10: Rebase
Cc: Ville Syrjala
Cc: Maarten Lankhorst
Reviewed-by: Maarten Lankhorst
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
drivers/gpu/drm/i915/intel_display.c | 12
drivers/gpu/drm/i915/intel_dp.c | 4
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_lspcon.c | 26 ++
6 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 17575cf..f3e58a9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9241,6 +9241,8 @@ enum skl_power_gate {
#define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)
#define TRANS_MSA_SYNC_CLK(1 << 0)
+#define TRANS_MSA_SAMPLING_444(2 << 1)
+#define TRANS_MSA_CLRSP_YCBCR (2 << 3)
#define TRANS_MSA_6_BPC (0 << 5)
#define TRANS_MSA_8_BPC (1 << 5)
#define TRANS_MSA_10_BPC (2 << 5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 148bfaa..0db3e22 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1703,6 +1703,13 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
break;
}
+ /*
+* As per DP 1.2 spec section 2.3.4.3 while sending
+* YCBCR 444 signals we should program MSA MISC1/0 fields with
+* colorspace information. The output colorspace encoding is BT601.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
+ temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3384129..883c897 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7827,6 +7827,8 @@ static void intel_get_crtc_ycbcr_config(struct intel_crtc
*crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum intel_output_format output = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->lspcon_downsampling = false;
+
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) {
u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
@@ -7844,6 +7846,16 @@ static void intel_get_crtc_ycbcr_config(struct
intel_crtc *crtc,
else
output = INTEL_OUTPUT_FORMAT_YCBCR420;
} else {
+ /*
+* Currently there is no interface defined to
+* check user preference between RGB/YCBCR444
+
