[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: Deliver guest cursor hotspot info (rev3)
== Series Details == Series: drm/i915/gvt: Deliver guest cursor hotspot info (rev3) URL : https://patchwork.freedesktop.org/series/41727/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4172_full -> Patchwork_8992_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8992_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8992_full, 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/41727/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8992_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-bsd1: shard-kbl: SKIP -> PASS igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_8992_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +1 Possible fixes igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-apl: FAIL (fdo#103207, fdo#104724) -> PASS igt@kms_flip@absolute-wf_vblank-interruptible: shard-glk: FAIL (fdo#106087) -> PASS igt@kms_flip@blocking-absolute-wf_vblank-interruptible: shard-glk: FAIL (fdo#106134) -> PASS igt@kms_setmode@basic: shard-hsw: FAIL (fdo#99912) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087 fdo#106134 https://bugs.freedesktop.org/show_bug.cgi?id=106134 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_4172 -> Patchwork_8992 CI_DRM_4172: b4c14c0809e8f6dba9a4fdf1a659cea5a98750d3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4475: 35f08c12aa216d5b62a5b9984b575cee6905098f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8992: ed94c7975cd1d2e3fe616059bc0ef242051c3312 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4475: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8992/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/oa: Disable OA on Haswell
Quoting Lionel Landwerlin (2018-05-11 16:43:02) > On 11/05/18 15:18, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-05-11 15:14:13) > >> My understanding of the virtual memory addressing from the GPU is > >> limited... > >> But how can the GPU poke at the kernel's allocated data? > >> I thought we mapped into the GPU's address space only what is allocated > >> through gem. > > Correct. The HW should only be accessing the pages through the GTT and > > the GTT should only contain known pages (or a pointer to the scratch > > page). There is maybe a hole where we are freeing the memory before > > the HW has finished using it (still writing through stale TLB and > > whatnot even though the system has reallocated the pages), but other > > than that quite, quite scary. Hence this awooga. > > > > I managed to reproduce a kasan backtrace on the same test. > So it's not just the CI machine. For the record, CI also seems much happier with the wait for OACONTROL before unpinning, so no need to panic! -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/6] lib/audio: Replace sqrt(a*a + b*b) with hypot(a, b)
Signed-off-by: Chris Wilson
---
lib/igt_audio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/igt_audio.c b/lib/igt_audio.c
index 2321d1c6e..229ce6c69 100644
--- a/lib/igt_audio.c
+++ b/lib/igt_audio.c
@@ -266,9 +266,7 @@ bool audio_signal_detect(struct audio_signal *signal, int
channels,
max = 0;
for (i = 0; i < frames / 2; i++) {
- amplitude[i] = sqrt(data[i] * data[i] +
- data[frames - i] *
- data[frames - i]);
+ amplitude[i] = hypot(data[i], data[frames - i]);
if (amplitude[i] > max)
max = amplitude[i];
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/6] overlay: Remove the miscalculation of window position
We already call x11_position() to calculate the position of the
overlay, so do not need to manually recompute them inside
x11_overlay_create(). This has the advantage that x11_position()
understands the multi-monitor layout instructions.
Signed-off-by: Chris Wilson
---
overlay/x11/x11-overlay.c | 16
1 file changed, 16 deletions(-)
diff --git a/overlay/x11/x11-overlay.c b/overlay/x11/x11-overlay.c
index d08ebfc9c..ae6494295 100644
--- a/overlay/x11/x11-overlay.c
+++ b/overlay/x11/x11-overlay.c
@@ -271,22 +271,6 @@ x11_overlay_create(struct config *config, int *width, int
*height)
priv->x = x;
priv->y = y;
- if (position != POS_UNSET) {
- switch (position & 7) {
- default:
- case 0: priv->x = 0; break;
- case 1: priv->x = (scr->width - image->width)/2; break;
- case 2: priv->x = scr->width - image->width; break;
- }
-
- switch ((position >> 4) & 7) {
- default:
- case 0: priv->y = 0; break;
- case 1: priv->y = (scr->height - image->height)/2; break;
- case 2: priv->y = scr->height - image->height; break;
- }
- }
-
priv->image = image;
priv->image->data = (void *)&priv->name;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/6] igt/gem_eio: Exercise banning
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
Signed-off-by: Chris Wilson
---
tests/gem_eio.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 6455c6acd..4720b47b5 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -250,6 +250,52 @@ static int __check_wait(int fd, uint32_t bo, unsigned int
wait)
return ret;
}
+static void __test_banned(int fd)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = gem_create(fd, 4096),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ };
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ unsigned long count = 0;
+
+ gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
+
+ gem_quiescent_gpu(fd);
+ igt_require(i915_reset_control(true));
+
+ igt_until_timeout(5) {
+ igt_spin_t *hang;
+
+ if (__gem_execbuf(fd, &execbuf) == -EIO) {
+ igt_info("Banned after causing %lu hangs\n", count);
+ igt_assert(count > 1);
+ return;
+ }
+
+ /* Trigger a reset, making sure we are detected as guilty */
+ hang = spin_sync(fd, 0, 0);
+ trigger_reset(fd);
+ igt_spin_batch_free(fd, hang);
+
+ count++;
+ }
+
+ igt_assert_f(false,
+"Ran for 5s, %lu hangs without being banned\n",
+count);
+}
+
+static void test_banned(int fd)
+{
+ fd = gem_reopen_driver(fd);
+ __test_banned(fd);
+ close(fd);
+}
+
#define TEST_WEDGE (1)
static void test_wait(int fd, unsigned int flags, unsigned int wait)
@@ -693,6 +739,9 @@ igt_main
igt_subtest("execbuf")
test_execbuf(fd);
+ igt_subtest("banned")
+ test_banned(fd);
+
igt_subtest("suspend")
test_suspend(fd, SUSPEND_STATE_MEM);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 6/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks
From: Tvrtko Ursulin
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
v2: Add tests to run across all engines simultaneously to encourage
ksoftirqd to kick in even more often.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson #v1
Signed-off-by: Chris Wilson
---
tests/gem_exec_latency.c | 207 +++
1 file changed, 207 insertions(+)
diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index 9498c0921..c5816427b 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -36,11 +36,15 @@
#include
#include
#include
+#include
#include "drm.h"
#include "igt_sysfs.h"
#include "igt_vgem.h"
+#include "igt_dummyload.h"
+#include "igt_stats.h"
+
#include "i915/gem_ring.h"
#define LOCAL_I915_EXEC_NO_RELOC (1<<11)
@@ -351,6 +355,189 @@ static void latency_from_ring(int fd,
}
}
+static void __rearm_spin_batch(igt_spin_t *spin)
+{
+ const uint32_t mi_arb_chk = 0x5 << 23;
+
+ *spin->batch = mi_arb_chk;
+ *spin->running = 0;
+ __sync_synchronize();
+}
+
+static void
+__submit_spin_batch(int fd, igt_spin_t *spin, unsigned int flags)
+{
+ struct drm_i915_gem_execbuffer2 eb = spin->execbuf;
+
+ eb.flags &= ~(0x3f | I915_EXEC_BSD_MASK);
+ eb.flags |= flags | I915_EXEC_NO_RELOC;
+
+ gem_execbuf(fd, &eb);
+}
+
+struct rt_pkt {
+ struct igt_mean mean;
+ double min, max;
+};
+
+static bool __spin_wait(int fd, igt_spin_t *spin)
+{
+ while (!READ_ONCE(*spin->running)) {
+ if (!gem_bo_busy(fd, spin->handle))
+ return false;
+ }
+
+ return true;
+}
+
+/*
+ * Test whether RT thread which hogs the CPU a lot can submit work with
+ * reasonable latency.
+ */
+static void
+rthog_latency_on_ring(int fd, unsigned int engine, const char *name, unsigned
int flags)
+#define RTIDLE 0x1
+{
+ const char *passname[] = { "warmup", "normal", "rt" };
+ struct rt_pkt *results;
+ unsigned int engines[16];
+ const char *names[16];
+ unsigned int nengine;
+ int ret;
+
+ results = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(results != MAP_FAILED);
+
+ nengine = 0;
+ if (engine == ALL_ENGINES) {
+ for_each_physical_engine(fd, engine) {
+ if (!gem_can_store_dword(fd, engine))
+ continue;
+
+ engines[nengine] = engine;
+ names[nengine] = e__->name;
+ nengine++;
+ }
+ igt_require(nengine > 1);
+ } else {
+ igt_require(gem_can_store_dword(fd, engine));
+ engines[nengine] = engine;
+ names[nengine] = name;
+ nengine++;
+ }
+
+ igt_fork(child, nengine) {
+ unsigned int pass = 0; /* Three passes: warmup, normal, rt. */
+
+ engine = engines[child];
+ do {
+ struct igt_mean mean;
+ double min = HUGE_VAL;
+ double max = -HUGE_VAL;
+ igt_spin_t *spin;
+
+ igt_mean_init(&mean);
+
+ if (pass == 2) {
+ struct sched_param rt =
+ { .sched_priority = 99 };
+
+ ret = sched_setscheduler(0,
+SCHED_FIFO |
SCHED_RESET_ON_FORK,
+&rt);
+ if (ret) {
+ igt_warn("Failed to set scheduling
policy!\n");
+ break;
+ }
+ }
+
+ spin = __igt_spin_batch_new_poll(fd, 0, engine);
+ if (!spin) {
+ igt_warn("Failed to create spinner! (%s)\n",
+passname[pass]);
+ break;
+ }
+ igt_spin_busywait_until_running(spin);
+
+ igt_until_timeout(pass > 0 ? 5 : 2) {
+ struct timespec ts = { };
+ double t;
+
+ igt_spin_batch_end(spin);
+ gem_sync(fd, spin->handle);
+ if (flags & RTIDLE)
+ usleep(250);
+
+ /*
+* If we are oversubscribed (more RT hogs than
+* cpus) give the others a change to run;
+* otherwise, they will inter
[Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()
trigger_reset() imposes a tight time constraint (2s) so that we verify
that the reset itself completes quickly. In the middle of this check, we
call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
clear out the freed memory (DROP_FREED). Those barriers may have
unbounded latency pushing beyond the 2s timeout, so restrict the
operation to only wait-for-idle (DROP_ACTIVE).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105957
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gem_eio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 4720b47b5..e1aff639d 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -74,8 +74,7 @@ static void trigger_reset(int fd)
/* And just check the gpu is indeed running again */
igt_debug("Checking that the GPU recovered\n");
gem_test_engine(fd, ALL_ENGINES);
-
- gem_quiescent_gpu(fd);
+ igt_drop_caches_set(fd, DROP_ACTIVE);
/* We expect forced reset and health check to be quick. */
igt_assert(igt_seconds_elapsed(&ts) < 2);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts
The test wrote to the same dwords from multiple contexts, assuming that
the writes would be ordered by its submission. However, as it was using
multiple contexts without a write hazard, those timelines are not
coupled and the requests may be emitted to hw in any order. So emit a
write hazard for each individual dword in the scratch (avoiding the
write hazard for the scratch as a whole) to ensure the writes do occur
in the expected order.
Signed-off-by: Chris Wilson
---
tests/gem_ctx_thrash.c | 92 --
1 file changed, 53 insertions(+), 39 deletions(-)
diff --git a/tests/gem_ctx_thrash.c b/tests/gem_ctx_thrash.c
index 2cd9cfebf..b25f95f13 100644
--- a/tests/gem_ctx_thrash.c
+++ b/tests/gem_ctx_thrash.c
@@ -90,17 +90,13 @@ static void single(const char *name, bool all_engines)
{
struct drm_i915_gem_exec_object2 *obj;
struct drm_i915_gem_relocation_entry *reloc;
- unsigned engines[16];
- uint64_t size;
- uint32_t *ctx, *map, scratch;
- unsigned num_ctx;
- int fd, gen, num_engines;
+ unsigned int engines[16], num_engines, num_ctx;
+ uint32_t *ctx, *map, scratch, size;
+ int fd, gen;
#define MAX_LOOP 16
- fd = drm_open_driver_master(DRIVER_INTEL);
+ fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
- igt_require(gem_can_store_dword(fd, 0));
-
gem_require_contexts(fd);
gen = intel_gen(intel_get_drm_devid(fd));
@@ -108,54 +104,77 @@ static void single(const char *name, bool all_engines)
num_engines = 0;
if (all_engines) {
unsigned engine;
+
for_each_physical_engine(fd, engine) {
+ if (!gem_can_store_dword(fd, engine))
+ continue;
+
engines[num_engines++] = engine;
if (num_engines == ARRAY_SIZE(engines))
break;
}
- } else
+ } else {
+ igt_require(gem_can_store_dword(fd, 0));
engines[num_engines++] = 0;
+ }
+ igt_require(num_engines);
num_ctx = get_num_contexts(fd, num_engines);
size = ALIGN(num_ctx * sizeof(uint32_t), 4096);
- scratch = gem_create(fd, ALIGN(num_ctx * sizeof(uint32_t), 4096));
+ scratch = gem_create(fd, size);
gem_set_caching(fd, scratch, I915_CACHING_CACHED);
- obj = calloc(num_ctx, 2 * sizeof(*obj));
- reloc = calloc(num_ctx, sizeof(*reloc));
+ obj = calloc(num_ctx, 3 * sizeof(*obj));
+ reloc = calloc(num_ctx, 2 * sizeof(*reloc));
ctx = malloc(num_ctx * sizeof(uint32_t));
igt_assert(ctx);
for (unsigned n = 0; n < num_ctx; n++) {
ctx[n] = gem_context_create(fd);
- obj[2*n + 0].handle = scratch;
-
- reloc[n].target_handle = scratch;
- reloc[n].presumed_offset = 0;
- reloc[n].offset = sizeof(uint32_t);
- reloc[n].delta = n * sizeof(uint32_t);
- reloc[n].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
- reloc[n].write_domain = 0; /* lies! */
+
+ obj[3*n + 0].handle = gem_create(fd, 4096);
+ reloc[2*n + 0].target_handle = obj[3*n + 0].handle;
+ reloc[2*n + 0].presumed_offset = 0;
+ reloc[2*n + 0].offset = 4000;
+ reloc[2*n + 0].delta = 0;
+ reloc[2*n + 0].read_domains = I915_GEM_DOMAIN_RENDER;
+ reloc[2*n + 0].write_domain = I915_GEM_DOMAIN_RENDER;
+
+ obj[3*n + 1].handle = scratch;
+ reloc[2*n + 1].target_handle = scratch;
+ reloc[2*n + 1].presumed_offset = 0;
+ reloc[2*n + 1].offset = sizeof(uint32_t);
+ reloc[2*n + 1].delta = n * sizeof(uint32_t);
+ reloc[2*n + 1].read_domains = I915_GEM_DOMAIN_RENDER;
+ reloc[2*n + 1].write_domain = 0; /* lies! */
if (gen >= 4 && gen < 8)
- reloc[n].offset += sizeof(uint32_t);
+ reloc[2*n + 1].offset += sizeof(uint32_t);
- obj[2*n + 1].relocs_ptr = to_user_pointer(&reloc[n]);
- obj[2*n + 1].relocation_count = 1;
+ obj[3*n + 2].relocs_ptr = to_user_pointer(&reloc[2*n]);
+ obj[3*n + 2].relocation_count = 2;
}
map = gem_mmap__cpu(fd, scratch, 0, size, PROT_WRITE);
- for (unsigned loop = 1; loop <= MAX_LOOP; loop <<= 1) {
- unsigned count = loop * num_ctx;
+ for (unsigned int loop = 1; loop <= MAX_LOOP; loop <<= 1) {
+ const unsigned int count = loop * num_ctx;
uint32_t *all;
all = malloc(count * sizeof(uint32_t));
- for (unsigned n = 0; n < count; n++)
+ for (unsigned int n = 0; n < count; n++)
all[n] = ctx[n % num_ctx
Re: [Intel-gfx] [PULL] gvt-next for 4.18
On Mon, 14 May 2018, Zhi Wang wrote: > The following changes since commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c: > >drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (2018-05-13 > 10:29:44 +0100) > > are available in the git repository at: > >https://github.com/intel/gvt-linux.git tags/gvt-next-2018-05-14 > > for you to fetch changes up to 41e403d04e7050c8d88682939febcdbe117d4c82: > >Revert "drm/i915/gvt: set max priority for gvt context" (2018-05-14 > 05:26:09 +0800) Pulled, thanks. Please try to avoid rebases; it looks like you're now the committer for each commit but without Signed-off-by. BR, Jani. > > > - Improve the emulation of virtual non-priv register. (Yan) > - Reverse the hack of host of preemption of GVT-g. (Weinan) > - Improve untracked warning message.(Changbin) > > > Changbin Du (1): >drm/i915/gvt: Remove disable_warn_untrack and print untracked > mmio with debug level > > Weinan Li (1): >Revert "drm/i915/gvt: set max priority for gvt context" > > Zhao Yan (3): >drm/i915/gvt: let NOPID be the default value of force_to_nonpriv > registers >drm/i915/gvt: do not return error on handling force_to_nonpriv > registers >drm/i915/gvt: let force_to_nonpriv cmd handler only valid for LRI cmd > > Zhi Wang (1): >Merge branch 'drm-intel-next-queued' into gvt-next > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 26 +- > drivers/gpu/drm/i915/gvt/gvt.h| 1 - > drivers/gpu/drm/i915/gvt/handlers.c | 35 > ++- > drivers/gpu/drm/i915/gvt/mmio.c | 2 -- > drivers/gpu/drm/i915/gvt/scheduler.c | 3 --- > 5 files changed, 39 insertions(+), 28 deletions(-) > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Relax CSB force-mmio for VT-d
Chris Wilson writes: > Quoting Chris Wilson (2018-05-11 13:11:47) >> The original switch to use CSB from the HWSP was plagued by the effort >> of read ordering on VT-d; we would read the WRITE pointer from the HWSP >> before it had completed writing the CSB contents. The mystery comes down >> to the lack of rmb() for correct ordering with respect to the writes >> from HW, and with that resolved we can remove the VT-d special casing. > > Mika's been able to reproduce the VT-d issue and is soak testing this > fix, so I'll leave that until he's had a chance to confirm it survives. > In the meantime, I think we are reasonably happy this is the right fix > for Cannonlake and beyond, so I've pushed the first two patches. > My kbl was quite sensitive to this, sometimes failing to even boot without the vtd backoff. Now after weekend of gem_ctx_switch and gem_exec_whisper I am confident for, Tested-by: Mika Kuoppala Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Relax CSB force-mmio for VT-d
Quoting Mika Kuoppala (2018-05-14 09:33:23) > Chris Wilson writes: > > > Quoting Chris Wilson (2018-05-11 13:11:47) > >> The original switch to use CSB from the HWSP was plagued by the effort > >> of read ordering on VT-d; we would read the WRITE pointer from the HWSP > >> before it had completed writing the CSB contents. The mystery comes down > >> to the lack of rmb() for correct ordering with respect to the writes > >> from HW, and with that resolved we can remove the VT-d special casing. > > > > Mika's been able to reproduce the VT-d issue and is soak testing this > > fix, so I'll leave that until he's had a chance to confirm it survives. > > In the meantime, I think we are reasonably happy this is the right fix > > for Cannonlake and beyond, so I've pushed the first two patches. > > > > My kbl was quite sensitive to this, sometimes failing to even > boot without the vtd backoff. > > Now after weekend of gem_ctx_switch and gem_exec_whisper > I am confident for, > > Tested-by: Mika Kuoppala > Reviewed-by: Mika Kuoppala Thanks. The proof of the pudding is in the eating! Pushed to a wider audience :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Nuke PSR support for VLV and CHV
On Fri, 11 May 2018, Dhinakaran Pandiyan wrote:
> PSR hardware and hence the driver code for VLV and CHV deviates a lot from
> their DDI counterparts. While the feature has been disabled for a long time
> now, retaining support for these platforms is a maintenance burden. There
> have been multiple refactoring commits to just keep the existing code for
> these platforms in line with the rest. There are known issues that need to
> be fixed to enable PSR on these platforms, and there is no PSR capable
> platform in CI to ensure the code does not break again if we get around to
> fixing the existing issues. On account of all these reasons, let's nuke
> this code for now and bring it back if a need arises in the future.
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Signed-off-by: Dhinakaran Pandiyan
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 42 +-
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/i915_pci.c | 2 -
> drivers/gpu/drm/i915/intel_drv.h | 2 -
> drivers/gpu/drm/i915/intel_frontbuffer.c | 2 -
> drivers/gpu/drm/i915/intel_psr.c | 248
> +++
> 6 files changed, 27 insertions(+), 270 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 13e7b9e4a6e6..0096e209fe04 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2630,8 +2630,6 @@ static int i915_edp_psr_status(struct seq_file *m, void
> *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> u32 psrperf = 0;
> - u32 stat[3];
> - enum pipe pipe;
> bool enabled = false;
> bool sink_support;
>
> @@ -2652,47 +2650,17 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
> seq_printf(m, "Re-enable work scheduled: %s\n",
> yesno(work_busy(&dev_priv->psr.work.work)));
>
> - if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.psr2_enabled)
> - enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> - else
> - enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> - } else {
> - for_each_pipe(dev_priv, pipe) {
> - enum transcoder cpu_transcoder =
> - intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> - enum intel_display_power_domain power_domain;
> -
> - power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> - if (!intel_display_power_get_if_enabled(dev_priv,
> - power_domain))
> - continue;
> -
> - stat[pipe] = I915_READ(VLV_PSRSTAT(pipe)) &
> - VLV_EDP_PSR_CURR_STATE_MASK;
> - if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
> - (stat[pipe] == VLV_EDP_PSR_ACTIVE_SF_UPDATE))
> - enabled = true;
> -
> - intel_display_power_put(dev_priv, power_domain);
> - }
> - }
> + if (dev_priv->psr.psr2_enabled)
> + enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
> + else
> + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>
> seq_printf(m, "Main link in standby mode: %s\n",
> yesno(dev_priv->psr.link_standby));
>
> - seq_printf(m, "HW Enabled & Active bit: %s", yesno(enabled));
> -
> - if (!HAS_DDI(dev_priv))
> - for_each_pipe(dev_priv, pipe) {
> - if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
> - (stat[pipe] == VLV_EDP_PSR_ACTIVE_SF_UPDATE))
> - seq_printf(m, " pipe %c", pipe_name(pipe));
> - }
> - seq_puts(m, "\n");
> + seq_printf(m, "HW Enabled & Active bit: %s\n", yesno(enabled));
>
> /*
> - * VLV/CHV PSR has no kind of performance counter
>* SKL+ Perf counter is reset to 0 everytime DC state is entered
>*/
> if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 57fb3aa09db0..7e2a400d33c3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -607,7 +607,6 @@ struct i915_psr {
> bool link_standby;
> bool colorimetry_support;
> bool alpm;
> - bool has_hw_tracking;
> bool psr2_enabled;
> u8 sink_sync_latency;
> bool debug;
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4364922e935d..97a91e6af7e3 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -340,7 +340,6 @@ static const struct intel_device_info
> intel_valleyview_info = {
> GEN(7),
Re: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater
>authentication
>
>Implements the HDCP2.2 repeaters authentication steps such as verifying the
>downstream topology and sending stream management information.
>
>v2:
> Rebased.
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 135
>++
> 1 file changed, 135 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index ee9b7519fe73..d70320da85e4 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1145,6 +1145,135 @@ static int hdcp2_session_key_exchange(struct
>intel_connector *connector)
> return 0;
> }
>
>+/*
>+ * Lib endianness functions are aligned for 16/32/64 bits. Since here
>+sequence
>+ * num is 24bits developed a small conversion function.
>+ */
>+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)
This function is already defined and used in mei layer. Define this in some
common header file and use instead of duplicating it here. May be in below
file:
>+{
>+ u32 index;
>+
>+ if (dest != NULL && dst_sz != 0) {
>+ for (index = 0; index < dst_sz && index < sizeof(u32);
>+ index++) {
>+ dest[dst_sz - index - 1] = src[index];
>+ }
>+ }
>+}
>+
>+static
>+int hdcp2_propagate_stream_management_info(struct intel_connector
>+*connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ union {
>+ struct hdcp2_rep_stream_manage stream_manage;
>+ struct hdcp2_rep_stream_ready stream_ready;
>+ } msgs;
>+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+ int ret;
>+
>+ /* Prepare RepeaterAuth_Stream_Manage msg */
>+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
>+ reverse_endianness(msgs.stream_manage.seq_num_m,
>HDCP_2_2_SEQ_NUM_LEN,
>+ (u8 *)&hdcp->seq_num_m);
>+
>+ /* K no of streams is fixed as 1. Stored as big-endian. */
>+ msgs.stream_manage.k = __swab16(1);
>+
>+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
>+ msgs.stream_manage.streams[0].stream_id = 0;
>+ msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
>+
>+ /* Send it to Repeater */
>+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.stream_manage,
>+sizeof(msgs.stream_manage));
>+ if (ret < 0)
>+ return ret;
>+
>+ ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_STREAM_READY,
>+ &msgs.stream_ready,
>sizeof(msgs.stream_ready));
>+ if (ret < 0)
>+ return ret;
>+
>+ hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
>+ hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
>+
>+ ret = hdcp2_verify_mprime(hdcp, &msgs.stream_ready);
>+ if (ret < 0)
>+ return ret;
>+
>+ hdcp->seq_num_m++;
>+
>+ if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
>+ DRM_DEBUG_KMS("seq_num_m roll over.\n");
>+ return -1;
>+ }
Leave a blank line.
>+ return 0;
>+}
>+
>+static
>+int hdcp2_authenticate_repeater_topology(struct intel_connector
>+*connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ union {
>+ struct hdcp2_rep_send_receiverid_list recvid_list;
>+ struct hdcp2_rep_send_ack rep_ack;
>+ } msgs;
>+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+ uint8_t *rx_info;
>+ uint32_t seq_num_v;
>+ int ret;
>+
>+ ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_SEND_RECVID_LIST,
>+ &msgs.recvid_list, sizeof(msgs.recvid_list));
>+ if (ret < 0)
>+ return ret;
>+
>+ rx_info = msgs.recvid_list.rx_info;
>+
>+ if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
>+ HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
>+ DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
>+ return -1;
>+ }
>+
>+ /* Converting and Storing the seq_num_v to local variable as DWORD */
>+ reverse_endianness((u8 *)&seq_num_v, HDCP_2_2_SEQ_NUM_LEN,
>+ msgs.recvid_list.seq_num_v);
>+
>+ if (seq_num_v < hdcp->seq_num_v) {
>+ /* Roll over of th
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
On Wed, 09 May 2018, Ramalingam C wrote:
> GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
> enabling the 511Bytes per RD/WR cycle on legacy platforms for no
> absolute ROIs, this change allows the max bytes per op upto 511Bytes
> from Gen9 onwards.
>
> v2:
> No Change.
> v3:
> Inline function for max_xfer_size and renaming of the macro.[Jani]
> v4:
> Extra brackets removed [ville]
> Commit msg is modified.
>
> Cc: Jani Nikula
> Cc: Chris Wilson
> Signed-off-by: Ramalingam C
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_i2c.c | 11 +--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c08fd4ded688..df998c10c48e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3025,6 +3025,7 @@ enum i915_power_well_id {
> #define GMBUS_CYCLE_STOP (4<<25)
> #define GMBUS_BYTE_COUNT_SHIFT 16
> #define GMBUS_BYTE_COUNT_MAX 256U
> +#define GEN9_GMBUS_BYTE_COUNT_MAX 511U
> #define GMBUS_SLAVE_INDEX_SHIFT 8
> #define GMBUS_SLAVE_ADDR_SHIFT 1
> #define GMBUS_SLAVE_READ (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index e6875509bcd9..1c0f6b56b209 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
> return ret;
> }
>
> +static inline
> +unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
> +{
> + return INTEL_GEN(dev_priv) >= 9 ? GEN9_GMBUS_BYTE_COUNT_MAX :
> +GMBUS_BYTE_COUNT_MAX;
> +}
> +
> static int
> gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> unsigned short addr, u8 *buf, unsigned int len,
> @@ -400,7 +407,7 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
> i2c_msg *msg,
> int ret;
>
> do {
> - len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
> + len = min(rx_size, gmbus_max_xfer_size(dev_priv));
>
> ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
> buf, len, gmbus1_index);
> @@ -462,7 +469,7 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv,
> struct i2c_msg *msg,
> int ret;
>
> do {
> - len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
> + len = min(tx_size, gmbus_max_xfer_size(dev_priv));
>
> ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
>gmbus1_index);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
On Fri, 11 May 2018, "Kumar, Abhay" wrote:
> On 5/11/2018 5:33 AM, Ville Syrjälä wrote:
>> On Wed, May 09, 2018 at 06:25:32PM -0700, Abhay Kumar wrote:
>>> From: Ville Syrjälä
>>>
>>> CDCLK has to be at least twice the BLCK regardless of audio. Audio
>>> driver has to probe using this hook and increase the clock even in
>>> absence of any display.
>>>
>>> v2: Use atomic refcount for get_power, put_power so that we can
>>> call each once(Abhay).
>>>
>>> Signed-off-by: Ville Syrjälä
>>> Signed-off-by: Abhay Kumar
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.h | 3 ++
>>> drivers/gpu/drm/i915/intel_audio.c | 66
>>> +---
>>> drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
>>> drivers/gpu/drm/i915/intel_display.c | 7 +++-
>>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>>> 5 files changed, 82 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index 24c5e4765afd..9c4ea767688a 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -1692,6 +1692,7 @@ struct drm_i915_private {
>>> unsigned int hpll_freq;
>>> unsigned int fdi_pll_freq;
>>> unsigned int czclk_freq;
>>> + atomic_t get_put_refcount;
>>>
>>> struct {
>>> /*
>>> @@ -1709,6 +1710,8 @@ struct drm_i915_private {
>>> struct intel_cdclk_state actual;
>>> /* The current hardware cdclk state */
>>> struct intel_cdclk_state hw;
>>> +
>>> + int force_min_cdclk;
>>> } cdclk;
>>>
>>> /**
>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
>>> b/drivers/gpu/drm/i915/intel_audio.c
>>> index 3ea566f99450..a1e2c4daae6e 100644
>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>> @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder
>>> *encoder,
>>>
>>> if (!connector->eld[0])
>>> return;
>>> -
>>> DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>>> connector->base.id,
>>> connector->name,
>>> @@ -713,14 +712,73 @@ void intel_init_audio_hooks(struct drm_i915_private
>>> *dev_priv)
>>> }
>>> }
>>>
>>> +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
>>> + bool enable)
>>> +{
>>> + struct drm_modeset_acquire_ctx ctx;
>>> + struct drm_atomic_state *state;
>>> + int ret;
>>> +
>>> + drm_modeset_acquire_init(&ctx, 0);
>>> + state = drm_atomic_state_alloc(&dev_priv->drm);
>>> + if (WARN_ON(!state))
>>> + return;
>>> +
>>> + state->acquire_ctx = &ctx;
>>> +
>>> +retry:
>>> + to_intel_atomic_state(state)->modeset = true;
>>> + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
>>> + enable ? 2 * 96000 : 0;
>>> +
>>> + /*
>>> +* Protects dev_priv->cdclk.force_min_cdclk
>>> +* Need to lock this here in case we have no active pipes
>>> +* and thus wouldn't lock it during the commit otherwise.
>>> +*/
>>> + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
>>> &ctx);
>>> + if (!ret)
>>> + ret = drm_atomic_commit(state);
>>> +
>>> + if (ret == -EDEADLK) {
>>> + drm_atomic_state_clear(state);
>>> + drm_modeset_backoff(&ctx);
>>> + goto retry;
>>> + }
>>> +
>>> + WARN_ON(ret);
>>> +
>>> + drm_atomic_state_put(state);
>>> +
>>> + drm_modeset_drop_locks(&ctx);
>>> + drm_modeset_acquire_fini(&ctx);
>>> +}
>>> +
>>> static void i915_audio_component_get_power(struct device *kdev)
>>> {
>>> - intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
>>> + struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
>>> +
>>> + intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
>>> + atomic_inc(&dev_priv->get_put_refcount);
>>> +
>>> + /* Force cdclk to 2*BCLK during first time get power call */
>>> + if (atomic_read(&dev_priv->get_put_refcount) == 1)
>> If it needs to be atomic (ie. we have concurrent callers of get/put_power())
>> then you would also need to do the inc+check atomically. But that in itself
>> wouldn't help because only the first caller would do the cdclk change,
>> and the second call would just immediately proceed without waiting for the
>> cdclk to actually have been changed.
>>
>> So the first question we should ask is whether we can even have
>> concurrent callers, or if there's some form of mutual exclusion
>> already on the caller side?
> As per my understanding I don't think we have any concurrent callers as
> these calls will be in sequence.
> Do you prefer to use static instead?
Static what?
BR,
Jani.
>>
>>> + if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
>>> + glk_force_audio_cdclk(dev_priv, true);
>>> }
>>>
>>> static void i915_audio_component_put_power(struct device *kdev)
>>> {
>>> - int
Re: [Intel-gfx] [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
>
>Implements the enable and disable functions for HDCP2.2 encryption of the
>PORT.
>
>v2:
> intel_wait_for_register is used instead of wait_for. [Chris Wilson]
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 54
>+++
> 1 file changed, 54 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index d70320da85e4..91cac643f083 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -19,6 +19,7 @@
>(enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES5
> #define HDCP2_LC_RETRY_CNT3
>+#define TIME_FOR_ENCRYPT_STATUS_CHANGE32
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
> const struct intel_hdcp_shim *shim) @@ -
>1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct intel_connector
>*connector)
>
> return ret;
> }
>+
>+static int hdcp2_enable_encryption(struct intel_connector *connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ enum port port = connector->encoder->port;
>+ int ret;
>+
>+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
Print a message saying "Encryption Already enabled" .
>+ return 0;
>+
>+ if (hdcp->hdcp_shim->toggle_signalling)
Check for "hdcp->hdcp_shim" as well.
>+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
>+
>+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
>+
>+ /* Link is Authenticated. Now set for Encryption */
>+ I915_WRITE(HDCP2_CTR_DDI(port),
>+ I915_READ(HDCP2_CTR_DDI(port)) |
>+ CTL_LINK_ENCRYPTION_REQ);
>+ }
>+
>+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
>+LINK_ENCRYPTION_STATUS,
>+LINK_ENCRYPTION_STATUS,
>+TIME_FOR_ENCRYPT_STATUS_CHANGE);
Print a message in case of timeout.
>+ return ret;
>+}
>+
>+static int hdcp2_disable_encryption(struct intel_connector *connector)
>+{
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ enum port port = connector->encoder->port;
>+ int ret;
>+
>+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
>LINK_ENCRYPTION_STATUS))
Put a info message saying "Already Disabled" .
>+ return 0;
>+
>+ I915_WRITE(HDCP2_CTR_DDI(port),
>+ I915_READ(HDCP2_CTR_DDI(port)) &
>~CTL_LINK_ENCRYPTION_REQ);
>+
>+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
>+LINK_ENCRYPTION_STATUS, 0x0,
>+TIME_FOR_ENCRYPT_STATUS_CHANGE);
If this times out, do we still need to toggle the signalling ?
>+
>+ if (hdcp->hdcp_shim->toggle_signalling)
Check for validity of " hdcp->hdcp_shim".
>+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
>+
>+ return ret;
>+}
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able
May be calling enable/disable sequence separately will be better :)
>
>Implements a sequence of enabling and disabling the HDCP2.2 (auth and
>encryption).
>
>v2:
> Rebased.
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 75
>+++
> 1 file changed, 75 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 91cac643f083..005627746ca5 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -21,6 +21,9 @@
> #define HDCP2_LC_RETRY_CNT3
> #define TIME_FOR_ENCRYPT_STATUS_CHANGE32
>
>+static int _intel_hdcp2_enable(struct intel_connector *connector);
>+static int _intel_hdcp2_disable(struct intel_connector *connector);
>+
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
> const struct intel_hdcp_shim *shim) { @@ -
>1384,3 +1387,75 @@ static int hdcp2_disable_encryption(struct intel_connector
>*connector)
>
> return ret;
> }
>+
>+static int hdcp2_authenticate_and_encrypt(struct intel_connector
>+*connector) {
>+ int ret, i, tries = 3;
>+
>+ for (i = 0; i < tries; i++) {
>+ ret = hdcp2_authenticate_sink(connector);
>+ if (!ret)
>+ break;
>+
>+ /* Clearing the mei hdcp session */
>+ hdcp2_deauthenticate_port(&connector->hdcp);
>+ DRM_DEBUG_KMS("HDCP2.2 Auth %d of %d Failed.(%d)\n",
>+i + 1, tries, ret);
>+ }
>+
>+ if (i != tries) {
>+
>+ /*
>+ * Ensuring the required 200mSec min time interval between
>+ * Session Key Exchange and encryption.
>+ */
>+ msleep(HDCP_2_2_DELAY_BEFORE_ENCRYPTION_EN);
>+ ret = hdcp2_enable_encryption(connector);
>+ if (ret < 0) {
>+ DRM_DEBUG_KMS("Encryption Enable Failed.(%d)\n",
>ret);
>+ hdcp2_deauthenticate_port(&connector->hdcp);
>+ }
>+ }
>+
>+ return ret;
>+}
>+
>+static int _intel_hdcp2_disable(struct intel_connector *connector) {
>+ int ret;
>+
>+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
>+connector->base.name, connector->base.base.id);
>+
>+ ret = hdcp2_disable_encryption(connector);
Check for return and print a message.
>+
>+ hdcp2_deauthenticate_port(&connector->hdcp);
>+
>+ return ret;
>+}
>+
>+static int _intel_hdcp2_enable(struct intel_connector *connector) {
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ int ret;
>+
>+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being enabled. Type: %d\n",
>+connector->base.name, connector->base.base.id,
>+hdcp->content_type);
>+
>+ ret = hdcp2_authenticate_and_encrypt(connector);
>+ if (ret) {
>+ DRM_ERROR("HDCP2 Type%d Enabling Failed. (%d)\n",
>+ hdcp->content_type, ret);
>+ return ret;
>+ }
>+
>+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is enabled. Type %d\n",
>+connector->base.name, connector->base.base.id,
>+hdcp->content_type);
>+
>+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+
>+ return 0;
>+}
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
;>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Detect if we missed kicking the execlists tasklet
If inside hangcheck we see that the engine has paused, but there is an
execlists interrupt still pending, we know that the tasklet did not
fire. Dump the GEM trace along with the current engine state, and kick
the tasklet to recovery without having to go through a GPU reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
b/drivers/gpu/drm/i915/intel_hangcheck.c
index d47e346bd49e..4b0745d94ab8 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -267,6 +267,21 @@ engine_stuck(struct intel_engine_cs *engine, u64 acthd)
}
}
+ if (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
+ if (GEM_SHOW_DEBUG()) {
+ struct drm_printer p = drm_debug_printer("hangcheck");
+
+ GEM_TRACE_DUMP();
+ intel_engine_dump(engine, &p,
+ "%s CS stuck\n", engine->name);
+ }
+
+ if (i915_tasklet_try(&engine->execlists.tasklet))
+ return ENGINE_WAIT_KICK;
+
+ return ENGINE_WAIT;
+ }
+
return ENGINE_DEAD;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
gen8_cs_irq_handler 512 428 -84
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 034c603867e6..f8c39e5b5cc6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1467,7 +1467,7 @@ static void gen8_cs_irq_handler(struct intel_engine_cs
*engine, u32 iir)
set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
if (iir & GT_RENDER_USER_INTERRUPT) {
- if (USES_GUC_SUBMISSION(engine->i915))
+ if (intel_engine_uses_guc(engine))
set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
notify_ring(engine);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 4e09abf7e206..eb2a25d84a82 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1277,6 +1277,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
engine->unpark = guc_submission_unpark;
engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
+ engine->flags |= I915_ENGINE_USES_GUC;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 70f1b5dd492a..90b534098d00 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2264,6 +2264,7 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->park = NULL;
engine->unpark = NULL;
+ engine->flags &= ~I915_ENGINE_USES_GUC;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
if (engine->i915->preempt_context)
engine->flags |= I915_ENGINE_HAS_PREEMPTION;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index f6ba354faf89..90d1ca2ca232 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -570,6 +570,7 @@ struct intel_engine_cs {
#define I915_ENGINE_NEEDS_CMD_PARSER BIT(0)
#define I915_ENGINE_SUPPORTS_STATS BIT(1)
#define I915_ENGINE_HAS_PREEMPTION BIT(2)
+#define I915_ENGINE_USES_GUC BIT(3)
unsigned int flags;
/*
@@ -647,6 +648,12 @@ intel_engine_has_preemption(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_HAS_PREEMPTION;
}
+static inline bool
+intel_engine_uses_guc(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_USES_GUC;
+}
+
static inline bool __execlists_need_preempt(int prio, int last)
{
return prio > max(0, last);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: Mark up nested spinlocks
When we process the outstanding requests upon banning a context, we need
to acquire both the engine and the client's timeline, nesting the locks.
This requires explicit markup as the two timelines are now of the same
class, since commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into
individual timelines").
Testcase: igt/gem_eio/banned
Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
timelines")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 89bf5d67cb74..0a2070112b66 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3119,7 +3119,7 @@ static void engine_skip_context(struct i915_request
*request)
GEM_BUG_ON(timeline == &engine->timeline);
spin_lock_irqsave(&engine->timeline.lock, flags);
- spin_lock(&timeline->lock);
+ spin_lock_nested(&timeline->lock, SINGLE_DEPTH_NESTING);
list_for_each_entry_continue(request, &engine->timeline.requests, link)
if (request->ctx == hung_ctx)
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Wrap tasklet_struct for abuse
In the next few patches, we want to abuse tasklet to avoid ksoftirqd
latency along critical paths. To make that abuse easily to swallow,
first coat the tasklet in a little syntactic sugar.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_tasklet.h | 78 +
drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
drivers/gpu/drm/i915/intel_lrc.c| 18 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
7 files changed, 102 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dc369a9ec4d..75668b50c81e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
* Turning off the execlists->tasklet until the reset is over
* prevents the race.
*/
- tasklet_disable(&engine->execlists.tasklet);
+ i915_tasklet_disable(&engine->execlists.tasklet);
/*
* We're using worker to queue preemption requests from the tasklet in
@@ -3256,7 +3256,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
{
- tasklet_enable(&engine->execlists.tasklet);
+ i915_tasklet_enable(&engine->execlists.tasklet);
kthread_unpark(engine->breadcrumbs.signaler);
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f9bc3aaa90d0..f8aff5a5aa83 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1477,7 +1477,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ i915_tasklet_schedule(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
new file mode 100644
index ..e24e4f77fe8e
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -0,0 +1,78 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _I915_TASKLET_H_
+#define _I915_TASKLET_H_
+
+#include
+#include
+
+/**
+ * struct i915_tasklet - wrapper around tasklet_struct
+ *
+ * We want to abuse tasklets slightly, such as calling them directly. In some
+ * cases, this requires some auxiliary tracking so subclass the tasklet_struct
+ * so that we have a central place and helpers.
+ */
+struct i915_tasklet {
+ struct tasklet_struct base;
+};
+
+static inline void i915_tasklet_init(struct i915_tasklet *t,
+void (*func)(unsigned long),
+unsigned long data)
+{
+ tasklet_init(&t->base, func, data);
+}
+
+static inline bool i915_tasklet_is_scheduled(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_SCHED, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_running(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_RUN, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_enabled(const struct i915_tasklet *t)
+{
+ return likely(!atomic_read(&t->base.count));
+}
+
+static inline void i915_tasklet_schedule(struct i915_tasklet *t)
+{
+ tasklet_hi_schedule(&t->base);
+}
+
+static inline void i915_tasklet_flush(struct i915_tasklet *t)
+{
+ tasklet_kill(&t->base);
+}
+
+static inline void i915_tasklet_disable(struct i915_tasklet *t)
+{
+ tasklet_disable(&t->base);
+}
+
+static inline void i915_tasklet_enable(struct i915_tasklet *t)
+{
+ tasklet_enable(&t->base);
+}
+
+static inline void i915_tasklet_set_func(struct i915_tasklet *t,
+void (*func)(unsigned long data),
+unsigned long data)
+{
+ i915_tasklet_disable(t);
+
+ t->base.func = func;
+ t->base.data = data;
+
+ i915_tasklet_enable(t);
+}
+
+#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 6bfd7e3ed152..70595e995c45 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1021,7 +1021,7 @@ void intel_engines_park(struct drm_i915_private *i915)
for_each_engine(engine, i915, id) {
/* Flush the residual irq tasklets first. */
intel_engine_disarm_breadcrumbs(engine);
- tasklet_kill(&engine->execlists.tasklet);
+ i915_tasklet_flush(&engine->execlists.tasklet);
[Intel-gfx] [PATCH 06/10] drm/i915/execlists: Direct submission from irq handler
Continuing the theme of bypassing ksoftirqd latency, also first try to
directly submit from the CS interrupt handler to clear the ELSP and
queue the next.
In the past, we have been hesitant to do this as the context switch
processing has been quite heavy, requiring forcewaked mmio. However, as
we now can read the GPU state from the cacheable HWSP, it is relatively
cheap!
v2: Explain why we test_bit(IRQ_EXECLIST) after doing notify_ring (it's
because the notify_ring() may itself trigger direct submission clearing
the bit)
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 21 ++---
drivers/gpu/drm/i915/i915_tasklet.h | 21 +
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f8aff5a5aa83..e1b3a7575fe7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1465,19 +1465,26 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
struct intel_engine_execlists * const execlists = &engine->execlists;
bool tasklet = false;
- if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active))
- tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted);
- }
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT && READ_ONCE(execlists->active))
+ tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+ &engine->irq_posted);
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
- tasklet |= USES_GUC_SUBMISSION(engine->i915);
+ /*
+* notify_ring() may trigger direct submission onto this
+* engine, clearing the ENGINE_IRQ_EXECLIST bit. In that
+* case, we don't want to resubmit and so clear the tasklet
+* boolean. GuC never sets the ENGINE_IRQ_EXECLIST bit and
+* so when using the GuC this equates to an unconditional
+* setting of tasklet to true.
+*/
+ if (!test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
+ tasklet = USES_GUC_SUBMISSION(engine->i915);
}
if (tasklet)
- i915_tasklet_schedule(&execlists->tasklet);
+ i915_tasklet(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index 6f3b2fedc65b..0aff77caa346 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -105,4 +105,25 @@ static inline void i915_tasklet_run(const struct
i915_tasklet *t)
__i915_tasklet_run(t);
}
+static inline bool i915_tasklet_try(struct i915_tasklet *t)
+{
+ if (unlikely(!tasklet_trylock(&t->base)))
+ return false;
+
+ if (i915_tasklet_is_enabled(t))
+ i915_tasklet_run(t);
+
+ tasklet_unlock(&t->base);
+ return true;
+}
+
+static inline void i915_tasklet(struct i915_tasklet *t)
+{
+ if (!i915_tasklet_is_enabled(t)) /* GPU reset active */
+ return;
+
+ if (!i915_tasklet_try(t))
+ i915_tasklet_schedule(t);
+}
+
#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index f2ded1796523..4e09abf7e206 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -780,6 +780,8 @@ static void guc_submission_tasklet(unsigned long data)
struct execlist_port *port = execlists->port;
struct i915_request *rq;
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+
rq = port_request(port);
while (rq && i915_request_completed(rq)) {
trace_i915_request_out(rq);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915/execlists: Direct submit onto idle engines
Bypass using the tasklet to submit the first request to HW, as the
tasklet may be deferred unto ksoftirqd and at a minimum will add in
excess of 10us (and maybe tens of milliseconds) to our execution
latency. This latency reduction is most notable when execution flows
between engines.
v2: Beware handling preemption completion from the direct submit path as
well.
v3: Make the abuse clear and track our extra state inside i915_tasklet.
v4:s/wakeup_queue/update_queue/
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_tasklet.h | 24 +++
drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++-
drivers/gpu/drm/i915/intel_lrc.c| 71 +
3 files changed, 89 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index b7cbbc2f8f69..6f3b2fedc65b 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -8,8 +8,11 @@
#define _I915_TASKLET_H_
#include
+#include
#include
+#include "i915_gem.h"
+
/**
* struct i915_tasklet - wrapper around tasklet_struct
*
@@ -19,6 +22,8 @@
*/
struct i915_tasklet {
struct tasklet_struct base;
+ unsigned long flags;
+#define I915_TASKLET_DIRECT_SUBMIT BIT(0)
};
static inline void i915_tasklet_init(struct i915_tasklet *t,
@@ -43,6 +48,14 @@ static inline bool i915_tasklet_is_enabled(const struct
i915_tasklet *t)
return likely(!atomic_read(&t->base.count));
}
+static inline bool i915_tasklet_is_direct_submit(const struct i915_tasklet *t)
+{
+ /* Only legal to be checked from inside the tasklet. */
+ GEM_BUG_ON(!i915_tasklet_is_running(t));
+
+ return t->flags & I915_TASKLET_DIRECT_SUBMIT;
+}
+
static inline void i915_tasklet_schedule(struct i915_tasklet *t)
{
tasklet_hi_schedule(&t->base);
@@ -81,4 +94,15 @@ static inline void i915_tasklet_set_func(struct i915_tasklet
*t,
i915_tasklet_enable(t);
}
+static inline void __i915_tasklet_run(const struct i915_tasklet *t)
+{
+ t->base.func(t->base.data);
+}
+
+static inline void i915_tasklet_run(const struct i915_tasklet *t)
+{
+ GEM_BUG_ON(!i915_tasklet_is_running(t));
+ __i915_tasklet_run(t);
+}
+
#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index a7afc976c3b9..f2ded1796523 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -754,14 +754,18 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
static void guc_dequeue(struct intel_engine_cs *engine)
{
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
bool submit;
local_irq_save(flags);
- spin_lock(&engine->timeline.lock);
+ if (!i915_tasklet_is_direct_submit(&engine->execlists.tasklet))
+ spin_lock(&engine->timeline.lock);
+
submit = __guc_dequeue(engine);
- spin_unlock(&engine->timeline.lock);
+
+ if (!i915_tasklet_is_direct_submit(&engine->execlists.tasklet))
+ spin_unlock(&engine->timeline.lock);
if (submit)
guc_submit(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0c3dad5c9709..70f1b5dd492a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -356,13 +356,15 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
{
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
- spin_lock_irqsave(&engine->timeline.lock, flags);
+ if (!i915_tasklet_is_direct_submit(&execlists->tasklet))
+ spin_lock_irqsave(&engine->timeline.lock, flags);
__unwind_incomplete_requests(engine);
- spin_unlock_irqrestore(&engine->timeline.lock, flags);
+ if (!i915_tasklet_is_direct_submit(&execlists->tasklet))
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
}
static inline void
@@ -601,6 +603,8 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
*/
GEM_BUG_ON(!execlists_is_active(execlists,
EXECLISTS_ACTIVE_USER));
+ GEM_BUG_ON(execlists_is_active(execlists,
+ EXECLISTS_ACTIVE_PREEMPT));
GEM_BUG_ON(!port_count(&port[0]));
if (port_count(&port[0]) > 1)
return false;
@@ -757,12 +761,16 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- unsigned l
[Intel-gfx] [PATCH 09/10] drm/i915: Speed up idle detection by kicking the tasklets
We rely on ksoftirqd to run in a timely fashion in order to drain the execlists queue. Quite frequently, it does not. In some cases we may see latencies of over 200ms triggering our idle timeouts and forcing us to declare the driver wedged! Thus we can speed up idle detection by bypassing ksoftirqd in these cases and flush our tasklet to confirm if we are indeed still waiting for the ELSP to drain. v2: Put the execlists.first check back; it is required for handling reset! v3: Follow Mika's suggestion to try and limit kicking the tasklet to only when we expect it to make a difference, i.e. in catch up after a CS interrupt, and not just execute it everytime as that is likely just to cover over our own bugs. References: https://bugs.freedesktop.org/show_bug.cgi?id=106373 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 70595e995c45..f7d67b96220b 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -933,11 +933,20 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine) if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock)) return true; + /* +* ksoftirqd has notorious latency that may cause us to +* timeout while waiting for the engine to idle as we wait for +* ksoftirqd to run the execlists tasklet to drain the ELSP. +* If we are expecting a context switch from the GPU, check now. +*/ + if (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) + i915_tasklet_try(&engine->execlists.tasklet); + /* Waiting to drain ELSP? */ if (READ_ONCE(engine->execlists.active)) return false; - /* ELSP is empty, but there are ready requests? */ + /* ELSP is empty, but there are ready requests? E.g. after reset */ if (READ_ONCE(engine->execlists.first)) return false; -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Remove tasklet flush before disable
The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution after reset (after spinning a bit during reset), but before we allow it to resume we will have cleared all the pending state. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 0a2070112b66..0dc369a9ec4d 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs *engine) * calling engine->init_hw() and also writing the ELSP. * Turning off the execlists->tasklet until the reset is over * prevents the race. -* -* Note that this needs to be a single atomic operation on the -* tasklet (flush existing tasks, prevent new tasks) to prevent -* a race between reset and set-wedged. It is not, so we do the best -* we can atm and make sure we don't lock the machine up in the more -* common case of recursively being called from set-wedged from inside -* i915_reset. */ - if (!atomic_read(&engine->execlists.tasklet.count)) - tasklet_kill(&engine->execlists.tasklet); tasklet_disable(&engine->execlists.tasklet); /* -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Direct execlists submission
Continuing the discussion with the latest refactorings, however I ran some tests to measure the impact on system (!i915) latency, using igt/benchmarks/gem_syslatency -t 120 drm-tip: latency mean=1.211us max=10us (no load) latency mean=2.611us max=83us (i915) latency mean=1.720us max=833us (no load, bg writeout) latency mean=3.294us max=607us (i915, bg writeout) this series: latency mean=1.280us max=15us (no load) latency mean=9.688us max=1271us (i915) latency mean=1.712us max=1026us (no load, bg writeout) latency mean=14.347us max=489850us (i915, bg writeout) That certainly takes the shine off directly using the tasklet for submission from the irq handler. Being selfish, I still think we can't allow the GPU to stall waiting for ksoftirqd, but at the same time we need to solve the latency issues introduced elsewhere. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Rearrange gen8_cs_irq_handler
After using direct submission from the irq handler, it is very likely
that the ENGINE_IRQ_EXECLISTS bit is unset and so we do not need to
test it first. It also follows that we then want to do a direct
submission evertime the irq_posted bit is set, and can use that as our
boolean rather than a separate local.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e1b3a7575fe7..034c603867e6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1459,31 +1459,21 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
ivybridge_parity_error_irq_handler(dev_priv, gt_iir);
}
-static void
-gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
+static void gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- bool tasklet = false;
if (iir & GT_CONTEXT_SWITCH_INTERRUPT && READ_ONCE(execlists->active))
- tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted);
+ set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
if (iir & GT_RENDER_USER_INTERRUPT) {
+ if (USES_GUC_SUBMISSION(engine->i915))
+ set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+
notify_ring(engine);
- /*
-* notify_ring() may trigger direct submission onto this
-* engine, clearing the ENGINE_IRQ_EXECLIST bit. In that
-* case, we don't want to resubmit and so clear the tasklet
-* boolean. GuC never sets the ENGINE_IRQ_EXECLIST bit and
-* so when using the GuC this equates to an unconditional
-* setting of tasklet to true.
-*/
- if (!test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
- tasklet = USES_GUC_SUBMISSION(engine->i915);
}
- if (tasklet)
+ if (engine && test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
i915_tasklet(&execlists->tasklet);
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Only sync tasklets once for recursive reset preparation
When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_tasklet.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 75668b50c81e..3f7ecbff1179 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
* Turning off the execlists->tasklet until the reset is over
* prevents the race.
*/
- i915_tasklet_disable(&engine->execlists.tasklet);
+ i915_tasklet_disable_once(&engine->execlists.tasklet);
/*
* We're using worker to queue preemption requests from the tasklet in
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index e24e4f77fe8e..b7cbbc2f8f69 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -58,6 +58,12 @@ static inline void i915_tasklet_disable(struct i915_tasklet
*t)
tasklet_disable(&t->base);
}
+static inline void i915_tasklet_disable_once(struct i915_tasklet *t)
+{
+ if (atomic_inc_return(&t->base.count) == 1)
+ tasklet_unlock_wait(&t->base);
+}
+
static inline void i915_tasklet_enable(struct i915_tasklet *t)
{
tasklet_enable(&t->base);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915: Mark up nested spinlocks
== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : warning == Summary == $ dim checkpatch origin/drm-tip c01ec3ff8d8e drm/i915: Mark up nested spinlocks 677445fc5fa2 drm/i915: Remove tasklet flush before disable 1fc1419f16a1 drm/i915: Wrap tasklet_struct for abuse -:49: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #49: new file mode 100644 -:54: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #54: FILE: drivers/gpu/drm/i915/i915_tasklet.h:1: +/* total: 0 errors, 2 warnings, 0 checks, 221 lines checked 96fc7eacdd83 drm/i915: Only sync tasklets once for recursive reset preparation 2407b8567c91 drm/i915/execlists: Direct submit onto idle engines -:86: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #86: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:757: + unsigned long uninitialized_var(flags); -:112: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #112: FILE: drivers/gpu/drm/i915/intel_lrc.c:359: + unsigned long uninitialized_var(flags); -:140: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #140: FILE: drivers/gpu/drm/i915/intel_lrc.c:764: + unsigned long uninitialized_var(flags); total: 0 errors, 3 warnings, 0 checks, 192 lines checked 0ccb45ec4488 drm/i915/execlists: Direct submission from irq handler d7c2e84cc0e1 drm/i915: Rearrange gen8_cs_irq_handler c4d4c78bc081 drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler 73c47ae8e31f drm/i915: Speed up idle detection by kicking the tasklets 10ad08a8e244 drm/i915: Detect if we missed kicking the execlists tasklet ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/10] drm/i915: Mark up nested spinlocks
== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Mark up nested spinlocks Okay! Commit: drm/i915: Remove tasklet flush before disable Okay! Commit: drm/i915: Wrap tasklet_struct for abuse Okay! Commit: drm/i915: Only sync tasklets once for recursive reset preparation Okay! Commit: drm/i915/execlists: Direct submit onto idle engines +drivers/gpu/drm/i915/intel_guc_submission.c:768:28: warning: context imbalance in 'guc_dequeue' - unexpected unlock +drivers/gpu/drm/i915/intel_lrc.c:367:39: warning: context imbalance in 'execlists_unwind_incomplete_requests' - unexpected unlock +drivers/gpu/drm/i915/intel_lrc.c:773:39: warning: context imbalance in 'execlists_dequeue' - unexpected unlock Commit: drm/i915/execlists: Direct submission from irq handler Okay! Commit: drm/i915: Rearrange gen8_cs_irq_handler Okay! Commit: drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler -O:drivers/gpu/drm/i915/intel_ringbuffer.h:652:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_ringbuffer.h:652:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_ringbuffer.h:659:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_ringbuffer.h:659:23: warning: expression using sizeof(void) Commit: drm/i915: Speed up idle detection by kicking the tasklets Okay! Commit: drm/i915: Detect if we missed kicking the execlists tasklet Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check
>
>Implements the link integrity check once in 500mSec.
>
>Once encryption is enabled, an ongoing Link Integrity Check is performed by the
>HDCP Receiver to check that cipher synchronization is maintained between the
>HDCP Transmitter and the HDCP Receiver.
>
>On the detection of synchronization lost, the HDCP Receiver must assert the
>corresponding bits of the RxStatus register. The Transmitter polls the RxStatus
>register and it may initiate re-authentication.
>
>v2:
> Rebased.
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 81
>++-
> include/drm/drm_hdcp.h| 8
> 2 files changed, 88 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 005627746ca5..e2aec73aefe3 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -23,6 +23,8 @@
>
> static int _intel_hdcp2_enable(struct intel_connector *connector); static int
>_intel_hdcp2_disable(struct intel_connector *connector);
>+static void intel_hdcp2_check_work(struct work_struct *work); static
>+int intel_hdcp2_check_link(struct intel_connector *connector);
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
> const struct intel_hdcp_shim *shim) @@ -
>1456,6 +1458,83 @@ static int _intel_hdcp2_enable(struct intel_connector
>*connector)
>
> hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
> schedule_work(&hdcp->hdcp_prop_work);
>-
>+ schedule_delayed_work(&hdcp->hdcp2_check_work,
>+DRM_HDCP2_CHECK_PERIOD_MS);
> return 0;
> }
>+
>+static int intel_hdcp2_check_link(struct intel_connector *connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ enum port port = connector->encoder->port;
>+ int ret = 0;
>+
>+ if (!hdcp->hdcp_shim)
>+ return -ENOENT;
>+
>+ mutex_lock(&hdcp->hdcp_mutex);
>+
>+ if (hdcp->hdcp_value ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>+ goto out;
>+
>+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
>LINK_ENCRYPTION_STATUS)) {
>+ DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
>+ I915_READ(HDCP2_STATUS_DDI(port)));
>+ ret = -ENXIO;
>+ hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+ goto out;
>+ }
>+
>+ ret = hdcp->hdcp_shim->check_2_2_link(intel_dig_port);
Check " hdcp->hdcp_shim->check_2_2_link " for NULL.
>+ if (!ret) {
>+ if (hdcp->hdcp_value !=
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
>+ hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+ }
>+ goto out;
>+ }
>+
>+ DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
>+ connector->base.name, connector->base.base.id);
>+
>+ ret = _intel_hdcp2_disable(connector);
>+ if (ret) {
>+ DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+
>+ hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+ goto out;
>+ }
>+
>+ ret = _intel_hdcp2_enable(connector);
>+ if (ret) {
>+ DRM_ERROR("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+
>+ hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+ goto out;
>+ }
>+
>+out:
>+ mutex_unlock(&hdcp->hdcp_mutex);
>+ return ret;
>+}
>+
>+static void intel_hdcp2_check_work(struct work_struct *work) {
>+ struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
>+ struct intel_hdcp,
>+ hdcp2_check_work);
>+ struct intel_connector *connector = container_of(hdcp,
>+ struct intel_connector,
>+
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Mark up nested spinlocks
== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4175 -> Patchwork_8993 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8993 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8993, 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/43123/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8993: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8993 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106248) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-skl-guc: PASS -> FAIL (fdo#103191, fdo#104724) Possible fixes igt@gem_exec_flush@basic-uc-set-default: fi-byt-j1900: INCOMPLETE (fdo#102657) -> PASS fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 == Participating hosts (41 -> 36) == Missing(5): fi-ctg-p8600 fi-byt-squawks fi-ilk-m540 fi-bxt-dsi fi-skl-6700hq == Build changes == * Linux: CI_DRM_4175 -> Patchwork_8993 CI_DRM_4175: a57366b6029ac86436ad36bbf8b9a31549ef2905 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4476: 03a62cf055481f66b4f58e6228bc45f8ca454216 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8993: 10ad08a8e244b440e8cdda390ed2da29bbd021ea @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4476: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Linux commits == 10ad08a8e244 drm/i915: Detect if we missed kicking the execlists tasklet 73c47ae8e31f drm/i915: Speed up idle detection by kicking the tasklets c4d4c78bc081 drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler d7c2e84cc0e1 drm/i915: Rearrange gen8_cs_irq_handler 0ccb45ec4488 drm/i915/execlists: Direct submission from irq handler 2407b8567c91 drm/i915/execlists: Direct submit onto idle engines 96fc7eacdd83 drm/i915: Only sync tasklets once for recursive reset preparation 1fc1419f16a1 drm/i915: Wrap tasklet_struct for abuse 677445fc5fa2 drm/i915: Remove tasklet flush before disable c01ec3ff8d8e drm/i915: Mark up nested spinlocks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8993/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm/i915: Mark up nested spinlocks
On 14/05/2018 10:37, Chris Wilson wrote:
When we process the outstanding requests upon banning a context, we need
to acquire both the engine and the client's timeline, nesting the locks.
This requires explicit markup as the two timelines are now of the same
class, since commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into
individual timelines").
Testcase: igt/gem_eio/banned
Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
timelines")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 89bf5d67cb74..0a2070112b66 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3119,7 +3119,7 @@ static void engine_skip_context(struct i915_request
*request)
GEM_BUG_ON(timeline == &engine->timeline);
spin_lock_irqsave(&engine->timeline.lock, flags);
- spin_lock(&timeline->lock);
+ spin_lock_nested(&timeline->lock, SINGLE_DEPTH_NESTING);
list_for_each_entry_continue(request, &engine->timeline.requests, link)
if (request->ctx == hung_ctx)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Direct execlists submission
On 14/05/2018 10:37, Chris Wilson wrote: Continuing the discussion with the latest refactorings, however I ran some tests to measure the impact on system (!i915) latency, using igt/benchmarks/gem_syslatency -t 120 drm-tip: latency mean=1.211us max=10us (no load) latency mean=2.611us max=83us (i915) latency mean=1.720us max=833us (no load, bg writeout) latency mean=3.294us max=607us (i915, bg writeout) this series: latency mean=1.280us max=15us (no load) latency mean=9.688us max=1271us (i915) latency mean=1.712us max=1026us (no load, bg writeout) latency mean=14.347us max=489850us (i915, bg writeout) That certainly takes the shine off directly using the tasklet for submission from the irq handler. Being selfish, I still think we can't allow the GPU to stall waiting for ksoftirqd, but at the same time we need to solve the latency issues introduced elsewhere. You dropped direct submit on idle from this incarnation, why? Before the above data my concern was that i915_tasklet in its current form does not buy us anything and adds boilerplate code. I was suggesting two alternatives, either no i915_tasklet at all, or different, more functional and self-contained version which you said wouldn't work with some future code. But now with this data it looks like a quite significant regression even if it fixes the rthog test case. So I don't know where this leaves us. :I Regards, Tvrtko ___ 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/6] overlay: Remove the miscalculation of window position
On 14/05/2018 09:02, Chris Wilson wrote:
We already call x11_position() to calculate the position of the
overlay, so do not need to manually recompute them inside
x11_overlay_create(). This has the advantage that x11_position()
understands the multi-monitor layout instructions.
Signed-off-by: Chris Wilson
---
overlay/x11/x11-overlay.c | 16
1 file changed, 16 deletions(-)
diff --git a/overlay/x11/x11-overlay.c b/overlay/x11/x11-overlay.c
index d08ebfc9c..ae6494295 100644
--- a/overlay/x11/x11-overlay.c
+++ b/overlay/x11/x11-overlay.c
@@ -271,22 +271,6 @@ x11_overlay_create(struct config *config, int *width, int
*height)
priv->x = x;
priv->y = y;
- if (position != POS_UNSET) {
- switch (position & 7) {
- default:
- case 0: priv->x = 0; break;
- case 1: priv->x = (scr->width - image->width)/2; break;
- case 2: priv->x = scr->width - image->width; break;
- }
-
- switch ((position >> 4) & 7) {
- default:
- case 0: priv->y = 0; break;
- case 1: priv->y = (scr->height - image->height)/2; break;
- case 2: priv->y = scr->height - image->height; break;
- }
- }
-
priv->image = image;
priv->image->data = (void *)&priv->name;
Looks OK even without full understanding of the X11 programming.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/6] lib/audio: Replace sqrt(a*a + b*b) with hypot(a, b)
On 14/05/2018 09:02, Chris Wilson wrote:
Signed-off-by: Chris Wilson
---
lib/igt_audio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/igt_audio.c b/lib/igt_audio.c
index 2321d1c6e..229ce6c69 100644
--- a/lib/igt_audio.c
+++ b/lib/igt_audio.c
@@ -266,9 +266,7 @@ bool audio_signal_detect(struct audio_signal *signal, int
channels,
max = 0;
for (i = 0; i < frames / 2; i++) {
- amplitude[i] = sqrt(data[i] * data[i] +
- data[frames - i] *
- data[frames - i]);
+ amplitude[i] = hypot(data[i], data[frames - i]);
if (amplitude[i] > max)
max = amplitude[i];
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 07/17] drm/i915/guc/slpc: Send RESET event to restart/enable SLPC tasks
On Fri, 30 Mar 2018 10:31:52 +0200, Sagar Arun Kamble
wrote:
Host to GuC actions for SLPC receive additional data as output through
scratch registers currently. intel_guc_send_and_receive handles this.
We need to define SLPC specific Host to GuC send action (slpc_send) as
wrapper on top of it to process the SLPC status that is received in
SOFT_SCRATCH(1).
Send host2guc SLPC reset event to GuC post GuC load for enabling SLPC.
Post this, i915 can ascertain if SLPC has started running successfully
through shared data. This check is done by waiting for maximum 5ms.
SLPC reset event also needs to be sent when parameters in shared data
are updated.
v1: Extract host2guc_slpc to handle slpc status code and style changes.
(Paulo). Removed WARN_ON for checking msb of gtt address of shared
gem obj. (Chris). host2guc_action to i915_guc_action change.(Sagar)
Updating SLPC enabled status. (Sagar)
v2: Commit message update. (David)
v3: Rebase.
v4: Added DRM_INFO message when SLPC is enabled.
v5: Updated patch as host2guc_slpc is moved to earlier patch. SLPC
activation status message put after checking the state from shared
data during intel_init_gt_powersave.
v6: Added definition of host2guc_slpc and clflush the shared data only
for required size. Setting state to NOT_RUNNING before sending RESET
event. Output data for SLPC actions is to be retrieved during
intel_guc_send with lock protection so created wrapper
__intel_guc_send that outputs GuC output data if needed. Clearing
pm_rps_events on confirming SLPC RUNNING status so that even if
host touches any of the PM registers by mistake it should not have
any effect. (Sagar)
v7: Added save/restore_default_rps as Uncore sanitize will clear the
RP_CONTROL setup by BIOS. s/i915_ggtt_offset/guc_ggtt_offset.
v8: Added support for handling TDR based SLPC reset. Added functions
host2guc_slpc_tdr_reset, intel_slpc_reset_prepare and
intel_slpc_tdr_reset to handle TDR based SLPC reset.
v9: Moved TDR support to later patch. Removed intel_slpc_get_status
and waiting for maximum of 5ms for SLPC state to turn RUNNING instead
of hiding the latency across uc_init_hw and init_gt_powersave.
s/if..else/switch..case in intel_guc_slpc_get_state_str. Removed SLPC
sanitization from init_gt_powersave. (Michal Wajdeczko)
v10: Rebase.
v11: Rebase. Created slpc_send func as wrapper on guc_send_and_receive.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc_slpc.c | 239
++
1 file changed, 239 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.c
b/drivers/gpu/drm/i915/intel_guc_slpc.c
index 974a3c0..bc2c717 100644
--- a/drivers/gpu/drm/i915/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/intel_guc_slpc.c
@@ -163,6 +163,211 @@ static void slpc_shared_data_init(struct
intel_guc_slpc *slpc)
kunmap_atomic(data);
}
+static const char *slpc_status_stringify(int status)
I guess this should be defined as:
static const char *slpc_status_stringify(enum slpc_status status)
or
static const char *stringify_slpc_status(enum slpc_status status)
but I'm wondering if we really need to be that user friendly,
as all these errors are unlikely and will be interpreted by the
professionals that can match error value with the enum name in code;)
+{
+ const char *str = NULL;
+
+ switch(status) {
+ case SLPC_STATUS_OK:
+ str = "Ok";
+ break;
+ case SLPC_STATUS_ERROR:
+ str = "Error";
+ break;
+ case SLPC_STATUS_ILLEGAL_COMMAND:
+ str = "Illegal command";
+ break;
+ case SLPC_STATUS_INVALID_ARGS:
+ str = "Invalid args";
+ break;
+ case SLPC_STATUS_INVALID_PARAMS:
+ str = "Invalid params";
+ break;
+ case SLPC_STATUS_INVALID_DATA:
+ str = "Invalid data";
+ break;
+ case SLPC_STATUS_OUT_OF_RANGE:
+ str = "Out of range";
+ break;
+ case SLPC_STATUS_NOT_SUPPORTED:
+ str = "Not supported";
+ break;
+ case SLPC_STATUS_NOT_IMPLEMENTED:
+ str = "Not implemented";
+ break;
+ case SLPC_STATUS_NO_DATA:
+ str = "No data";
+ break;
+ case SLPC_STATUS_EVENT_NOT_REGISTERED:
+ str = "Event not registered";
+ break;
+ case SLPC_STATUS_REGISTER_LOCKED:
+ str = "Register locked";
+ break;
+ case SLPC_STATUS_TEMPORARILY_UNAVAILABLE:
+ str = "Temporarily unavailable";
+ break;
+ case SLPC_STATUS_VALUE_ALREADY_SET:
+ str = "Value already set";
+ break;
+ cas
Re: [Intel-gfx] Direct execlists submission
Quoting Tvrtko Ursulin (2018-05-14 11:11:54) > > On 14/05/2018 10:37, Chris Wilson wrote: > > Continuing the discussion with the latest refactorings, however I ran > > some tests to measure the impact on system (!i915) latency, > > using igt/benchmarks/gem_syslatency -t 120 > > > > drm-tip: > > latency mean=1.211us max=10us (no load) > > latency mean=2.611us max=83us (i915) > > > > latency mean=1.720us max=833us (no load, bg writeout) > > latency mean=3.294us max=607us (i915, bg writeout) > > > > this series: > > latency mean=1.280us max=15us (no load) > > latency mean=9.688us max=1271us (i915) > > > > latency mean=1.712us max=1026us (no load, bg writeout) > > latency mean=14.347us max=489850us (i915, bg writeout) > > > > That certainly takes the shine off directly using the tasklet for > > submission from the irq handler. Being selfish, I still think we can't > > allow the GPU to stall waiting for ksoftirqd, but at the same time we > > need to solve the latency issues introduced elsewhere. > > You dropped direct submit on idle from this incarnation, why? It's still there, right? I just haven't made any changes towards making it more generic. > Before the above data my concern was that i915_tasklet in its current > form does not buy us anything and adds boilerplate code. I was > suggesting two alternatives, either no i915_tasklet at all, or > different, more functional and self-contained version which you said > wouldn't work with some future code. We need struct tasklet_struct, I don't think we can easily replace that locally. (And you are cc'ed on the code that truly abuses tasklet, where we mix preemption and reset from timers.) > But now with this data it looks like a quite significant regression even > if it fixes the rthog test case. So I don't know where this leaves us. :I With a challenge to solve. That nasty part is that the timings are still so small that it's in the tail of the perf profile for this, so we'll need to look at the latency tracers instead. My first instinct is that it is engine->timeline.lock contention. And that does seem like it is doing the trick... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler
On 14/05/2018 10:37, Chris Wilson wrote:
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
gen8_cs_irq_handler 512 428 -84
Impressive, or not, depends whether you look at the saving or code
generation.
Hm, actually, is it just GEM_BUG_ON in intel_uc_is_using_guc_submission?
But blimey, didn't we pencil in long time ago to stop using modparams at
runtime in favour of caching the values? This one looks like one to
confuse the driver easily if fiddled with at runtime.
Regards,
Tvrtko
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 034c603867e6..f8c39e5b5cc6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1467,7 +1467,7 @@ static void gen8_cs_irq_handler(struct intel_engine_cs
*engine, u32 iir)
set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
if (iir & GT_RENDER_USER_INTERRUPT) {
- if (USES_GUC_SUBMISSION(engine->i915))
+ if (intel_engine_uses_guc(engine))
set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
notify_ring(engine);
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 4e09abf7e206..eb2a25d84a82 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1277,6 +1277,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
engine->unpark = guc_submission_unpark;
engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
+ engine->flags |= I915_ENGINE_USES_GUC;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 70f1b5dd492a..90b534098d00 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2264,6 +2264,7 @@ static void execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->park = NULL;
engine->unpark = NULL;
+ engine->flags &= ~I915_ENGINE_USES_GUC;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
if (engine->i915->preempt_context)
engine->flags |= I915_ENGINE_HAS_PREEMPTION;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index f6ba354faf89..90d1ca2ca232 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -570,6 +570,7 @@ struct intel_engine_cs {
#define I915_ENGINE_NEEDS_CMD_PARSER BIT(0)
#define I915_ENGINE_SUPPORTS_STATS BIT(1)
#define I915_ENGINE_HAS_PREEMPTION BIT(2)
+#define I915_ENGINE_USES_GUC BIT(3)
unsigned int flags;
/*
@@ -647,6 +648,12 @@ intel_engine_has_preemption(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_HAS_PREEMPTION;
}
+static inline bool
+intel_engine_uses_guc(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_USES_GUC;
+}
+
static inline bool __execlists_need_preempt(int prio, int last)
{
return prio > max(0, last);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 08/17] drm/i915/guc/slpc: Send SHUTDOWN event to stop SLPC tasks
On Fri, 30 Mar 2018 10:31:53 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
Send SLPC shutdown event during uc_fini_hw or prior to enabling SLPC
done while communicating updated parameters in shared data.
v1: Return void instead of ignored error code (Paulo). Removed WARN_ON
for checking msb of gtt address of shared gem obj. (Chris)
Added SLPC state update during disable, suspend and reset. Changed
semantics of reset. It is supposed to just disable. (Sagar)
v2-v4: Rebase.
v5: Updated the input data structure. (Sagar)
v6: Rebase.
v7: s/i915_ggtt_offset/guc_ggtt_offset.
v8: Updated the status check post disabling to wait for 20us. (Sagar)
v9: Updated the status check wait time to 5ms for safe margin as it is
handled similar to reset by SLPC. s/slpc_disabled/slpc_stopped
v10: Rebase.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc_slpc.c | 38
+++
drivers/gpu/drm/i915/intel_uc.c | 6 +++---
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.c
b/drivers/gpu/drm/i915/intel_guc_slpc.c
index bc2c717..7f75d218 100644
--- a/drivers/gpu/drm/i915/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/intel_guc_slpc.c
@@ -368,6 +368,28 @@ static bool slpc_running(struct intel_guc_slpc
*slpc)
return (data.global_state == SLPC_GLOBAL_STATE_RUNNING);
}
+static void host2guc_slpc_shutdown(struct intel_guc_slpc *slpc)
+{
+ struct intel_guc *guc = slpc_to_guc(slpc);
+ u32 shared_data_gtt_offset = intel_guc_ggtt_offset(guc, slpc->vma);
+ struct slpc_event_input data = {0};
+
+ data.header.value = SLPC_EVENT(SLPC_EVENT_SHUTDOWN, 2);
+ data.args[0] = shared_data_gtt_offset;
data.args[0] = intel_guc_ggtt_offset(guc, slpc->vma);
+ data.args[1] = 0;
hmm, this '0' means something ? or it is MBZ ?
but since events num_args is flexible, maybe we can drop it ?
+
+ slpc_send(slpc, &data, 4);
+}
+
+static bool slpc_stopped(struct intel_guc_slpc *slpc)
+{
+ struct slpc_shared_data data;
+
+ slpc_read_shared_data(slpc, &data);
+
+ return (data.global_state == SLPC_GLOBAL_STATE_NOT_RUNNING);
+}
+
/**
* intel_guc_slpc_init() - Initialize the SLPC shared data structure.
* @slpc: pointer to intel_guc_slpc.
@@ -448,8 +470,24 @@ int intel_guc_slpc_enable(struct intel_guc_slpc
*slpc)
return 0;
}
+/**
+ * intel_guc_slpc_disable() - Stop SLPC tasks.
+ * @slpc: pointer to intel_guc_slpc.
+ *
+ * This function will stop GuC SLPC tasks by sending Host to GuC action.
+ */
void intel_guc_slpc_disable(struct intel_guc_slpc *slpc)
{
+ mutex_lock(&slpc->lock);
+
+ host2guc_slpc_shutdown(slpc);
+
+ /* Ensure SLPC is not running */
+ if (wait_for(slpc_stopped(slpc), 5))
+ DRM_ERROR("SLPC not disabled! State = %s\n",
+ slpc_get_state(slpc));
+
+ mutex_unlock(&slpc->lock);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 5bf33c8..ece6687 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -359,6 +359,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915)
GEM_BUG_ON(!HAS_GUC(i915));
+ if (USES_GUC_SLPC(dev_priv))
+ intel_guc_slpc_disable(&guc->slpc);
+
guc_disable_communication(guc);
intel_huc_sanitize(huc);
@@ -484,9 +487,6 @@ void intel_uc_fini_hw(struct drm_i915_private
*dev_priv)
if (USES_GUC_SUBMISSION(dev_priv))
intel_guc_submission_disable(guc);
- if (USES_GUC_SLPC(dev_priv))
- intel_guc_slpc_disable(&guc->slpc);
-
Can we avoid such code movement within one series ?
guc_disable_communication(guc);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mark up nested spinlocks
Quoting Chris Wilson (2018-05-12 09:49:57)
> When we process the outstanding requests upon banning a context, we need
> to acquire both the engine and the client's timeline, nesting the locks.
> This requires explicit markup as the two timelines are now of the same
> class, since commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into
> individual timelines").
>
> Testcase: igt/gem_eio/banned
> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
> timelines")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: Michel Thierry
[from resend]
Reviewed-by: Tvrtko Ursulin
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mark up nested spinlocks
Quoting Chris Wilson (2018-05-14 11:43:44)
> Quoting Chris Wilson (2018-05-12 09:49:57)
> > When we process the outstanding requests upon banning a context, we need
> > to acquire both the engine and the client's timeline, nesting the locks.
> > This requires explicit markup as the two timelines are now of the same
> > class, since commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into
> > individual timelines").
> >
> > Testcase: igt/gem_eio/banned
> > Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
> > timelines")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Joonas Lahtinen
> > Cc: Michel Thierry
>
> [from resend]
> Reviewed-by: Tvrtko Ursulin
And pushed, thanks for the review. Will push the test case once CI has
updated to the new drm-tip.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] benchmarks/gem_syslatency: Pass a write hazard around
Extend the i915 load to (optionally) pass a write hazard between
engines, causing us to wait on the interrupt between engines. Thus
adding MI_USER_INTERRUPT irq handling to our list of sins.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_syslatency.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/benchmarks/gem_syslatency.c b/benchmarks/gem_syslatency.c
index de59eaf82..9160e2199 100644
--- a/benchmarks/gem_syslatency.c
+++ b/benchmarks/gem_syslatency.c
@@ -53,6 +53,7 @@ struct gem_busyspin {
pthread_t thread;
unsigned long count;
bool leak;
+ bool interrupts;
};
struct sys_wait {
@@ -94,7 +95,7 @@ static void *gem_busyspin(void *arg)
const uint32_t bbe = MI_BATCH_BUFFER_END;
struct gem_busyspin *bs = arg;
struct drm_i915_gem_execbuffer2 execbuf;
- struct drm_i915_gem_exec_object2 obj;
+ struct drm_i915_gem_exec_object2 obj[2];
const unsigned sz = bs->leak ? 16 << 20 : 4 << 10;
unsigned engines[16];
unsigned nengine;
@@ -107,13 +108,15 @@ static void *gem_busyspin(void *arg)
for_each_engine(fd, engine)
if (!ignore_engine(fd, engine)) engines[nengine++] = engine;
- memset(&obj, 0, sizeof(obj));
- obj.handle = gem_create(fd, sz);
- gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = gem_create(fd, 4096);
+ obj[0].flags = EXEC_OBJECT_WRITE;
+ obj[1].handle = gem_create(fd, sz);
+ gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)&obj;
- execbuf.buffer_count = 1;
+ execbuf.buffers_ptr = (uintptr_t)(obj + !bs->interrupts);
+ execbuf.buffer_count = 1 + !!bs->interrupts;
execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
if (__gem_execbuf(fd, &execbuf)) {
@@ -129,9 +132,9 @@ static void *gem_busyspin(void *arg)
}
bs->count += nengine;
if (bs->leak) {
- gem_madvise(fd, obj.handle, I915_MADV_DONTNEED);
- obj.handle = gem_create(fd, sz);
- gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
+ gem_madvise(fd, obj[1].handle, I915_MADV_DONTNEED);
+ obj[1].handle = gem_create(fd, sz);
+ gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
}
}
@@ -305,13 +308,17 @@ int main(int argc, char **argv)
int field = -1;
int enable_gem_sysbusy = 1;
bool leak = false;
+ bool interrupts = false;
int n, c;
- while ((c = getopt(argc, argv, "t:f:bmn")) != -1) {
+ while ((c = getopt(argc, argv, "t:f:bmni")) != -1) {
switch (c) {
case 'n': /* dry run, measure baseline system latency */
enable_gem_sysbusy = 0;
break;
+ case 'i': /* interrupts ahoy! */
+ interrupts = true;
+ break;
case 't':
/* How long to run the benchmark for (seconds) */
time = atoi(optarg);
@@ -346,6 +353,7 @@ int main(int argc, char **argv)
for (n = 0; n < ncpus; n++) {
bind_cpu(&attr, n);
busy[n].leak = leak;
+ busy[n].interrupts = interrupts;
pthread_create(&busy[n].thread, &attr,
gem_busyspin, &busy[n]);
}
--
2.17.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 3/6] igt/gem_ctx_thrash: Order writes between contexts
On 14/05/2018 09:02, Chris Wilson wrote:
The test wrote to the same dwords from multiple contexts, assuming that
the writes would be ordered by its submission. However, as it was using
multiple contexts without a write hazard, those timelines are not
coupled and the requests may be emitted to hw in any order. So emit a
write hazard for each individual dword in the scratch (avoiding the
write hazard for the scratch as a whole) to ensure the writes do occur
in the expected order.
Signed-off-by: Chris Wilson
---
tests/gem_ctx_thrash.c | 92 --
1 file changed, 53 insertions(+), 39 deletions(-)
diff --git a/tests/gem_ctx_thrash.c b/tests/gem_ctx_thrash.c
index 2cd9cfebf..b25f95f13 100644
--- a/tests/gem_ctx_thrash.c
+++ b/tests/gem_ctx_thrash.c
@@ -90,17 +90,13 @@ static void single(const char *name, bool all_engines)
{
struct drm_i915_gem_exec_object2 *obj;
struct drm_i915_gem_relocation_entry *reloc;
- unsigned engines[16];
- uint64_t size;
- uint32_t *ctx, *map, scratch;
- unsigned num_ctx;
- int fd, gen, num_engines;
+ unsigned int engines[16], num_engines, num_ctx;
+ uint32_t *ctx, *map, scratch, size;
+ int fd, gen;
#define MAX_LOOP 16
- fd = drm_open_driver_master(DRIVER_INTEL);
+ fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
- igt_require(gem_can_store_dword(fd, 0));
-
gem_require_contexts(fd);
gen = intel_gen(intel_get_drm_devid(fd));
@@ -108,54 +104,77 @@ static void single(const char *name, bool all_engines)
num_engines = 0;
if (all_engines) {
unsigned engine;
+
for_each_physical_engine(fd, engine) {
+ if (!gem_can_store_dword(fd, engine))
+ continue;
+
engines[num_engines++] = engine;
if (num_engines == ARRAY_SIZE(engines))
break;
}
- } else
+ } else {
+ igt_require(gem_can_store_dword(fd, 0));
engines[num_engines++] = 0;
+ }
+ igt_require(num_engines);
num_ctx = get_num_contexts(fd, num_engines);
size = ALIGN(num_ctx * sizeof(uint32_t), 4096);
- scratch = gem_create(fd, ALIGN(num_ctx * sizeof(uint32_t), 4096));
+ scratch = gem_create(fd, size);
gem_set_caching(fd, scratch, I915_CACHING_CACHED);
- obj = calloc(num_ctx, 2 * sizeof(*obj));
- reloc = calloc(num_ctx, sizeof(*reloc));
+ obj = calloc(num_ctx, 3 * sizeof(*obj));
+ reloc = calloc(num_ctx, 2 * sizeof(*reloc));
ctx = malloc(num_ctx * sizeof(uint32_t));
igt_assert(ctx);
for (unsigned n = 0; n < num_ctx; n++) {
ctx[n] = gem_context_create(fd);
- obj[2*n + 0].handle = scratch;
-
- reloc[n].target_handle = scratch;
- reloc[n].presumed_offset = 0;
- reloc[n].offset = sizeof(uint32_t);
- reloc[n].delta = n * sizeof(uint32_t);
- reloc[n].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
- reloc[n].write_domain = 0; /* lies! */
+
+ obj[3*n + 0].handle = gem_create(fd, 4096);
+ reloc[2*n + 0].target_handle = obj[3*n + 0].handle;
+ reloc[2*n + 0].presumed_offset = 0;
+ reloc[2*n + 0].offset = 4000;
+ reloc[2*n + 0].delta = 0;
+ reloc[2*n + 0].read_domains = I915_GEM_DOMAIN_RENDER;
+ reloc[2*n + 0].write_domain = I915_GEM_DOMAIN_RENDER;
+
+ obj[3*n + 1].handle = scratch;
+ reloc[2*n + 1].target_handle = scratch;
+ reloc[2*n + 1].presumed_offset = 0;
+ reloc[2*n + 1].offset = sizeof(uint32_t);
+ reloc[2*n + 1].delta = n * sizeof(uint32_t);
+ reloc[2*n + 1].read_domains = I915_GEM_DOMAIN_RENDER;
+ reloc[2*n + 1].write_domain = 0; /* lies! */
if (gen >= 4 && gen < 8)
- reloc[n].offset += sizeof(uint32_t);
+ reloc[2*n + 1].offset += sizeof(uint32_t);
- obj[2*n + 1].relocs_ptr = to_user_pointer(&reloc[n]);
- obj[2*n + 1].relocation_count = 1;
+ obj[3*n + 2].relocs_ptr = to_user_pointer(&reloc[2*n]);
+ obj[3*n + 2].relocation_count = 2;
}
map = gem_mmap__cpu(fd, scratch, 0, size, PROT_WRITE);
- for (unsigned loop = 1; loop <= MAX_LOOP; loop <<= 1) {
- unsigned count = loop * num_ctx;
+ for (unsigned int loop = 1; loop <= MAX_LOOP; loop <<= 1) {
+ const unsigned int count = loop * num_ctx;
uint32_t *all;
all = malloc(count * sizeof(uint32_t));
- for (unsigned n = 0; n < count; n++)
+ for (unsigned int n = 0; n < count; n++)
all[n] = ctx[n %
Re: [Intel-gfx] [PATCH i-g-t 4/6] igt/gem_eio: Exercise banning
On 14/05/2018 09:02, Chris Wilson wrote:
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
banned
Signed-off-by: Chris Wilson
---
tests/gem_eio.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 6455c6acd..4720b47b5 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -250,6 +250,52 @@ static int __check_wait(int fd, uint32_t bo, unsigned int
wait)
return ret;
}
+static void __test_banned(int fd)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = gem_create(fd, 4096),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ };
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ unsigned long count = 0;
+
+ gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
+
+ gem_quiescent_gpu(fd);
+ igt_require(i915_reset_control(true));
+
+ igt_until_timeout(5) {
+ igt_spin_t *hang;
+
+ if (__gem_execbuf(fd, &execbuf) == -EIO) {
+ igt_info("Banned after causing %lu hangs\n", count);
+ igt_assert(count > 1);
+ return;
+ }
+
+ /* Trigger a reset, making sure we are detected as guilty */
+ hang = spin_sync(fd, 0, 0);
+ trigger_reset(fd);
+ igt_spin_batch_free(fd, hang);
+
+ count++;
+ }
+
+ igt_assert_f(false,
+"Ran for 5s, %lu hangs without being banned\n",
+count);
+}
+
+static void test_banned(int fd)
+{
+ fd = gem_reopen_driver(fd);
+ __test_banned(fd);
+ close(fd);
+}
+
#define TEST_WEDGE (1)
static void test_wait(int fd, unsigned int flags, unsigned int wait)
@@ -693,6 +739,9 @@ igt_main
igt_subtest("execbuf")
test_execbuf(fd);
+ igt_subtest("banned")
+ test_banned(fd);
+
igt_subtest("suspend")
test_suspend(fd, SUSPEND_STATE_MEM);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()
On 14/05/2018 09:02, Chris Wilson wrote:
trigger_reset() imposes a tight time constraint (2s) so that we verify
that the reset itself completes quickly. In the middle of this check, we
call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
clear out the freed memory (DROP_FREED). Those barriers may have
unbounded latency pushing beyond the 2s timeout, so restrict the
operation to only wait-for-idle (DROP_ACTIVE).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105957
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gem_eio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 4720b47b5..e1aff639d 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -74,8 +74,7 @@ static void trigger_reset(int fd)
/* And just check the gpu is indeed running again */
igt_debug("Checking that the GPU recovered\n");
gem_test_engine(fd, ALL_ENGINES);
-
- gem_quiescent_gpu(fd);
+ igt_drop_caches_set(fd, DROP_ACTIVE);
/* We expect forced reset and health check to be quick. */
igt_assert(igt_seconds_elapsed(&ts) < 2);
Sounds fine to only wait for idle:
Reviewed-by: Tvrtko Ursulin
However I am a bit surprised that under plain IGT environment RCU
latency can be so high.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()
Quoting Tvrtko Ursulin (2018-05-14 12:03:58)
>
> On 14/05/2018 09:02, Chris Wilson wrote:
> > trigger_reset() imposes a tight time constraint (2s) so that we verify
> > that the reset itself completes quickly. In the middle of this check, we
> > call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
> > clear out the freed memory (DROP_FREED). Those barriers may have
> > unbounded latency pushing beyond the 2s timeout, so restrict the
> > operation to only wait-for-idle (DROP_ACTIVE).
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105957
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/gem_eio.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> > index 4720b47b5..e1aff639d 100644
> > --- a/tests/gem_eio.c
> > +++ b/tests/gem_eio.c
> > @@ -74,8 +74,7 @@ static void trigger_reset(int fd)
> > /* And just check the gpu is indeed running again */
> > igt_debug("Checking that the GPU recovered\n");
> > gem_test_engine(fd, ALL_ENGINES);
> > -
> > - gem_quiescent_gpu(fd);
> > + igt_drop_caches_set(fd, DROP_ACTIVE);
> >
> > /* We expect forced reset and health check to be quick. */
> > igt_assert(igt_seconds_elapsed(&ts) < 2);
> >
>
> Sounds fine to only wait for idle:
>
> Reviewed-by: Tvrtko Ursulin
>
> However I am a bit surprised that under plain IGT environment RCU
> latency can be so high.
I suspect it's more of a latency issue with recent kernels or CI systems.
There are a few mysterious multi-second sleeps that cause sporadic fails
around the place. rcu_barrier() can be slow (like 30s slow) but only
under load, afaik.
-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 6/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks
On 14/05/2018 09:02, Chris Wilson wrote:
From: Tvrtko Ursulin
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
v2: Add tests to run across all engines simultaneously to encourage
ksoftirqd to kick in even more often.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson #v1
Signed-off-by: Chris Wilson
---
tests/gem_exec_latency.c | 207 +++
1 file changed, 207 insertions(+)
diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index 9498c0921..c5816427b 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -36,11 +36,15 @@
#include
#include
#include
+#include
#include "drm.h"
#include "igt_sysfs.h"
#include "igt_vgem.h"
+#include "igt_dummyload.h"
+#include "igt_stats.h"
+
#include "i915/gem_ring.h"
#define LOCAL_I915_EXEC_NO_RELOC (1<<11)
@@ -351,6 +355,189 @@ static void latency_from_ring(int fd,
}
}
+static void __rearm_spin_batch(igt_spin_t *spin)
+{
+ const uint32_t mi_arb_chk = 0x5 << 23;
+
+ *spin->batch = mi_arb_chk;
+ *spin->running = 0;
+ __sync_synchronize();
+}
+
+static void
+__submit_spin_batch(int fd, igt_spin_t *spin, unsigned int flags)
+{
+ struct drm_i915_gem_execbuffer2 eb = spin->execbuf;
+
+ eb.flags &= ~(0x3f | I915_EXEC_BSD_MASK);
+ eb.flags |= flags | I915_EXEC_NO_RELOC;
+
+ gem_execbuf(fd, &eb);
+}
+
+struct rt_pkt {
+ struct igt_mean mean;
+ double min, max;
+};
+
+static bool __spin_wait(int fd, igt_spin_t *spin)
+{
+ while (!READ_ONCE(*spin->running)) {
+ if (!gem_bo_busy(fd, spin->handle))
+ return false;
+ }
+
+ return true;
+}
+
+/*
+ * Test whether RT thread which hogs the CPU a lot can submit work with
+ * reasonable latency.
+ */
+static void
+rthog_latency_on_ring(int fd, unsigned int engine, const char *name, unsigned
int flags)
+#define RTIDLE 0x1
+{
+ const char *passname[] = { "warmup", "normal", "rt" };
+ struct rt_pkt *results;
+ unsigned int engines[16];
+ const char *names[16];
+ unsigned int nengine;
+ int ret;
+
+ results = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(results != MAP_FAILED);
+
+ nengine = 0;
+ if (engine == ALL_ENGINES) {
+ for_each_physical_engine(fd, engine) {
+ if (!gem_can_store_dword(fd, engine))
+ continue;
+
+ engines[nengine] = engine;
+ names[nengine] = e__->name;
+ nengine++;
+ }
+ igt_require(nengine > 1);
+ } else {
+ igt_require(gem_can_store_dword(fd, engine));
+ engines[nengine] = engine;
+ names[nengine] = name;
+ nengine++;
+ }
+
+ igt_fork(child, nengine) {
+ unsigned int pass = 0; /* Three passes: warmup, normal, rt. */
+
+ engine = engines[child];
+ do {
+ struct igt_mean mean;
+ double min = HUGE_VAL;
+ double max = -HUGE_VAL;
+ igt_spin_t *spin;
+
+ igt_mean_init(&mean);
+
+ if (pass == 2) {
+ struct sched_param rt =
+ { .sched_priority = 99 };
+
+ ret = sched_setscheduler(0,
+SCHED_FIFO |
SCHED_RESET_ON_FORK,
+&rt);
+ if (ret) {
+ igt_warn("Failed to set scheduling
policy!\n");
+ break;
+ }
+ }
+
+ spin = __igt_spin_batch_new_poll(fd, 0, engine);
+ if (!spin) {
+ igt_warn("Failed to create spinner! (%s)\n",
+passname[pass]);
+ break;
+ }
+ igt_spin_busywait_until_running(spin);
+
+ igt_until_timeout(pass > 0 ? 5 : 2) {
+ struct timespec ts = { };
+ double t;
+
+ igt_spin_batch_end(spin);
+ gem_sync(fd, spin->handle);
+ if (flags & RTIDLE)
+ usleep(250);
250us is how long you expect context complete to be received in?
s/RTIDLE/SUBMIT_IDLE/ ?
+
+ /*
+* If we are oversubscribe
Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks
Quoting Tvrtko Ursulin (2018-05-14 12:13:10)
>
> On 14/05/2018 09:02, Chris Wilson wrote:
> > From: Tvrtko Ursulin
> >
> > We want to make sure RT tasks which use a lot of CPU times can submit
> > batch buffers with roughly the same latency (and certainly not worse)
> > compared to normal tasks.
> >
> > v2: Add tests to run across all engines simultaneously to encourage
> > ksoftirqd to kick in even more often.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Reviewed-by: Chris Wilson #v1
> > Signed-off-by: Chris Wilson
> > ---
> > tests/gem_exec_latency.c | 207 +++
> > 1 file changed, 207 insertions(+)
> >
> > diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
> > index 9498c0921..c5816427b 100644
> > --- a/tests/gem_exec_latency.c
> > +++ b/tests/gem_exec_latency.c
> > @@ -36,11 +36,15 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "drm.h"
> >
> > #include "igt_sysfs.h"
> > #include "igt_vgem.h"
> > +#include "igt_dummyload.h"
> > +#include "igt_stats.h"
> > +
> > #include "i915/gem_ring.h"
> >
> > #define LOCAL_I915_EXEC_NO_RELOC (1<<11)
> > @@ -351,6 +355,189 @@ static void latency_from_ring(int fd,
> > }
> > }
> >
> > +static void __rearm_spin_batch(igt_spin_t *spin)
> > +{
> > + const uint32_t mi_arb_chk = 0x5 << 23;
> > +
> > + *spin->batch = mi_arb_chk;
> > + *spin->running = 0;
> > + __sync_synchronize();
> > +}
> > +
> > +static void
> > +__submit_spin_batch(int fd, igt_spin_t *spin, unsigned int flags)
> > +{
> > + struct drm_i915_gem_execbuffer2 eb = spin->execbuf;
> > +
> > + eb.flags &= ~(0x3f | I915_EXEC_BSD_MASK);
> > + eb.flags |= flags | I915_EXEC_NO_RELOC;
> > +
> > + gem_execbuf(fd, &eb);
> > +}
> > +
> > +struct rt_pkt {
> > + struct igt_mean mean;
> > + double min, max;
> > +};
> > +
> > +static bool __spin_wait(int fd, igt_spin_t *spin)
> > +{
> > + while (!READ_ONCE(*spin->running)) {
> > + if (!gem_bo_busy(fd, spin->handle))
> > + return false;
> > + }
> > +
> > + return true;
> > +}
> > +
> > +/*
> > + * Test whether RT thread which hogs the CPU a lot can submit work with
> > + * reasonable latency.
> > + */
> > +static void
> > +rthog_latency_on_ring(int fd, unsigned int engine, const char *name,
> > unsigned int flags)
> > +#define RTIDLE 0x1
> > +{
> > + const char *passname[] = { "warmup", "normal", "rt" };
> > + struct rt_pkt *results;
> > + unsigned int engines[16];
> > + const char *names[16];
> > + unsigned int nengine;
> > + int ret;
> > +
> > + results = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> > + igt_assert(results != MAP_FAILED);
> > +
> > + nengine = 0;
> > + if (engine == ALL_ENGINES) {
> > + for_each_physical_engine(fd, engine) {
> > + if (!gem_can_store_dword(fd, engine))
> > + continue;
> > +
> > + engines[nengine] = engine;
> > + names[nengine] = e__->name;
> > + nengine++;
> > + }
> > + igt_require(nengine > 1);
> > + } else {
> > + igt_require(gem_can_store_dword(fd, engine));
> > + engines[nengine] = engine;
> > + names[nengine] = name;
> > + nengine++;
> > + }
> > +
> > + igt_fork(child, nengine) {
> > + unsigned int pass = 0; /* Three passes: warmup, normal, rt. */
> > +
> > + engine = engines[child];
> > + do {
> > + struct igt_mean mean;
> > + double min = HUGE_VAL;
> > + double max = -HUGE_VAL;
> > + igt_spin_t *spin;
> > +
> > + igt_mean_init(&mean);
> > +
> > + if (pass == 2) {
> > + struct sched_param rt =
> > + { .sched_priority = 99 };
> > +
> > + ret = sched_setscheduler(0,
> > + SCHED_FIFO |
> > SCHED_RESET_ON_FORK,
> > + &rt);
> > + if (ret) {
> > + igt_warn("Failed to set scheduling
> > policy!\n");
> > + break;
> > + }
> > + }
> > +
> > + spin = __igt_spin_batch_new_poll(fd, 0, engine);
> > + if (!spin) {
> > + igt_warn("Failed to create spinner! (%s)\n",
> > + passname[pass]);
> > + break;
> > + }
> > + igt_spin_busywait_until_running(spin);
> > +
> > + igt_until_timeout(pass > 0 ? 5 : 2) {
> > +
Re: [Intel-gfx] [PATCH v12 10/17] drm/i915/guc/slpc: Add parameter set/unset/get, task control/status functions
On Fri, 30 Mar 2018 10:31:55 +0200, Sagar Arun Kamble
wrote:
SLPC behavior can be changed through set of parameters. These parameters
can be updated and queried from i915 though Host to GuC SLPC events. This
patch adds parameter update events for setting/unsetting/getting params.
Setting parameter leads to overridding of default parameter value. Unset
leads to restoring of default value by communicating with GuC SLPC
through
parameter updates in the shared data.
i915 can only query/get parameters that it overrides, so getting
parameter
value is done by only reading from the shared data.
SLPC has various tasks, GTPERF, BALANCER and DCC. These can be controlled
through pair of GuC SLPC parameters. Enable/disable of these tasks
require
combined update to both parameters hence new actions are added to control
and query the status of tasks.
v1: Use host2guc_slpc. Update slcp_param_id enum values for SLPC 2015.2.4
Return void instead of ignored error code (Paulo)
v2: Checkpatch update.
v3: Rebase.
v4: Updated with GuC firmware v9.
v5: Updated input structure to host2guc_slpc. Added functions to update
only parameters in the SLPC shared memory. This will allow to setup
shared data with all parameters and send single event to SLPC take
them into effect. Commit message update. (Sagar)
v6: Rearranged helpers to use them in slpc_shared_data_init. Added defn.
of SLPC_KMD_MAX_PARAM.
v7: Added definition of host2guc_slpc with rearrangement of patches.
Added
task control/status functions.
v8: Rebase w.r.t s/intel_guc_send/intel_guc_send_mmio.
v9: Created intel_guc_slpc_send_mmio with SLPC specific H2G action send
function. Rebase. Defined slpc_statuslist and using the same in
intel_guc_slpc_send_mmio. (Michal Wajdeczko)
v10: Rebase. Added kernel documentation to the task control functions.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc_slpc.c | 173
++
drivers/gpu/drm/i915/intel_guc_slpc.h | 5 +
2 files changed, 178 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.c
b/drivers/gpu/drm/i915/intel_guc_slpc.c
index bdafbaa..011e442 100644
--- a/drivers/gpu/drm/i915/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/intel_guc_slpc.c
@@ -404,6 +404,179 @@ static void host2guc_slpc_tdr_reset(struct
intel_guc_slpc *slpc)
slpc_send(slpc, &data, 5);
}
+static void host2guc_slpc_set_param(struct intel_guc_slpc *slpc,
+ u32 id, u32 value)
s/host2guc_slpc_set_param/slpc_send_set_param
and in general (not sure if already discussed this):
s/host2guc_slpc_/slpc_send_
+{
+ struct slpc_event_input data = {0};
+
+ data.header.value = SLPC_EVENT(SLPC_EVENT_PARAMETER_SET, 2);
+ data.args[0] = id;
+ data.args[1] = value;
+
+ slpc_send(slpc, &data, 4);
+}
+
+static void host2guc_slpc_unset_param(struct intel_guc_slpc *slpc,
+ u32 id)
+{
+ struct slpc_event_input data = {0};
+
+ data.header.value = SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1);
+ data.args[0] = id;
+
+ slpc_send(slpc, &data, 3);
+}
+
+static void slpc_set_param(struct intel_guc_slpc *slpc, u32 id, u32
value)
+{
+ struct slpc_shared_data *data = NULL;
+ struct page *page;
+
+ GEM_BUG_ON(id >= SLPC_MAX_PARAM);
+ GEM_BUG_ON(!slpc->vma);
+
+ lockdep_assert_held(&slpc->lock);
+
+ page = i915_vma_first_page(slpc->vma);
+ data = kmap_atomic(page);
+ slpc_mem_set_param(data, id, value);
hmm, why we have to pass param value by two mechanisms?
what if 'send' fails or slpc rejects that value?
+ kunmap_atomic(data);
+
+ host2guc_slpc_set_param(slpc, id, value);
+}
+
+static void slpc_unset_param(struct intel_guc_slpc *slpc, u32 id)
+{
+ struct slpc_shared_data *data = NULL;
+ struct page *page;
+
+ GEM_BUG_ON(id >= SLPC_MAX_PARAM);
+ GEM_BUG_ON(!slpc->vma);
+
+ lockdep_assert_held(&slpc->lock);
+
+ page = i915_vma_first_page(slpc->vma);
+ data = kmap_atomic(page);
+ slpc_mem_unset_param(data, id);
+ kunmap_atomic(data);
+
+ host2guc_slpc_unset_param(slpc, id);
+}
+
+static void slpc_get_param(struct intel_guc_slpc *slpc, u32 id,
+ int *overriding, u32 *value)
+{
+ struct slpc_shared_data *data = NULL;
+ struct page *page;
+ u32 bits;
+
+ GEM_BUG_ON(id >= SLPC_MAX_PARAM);
+ GEM_BUG_ON(!slpc->vma);
+
+ lockdep_assert_held(&slpc->lock);
+
+ page = i915_vma_first_page(slpc->vma);
+ data = kmap_atomic(page);
+ if (overriding) {
+ bits = data->override_params_set_bits[id >> 5];
+ *overriding = (0 != (bits & (1 << (id % 32;
+ }
+
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler
Quoting Tvrtko Ursulin (2018-05-14 11:27:56) > > On 14/05/2018 10:37, Chris Wilson wrote: > > Store whether or not we need to kick the guc's execlists emulation on > > the engine itself to avoid chasing the device info. > > > > gen8_cs_irq_handler 512 428 -84 > > Impressive, or not, depends whether you look at the saving or code > generation. The code generation also looked better, at least in my eyes. Fewer chained movs and simpler test? > Hm, actually, is it just GEM_BUG_ON in intel_uc_is_using_guc_submission? > > But blimey, didn't we pencil in long time ago to stop using modparams at > runtime in favour of caching the values? This one looks like one to > confuse the driver easily if fiddled with at runtime. Yes, this is one where once upon a time we had an engine->guc_client to inspect that we traded in for a common i915->guc_client, but that will still require a pointer dance. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 12/17] drm/i915/guc/slpc: Add enable/disable controls for SLPC tasks
On Fri, 30 Mar 2018 10:31:57 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
Adds debugfs hooks for enabling/disabling each SLPC task.
The enable/disable debugfs files are:
i915_guc_slpc_gtperf, i915_guc_slpc_balancer, and i915_guc_slpc_dcc.
Each of these can take the values: "default", "enabled", or "disabled"
v1: update for SLPC v2015.2.4
dfps and turbo merged and renamed "gtperf"
ibc split out and renamed "balancer"
Avoid magic numbers (Jon Bloomfield)
v2-v3: Rebase.
v5: Moved slpc_enable_disable_set and slpc_enable_disable_get to
intel_slpc.c. s/slpc_enable_disable_get/intel_slpc_task_status
and s/slpc_enable_disable_set/intel_slpc_task_control. Prepared
separate functions to update the task status only in the SLPC
shared memory. Passing dev_priv as parameter.
v6: Rebase. s/slpc_param_show|write/slpc_task_param_show|write.
Moved functions to intel_slpc.c. RPM Get/Put added before setting
parameters and sending RESET event explicitly. (Sagar)
v7: Rebase.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 200
1 file changed, 200 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff90577..d646a04 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2580,6 +2580,203 @@ static const struct file_operations
i915_guc_log_relay_fops = {
.release = i915_guc_log_relay_release,
};
+static const char *slpc_task_status_stringify(int state)
+{
+ const char *str = NULL;
+
+ switch (state) {
+ case SLPC_PARAM_TASK_DEFAULT:
+ str = "default\n";
no \n please
+ break;
+
+ case SLPC_PARAM_TASK_ENABLED:
+ str = "enabled\n";
+ break;
+
+ case SLPC_PARAM_TASK_DISABLED:
+ str = "disabled\n";
+ break;
+
+ default:
+ str = "unknown\n";
+ break;
+ }
+
btw, stringify_* functions can be as simple as:
switch(state)
{
case A:
return "A";
case B:
return "B";
default:
return "";
}
+ return str;
+}
+
+static int slpc_task_status_show(struct seq_file *m,
+u32 enable_id,
+u32 disable_id)
+{
+ struct drm_i915_private *dev_priv = m->private;
+ struct intel_guc_slpc *slpc = &dev_priv->guc.slpc;
+ const char *status = NULL;
+ u64 val;
+ int ret;
+
+ mutex_lock(&slpc->lock);
+ ret = intel_guc_slpc_task_status(slpc, &val, enable_id, disable_id);
s/intel_guc_slpc_task_status/intel_guc_slpc_get_task_status
+ mutex_unlock(&slpc->lock);
+
+ if (!ret)
+ status = slpc_task_status_stringify(val);
hmm, I'm not sure if status "null" is something that user want to see
if we hit non zero 'ret'
+
+ seq_printf(m, "%s", status);
hmm, as val is returned by guc fw, what if its value will not
match predefined 0..3 ? showing just "unknown" without actual
bad value may be insufficient
+
+ return 0;
+}
+
+static int slpc_task_status_write(struct seq_file *m,
+ const char __user *ubuf,
+ size_t len,
+ u32 enable_id,
+ u32 disable_id)
+{
+ struct drm_i915_private *dev_priv = m->private;
+ struct intel_guc_slpc *slpc = &dev_priv->guc.slpc;
+ int ret = 0;
+ char status[10];
+ u64 val;
+
+ if (len >= sizeof(status))
+ ret = -EINVAL;
+ else if (copy_from_user(status, ubuf, len))
+ ret = -EFAULT;
+ else
+ status[len] = '\0';
+
+ if (ret)
+ return ret;
+
+ if (!strncmp(status, "default", 7))
+ val = SLPC_PARAM_TASK_DEFAULT;
+ else if (!strncmp(status, "enabled", 7))
+ val = SLPC_PARAM_TASK_ENABLED;
+ else if (!strncmp(status, "disabled", 8))
+ val = SLPC_PARAM_TASK_DISABLED;
+ else
+ return -EINVAL;
+
+ mutex_lock(&slpc->lock);
+ ret = intel_guc_slpc_task_control(slpc, val, enable_id, disable_id);
+ mutex_unlock(&slpc->lock);
+
+ return ret;
+}
+
+static int slpc_gtperf_show(struct seq_file *m, void *data)
+{
+ return slpc_task_status_show(m,
+SLPC_PARAM_TASK_ENABLE_GTPERF,
+SLPC_PARAM_TASK_DISABLE_GTPERF);
+}
+
+static int i915_guc_slpc_gtperf_open(struct inode *inode, struct file
*file)
+{
+ struct drm_i915_private *dev_priv = inode->i_private;
+
+ return single_open(file, slpc_gtperf_show, dev_priv);
+}
+
+stati
Re: [Intel-gfx] [PATCH v12 14/17] drm/i915/guc/slpc: Add debugfs support to read/write/revert the parameters
On Fri, 30 Mar 2018 10:31:59 +0200, Sagar Arun Kamble
wrote:
Add support to set/read parameters and unset the parameters which will
revert them to default SLPC internal values. Explicit SLPC reset is
needed
on setting/unsetting some of the parameters.
This patch adds two debugfs interfaces:
1. i915_guc_slpc_params: List of all parameters that Host can configure.
Currently listing id and description of each.
2. i915_guc_slpc_param_ctl: This allows to change the parameters.
Syntax is:
* Update parameter with id with value :
echo "write " > i915_guc_slpc_param_ctl
* Read parameter with id
echo "read " > i915_guc_slpc_param_ctl
cat i915_guc_slpc_param_ctl
* Revert parameter with id to default value
echo "revert " > i915_guc_slpc_param_ctl.
v2: Moved the SLPC interfaces to i915_debugfs.c. Added error handling to
the range of parameters and parsing. Making use of intel_guc_slpc_enabled
instead of accessing status variable. Optimized token parsing.
(Michal Wajdeczko) s/i915_slpc_paramlist/i915_guc_slpc_params and
s/i915_slpc_param_ctl/i915_guc_slpc_param_ctl
v3: Rebase.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c| 156
+
drivers/gpu/drm/i915/intel_guc_slpc.c | 87
drivers/gpu/drm/i915/intel_guc_slpc.h | 18
drivers/gpu/drm/i915/intel_guc_slpc_fwif.h | 23 +
4 files changed, 284 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5c1231f..f90ad52 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2777,6 +2777,160 @@ const struct file_operations
i915_guc_slpc_dcc_fops = {
.llseek = seq_lseek
};
+static int i915_guc_slpc_params_info(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ if (!USES_GUC_SLPC(dev_priv))
+ return -ENODEV;
+
+ intel_guc_slpc_params_print(&dev_priv->guc.slpc, &p);
+
+ return 0;
+}
+
+static int slpc_param_ctl_show(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = m->private;
+ struct intel_guc_slpc *slpc = &dev_priv->guc.slpc;
+
+ if (!USES_GUC_SLPC(dev_priv))
+ return -ENODEV;
+
+ if (slpc->debug.param_id >= SLPC_MAX_PARAM)
+ return -EINVAL;
+
+ BUILD_BUG_ON(ARRAY_SIZE(slpc_params_desc) != SLPC_MAX_PARAM);
+
+ seq_printf(m, "%s=%u, override=%s\n",
+ slpc_params_desc[slpc->debug.param_id],
+ slpc->debug.param_value,
+ yesno(!!slpc->debug.param_override));
+
+ return 0;
+}
+
+static int slpc_param_ctl_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, slpc_param_ctl_show, inode->i_private);
+}
+
+/*
+ * Parse SLPC parameter control strings: (Similar to Pipe CRC handling)
+ * command: wsp* op wsp+ param id wsp+ [value] wsp*
+ * op: "read"/"write"/"revert"
+ * param id: slpc_param_id
+ * value: u32 value
+ * wsp: (#0x20 | #0x9 | #0xA)+
+ *
+ * eg.:
+ * "read 0" -> read SLPC_PARAM_TASK_ENABLE_GTPERF
+ * "write 7 500" -> set SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ to
500MHz
+ * "revert 7" -> revert SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ
to
+ *default value.
+ */
+static int slpc_param_ctl_parse(char *buf, size_t len, int *op,
+ u32 *id, u32 *value)
+{
+#define MAX_WORDS 3
+ int n_words;
+ char *words[MAX_WORDS];
+ ssize_t ret;
+
+ n_words = buffer_tokenize(buf, words, MAX_WORDS);
+ if (!(n_words == 3) && !(n_words == 2)) {
+ DRM_DEBUG_DRIVER("tokenize failed, a command is %d words\n",
+MAX_WORDS);
+ return -EINVAL;
+ }
+
+ if (!strcmp(words[0], "read"))
+ *op = READ_OP;
+ else if (!strcmp(words[0], "write"))
+ *op = WRITE_OP;
+ else if (!strcmp(words[0], "revert"))
+ *op = REVERT_OP;
+ else {
+ DRM_DEBUG_DRIVER("unknown operation\n");
+ return -EINVAL;
+ }
+
+ ret = kstrtou32(words[1], 0, id);
+ if (ret)
+ return ret;
+
+ if (n_words == 3) {
+ ret = kstrtou32(words[2], 0, value);
+ if (ret)
+ return ret;
+ }
+
+ return (n_words-1);
+}
+
+static ssize_t slpc_param_ctl_write(struct file *file, const char
__user *ubuf,
+size_t len, loff_t *offp)
+{
+ struct seq_file *m = file->private_data;
+ struct drm_i915_private *dev_priv = m->private;
+
Re: [Intel-gfx] [PULL] gvt-next for 4.18
Thanks for the reminder! :) Thanks, Zhi. -Original Message- From: Nikula, Jani Sent: Monday, May 14, 2018 11:36 AM To: Wang, Zhi A ; Zhenyu Wang ; Joonas Lahtinen ; Vivi, Rodrigo Cc: intel-gfx ; intel-gvt-dev ; Lv, Zhiyuan ; Yuan, Hang Subject: Re: [PULL] gvt-next for 4.18 On Mon, 14 May 2018, Zhi Wang wrote: > The following changes since commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c: > >drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk > (2018-05-13 > 10:29:44 +0100) > > are available in the git repository at: > >https://github.com/intel/gvt-linux.git tags/gvt-next-2018-05-14 > > for you to fetch changes up to 41e403d04e7050c8d88682939febcdbe117d4c82: > >Revert "drm/i915/gvt: set max priority for gvt context" (2018-05-14 > 05:26:09 +0800) Pulled, thanks. Please try to avoid rebases; it looks like you're now the committer for each commit but without Signed-off-by. BR, Jani. > > > - Improve the emulation of virtual non-priv register. (Yan) > - Reverse the hack of host of preemption of GVT-g. (Weinan) > - Improve untracked warning message.(Changbin) > > > Changbin Du (1): >drm/i915/gvt: Remove disable_warn_untrack and print untracked > mmio with debug level > > Weinan Li (1): >Revert "drm/i915/gvt: set max priority for gvt context" > > Zhao Yan (3): >drm/i915/gvt: let NOPID be the default value of > force_to_nonpriv registers >drm/i915/gvt: do not return error on handling force_to_nonpriv > registers >drm/i915/gvt: let force_to_nonpriv cmd handler only valid for > LRI cmd > > Zhi Wang (1): >Merge branch 'drm-intel-next-queued' into gvt-next > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 26 +- > drivers/gpu/drm/i915/gvt/gvt.h| 1 - > drivers/gpu/drm/i915/gvt/handlers.c | 35 > ++- > drivers/gpu/drm/i915/gvt/mmio.c | 2 -- > drivers/gpu/drm/i915/gvt/scheduler.c | 3 --- > 5 files changed, 39 insertions(+), 28 deletions(-) > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for benchmarks/gem_syslatency: Pass a write hazard around
== Series Details == Series: benchmarks/gem_syslatency: Pass a write hazard around URL : https://patchwork.freedesktop.org/series/43126/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4176 -> IGTPW_1353 = == Summary - WARNING == Minor unknown changes coming with IGTPW_1353 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_1353, 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/43126/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in IGTPW_1353: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in IGTPW_1353 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-elk-e7500: PASS -> INCOMPLETE (fdo#103989) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-skl-6770hq: FAIL (fdo#100368) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (41 -> 37) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * IGT: IGT_4477 -> IGTPW_1353 CI_DRM_4176: d6984daab2a47e5afeb638f31b40c36693c93d6c @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_1353: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1353/ IGT_4477: 395c23946b44b071cc376f488a3205bedb02b382 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools piglit_4477: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1353/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 16/17] drm/i915/guc/slpc: Add SLPC banner to RPS debugfs interfaces
On Fri, 30 Mar 2018 10:32:01 +0200, Sagar Arun Kamble
wrote:
When SLPC is controlling frequency requests, RPS state related to
autotuning is no longer valid. Make user aware through banner
upfront. Value read from register RPNSWREQ likely has the frequency
requested last by GuC SLPC.
v1: Replace HAS_SLPC with intel_slpc_active (Paulo)
Avoid magic numbers (Nick)
Use a function for repeated code (Jon)
v2: Add "SLPC Active" to i915_frequency_info output and
don't update cur_freq as it is driver internal request. (Chris)
v3: Removing sysfs interface gt_req_freq_mhz out of this patch
for proper division of functionality. (Sagar)
v4: idle_freq, boost_freq are also not used with SLPC.
v5: Added SLPC banner to i915_rps_boost_info and keep printing
driver internal values. (Chris)
v6: Commit message update.
v7: Rebase.
v8: Rebase.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Radoslaw Szwichtenberg
Cc: Michal Wajdeczko
Cc: Sujaritha Sundaresan
Cc: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1a66507..5d2ac24 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1068,6 +1068,9 @@ static int i915_frequency_info(struct seq_file *m,
void *unused)
struct intel_rps *rps = &dev_priv->gt_pm.rps;
int ret = 0;
+ if (USES_GUC_SLPC(dev_priv))
+ seq_puts(m, "SLPC Active\n");
+
intel_runtime_pm_get(dev_priv);
if (IS_GEN5(dev_priv)) {
@@ -2209,6 +2212,9 @@ static int i915_rps_boost_info(struct seq_file *m,
void *data)
struct intel_rps *rps = &dev_priv->gt_pm.rps;
struct drm_file *file;
+ if (USES_GUC_SLPC(dev_priv))
+ seq_puts(m, "SLPC Active\n");
[bikeshed] maybe to match below pattern:
seq_puts(m, "SLPC active? %s\n", yesno(true));
or
seq_puts(m, "SLPC active? %s\n", yesno((USES_GUC_SLPC(dev_priv)));
+
seq_printf(m, "RPS enabled? %d\n", rps->enabled);
seq_printf(m, "GPU busy? %s [%d requests]\n",
yesno(dev_priv->gt.awake), dev_priv->gt.active_requests);
___
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 [01/10] drm/i915: Mark up nested spinlocks
== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4175_full -> Patchwork_8993_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8993_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8993_full, 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/43123/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8993_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP +1 igt@kms_frontbuffer_tracking@fbc-tilingchange: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8993_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105312) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +3 igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt: shard-glk: PASS -> FAIL (fdo#104724, fdo#103167) igt@kms_setmode@basic: shard-apl: NOTRUN -> FAIL (fdo#99912) igt@perf_pmu@enable-race-vcs0: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) shard-apl: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: FAIL -> PASS igt@kms_busy@basic-flip-c: shard-apl: FAIL (fdo#103182) -> PASS igt@kms_flip@2x-absolute-wf_vblank-interruptible: shard-glk: FAIL (fdo#106087) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105707) -> PASS igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-glk: FAIL (fdo#105312) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_plane_lowres@pipe-b-tiling-y: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +10 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105312 https://bugs.freedesktop.org/show_bug.cgi?id=105312 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087 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_4175 -> Patchwork_8993 CI_DRM_4175: a57366b6029ac86436ad36bbf8b9a31549ef2905 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4476: 03a62cf055481f66b4f58e6228bc45f8ca454216 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8993: 10ad08a8e244b440e8cdda390ed2da29bbd021ea @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4476: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8993/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: Wait for PSR exit before checking for vblank evasion for an atomic update
On Sun, 29 Apr 2018, Tarun Vyas wrote: > From: Tarun Please use your full name. This will appear in git logs. > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then > the pipe_update_start call schedules itself out to check back later. > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but > lags w.r.t core kernel code, hot plugging an external display triggers > tons of "potential atomic update errors" in the dmesg, on *pipe A*. A > closer analysis reveals that we try to read the scanline 3 times and > eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL > stuck @ 1599. This issue is not seen on upstream kernels, b/c for *some* > reason we loop inside intel_pipe_update start for ~2+ msec which in this > case is more than enough to exit PSR fully, hence an *unstuck* PIPEDSL > counter, hence no error. On the other hand, the ChromeOS kernel spends > ~1.1 msec looping inside intel_pipe_update_start and hence errors out > b/c the source is still in PSR. > > Regardless, we should wait for PSR exit (if PSR is supported and active > on the current pipe) before reading the PIPEDSL, b/c if we haven't > fully exited PSR, then checking for vblank evasion isn't actually > applicable. > > This scenario applies to a configuration with an additional pipe, > as of now. Sign your work. See the Developer's Certificate of Origin in Documentation/process/submitting-patches.rst. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Updated drm-intel-testing
Hi all, The following changes tagged drm-intel-testing-2018-05-14: drm-intel-next-2018-05-14: Last drm/i915 changes for v4.18: - NV12 enabling (Chandra, Maarten) - ICL workarounds (Oscar) - ICL basic DPLL enabling (Paulo) - GVT updates - DP link config refactoring (Jani) - Module parameter to override DMC firmware (Jani) - PSR updates (José, DK, Daniel, Ville) - ICL DP vswing programming (Manasi) - ICL DBuf slice updates (Mahesh) - Selftest fixes and updates (Chris, Matthew, Oscar) - Execlist fixes and updates (Chris) - Stolen memory first 4k fix (Hans de Goede) - wait_for fixes (Mika) - Tons of GEM improvements (Chris) - Plenty of other fixes and improvements (Everyone) - Crappy changelog (Me) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ 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] igt/gem_eio: Exercise banning
On 12/05/18 02:03, Chris Wilson wrote: If we trigger "too many" resets, the context and even the file, will be banend and subsequent execbufs should fail with -EIO. Signed-off-by: Chris Wilson Does this replace gem_reset_stats@test_ban? Thanks, Antonio ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Direct execlists submission
Quoting Chris Wilson (2018-05-14 11:25:45) > Quoting Tvrtko Ursulin (2018-05-14 11:11:54) > > > > On 14/05/2018 10:37, Chris Wilson wrote: > > > Continuing the discussion with the latest refactorings, however I ran > > > some tests to measure the impact on system (!i915) latency, > > > using igt/benchmarks/gem_syslatency -t 120 > > > > > > drm-tip: > > > latency mean=1.211us max=10us (no load) > > > latency mean=2.611us max=83us (i915) > > > > > > latency mean=1.720us max=833us (no load, bg writeout) > > > latency mean=3.294us max=607us (i915, bg writeout) > > > > > > this series: > > > latency mean=1.280us max=15us (no load) > > > latency mean=9.688us max=1271us (i915) > > > > > > latency mean=1.712us max=1026us (no load, bg writeout) > > > latency mean=14.347us max=489850us (i915, bg writeout) > > > > > > That certainly takes the shine off directly using the tasklet for > > > submission from the irq handler. Being selfish, I still think we can't > > > allow the GPU to stall waiting for ksoftirqd, but at the same time we > > > need to solve the latency issues introduced elsewhere. > > But now with this data it looks like a quite significant regression even > > if it fixes the rthog test case. So I don't know where this leaves us. :I The ginormous writeout latency is a bit inconsistent. What remains consistent is that with direct submission, latency with i915 loaded remains around 10us versus 1us unloaded. The difference for direct submission is that the latency and i915 throughput remains the same even with bg writeout (with ksoftirqd there is a very noticeable fall off). I've still no clue as what causes the latency to spike so badly with bg write out. As for the 10us latency, I think that is just i915 hogging the cpu to handle the flow onto GPU, so the "fairness" issue that ksoftirqd seeks to prevent (rather than a side-effect of irqoff, as the irqoff periods do not change that much due to execlists_dequeue being the brunt of the work). I no longer think the sky is falling, or that these bad results are anything more than something we can and should improve. I think the protection from ksoftirqd is definitely more important for us. -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] igt/gem_eio: Exercise banning
Quoting Antonio Argenziano (2018-05-14 15:51:04) > > > On 12/05/18 02:03, Chris Wilson wrote: > > If we trigger "too many" resets, the context and even the file, will be > > banend and subsequent execbufs should fail with -EIO. > > > > Signed-off-by: Chris Wilson > > Does this replace gem_reset_stats@test_ban? gem_reset_stats was queued to be rewritten from scratch a few years ago. In short, no it doesn't replace as they are asking slightly different questions. gem_eio is asking that if banned we get EIO. I have no idea what API gem_reset_stats is supposed to be asking about, since banning is not an aspect of DRM_IOCTL_I915_GET_RESET_STATS and so should be treated very lightly to avoid over-specificity. (Banning is an internal kernel policy in the name of DoS prevention and not a rigorous defense or subject to user control.) -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 3/6] igt/gem_ctx_thrash: Order writes between contexts
Quoting Tvrtko Ursulin (2018-05-14 11:59:09)
>
> On 14/05/2018 09:02, Chris Wilson wrote:
> > The test wrote to the same dwords from multiple contexts, assuming that
> > the writes would be ordered by its submission. However, as it was using
> > multiple contexts without a write hazard, those timelines are not
> > coupled and the requests may be emitted to hw in any order. So emit a
> > write hazard for each individual dword in the scratch (avoiding the
> > write hazard for the scratch as a whole) to ensure the writes do occur
> > in the expected order.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/gem_ctx_thrash.c | 92 --
> > 1 file changed, 53 insertions(+), 39 deletions(-)
> >
> > diff --git a/tests/gem_ctx_thrash.c b/tests/gem_ctx_thrash.c
> > index 2cd9cfebf..b25f95f13 100644
> > --- a/tests/gem_ctx_thrash.c
> > +++ b/tests/gem_ctx_thrash.c
> > @@ -90,17 +90,13 @@ static void single(const char *name, bool all_engines)
> > {
> > struct drm_i915_gem_exec_object2 *obj;
> > struct drm_i915_gem_relocation_entry *reloc;
> > - unsigned engines[16];
> > - uint64_t size;
> > - uint32_t *ctx, *map, scratch;
> > - unsigned num_ctx;
> > - int fd, gen, num_engines;
> > + unsigned int engines[16], num_engines, num_ctx;
> > + uint32_t *ctx, *map, scratch, size;
> > + int fd, gen;
> > #define MAX_LOOP 16
> >
> > - fd = drm_open_driver_master(DRIVER_INTEL);
> > + fd = drm_open_driver(DRIVER_INTEL);
> > igt_require_gem(fd);
> > - igt_require(gem_can_store_dword(fd, 0));
> > -
> > gem_require_contexts(fd);
> >
> > gen = intel_gen(intel_get_drm_devid(fd));
> > @@ -108,54 +104,77 @@ static void single(const char *name, bool all_engines)
> > num_engines = 0;
> > if (all_engines) {
> > unsigned engine;
> > +
> > for_each_physical_engine(fd, engine) {
> > + if (!gem_can_store_dword(fd, engine))
> > + continue;
> > +
> > engines[num_engines++] = engine;
> > if (num_engines == ARRAY_SIZE(engines))
> > break;
> > }
> > - } else
> > + } else {
> > + igt_require(gem_can_store_dword(fd, 0));
> > engines[num_engines++] = 0;
> > + }
> > + igt_require(num_engines);
> >
> > num_ctx = get_num_contexts(fd, num_engines);
> >
> > size = ALIGN(num_ctx * sizeof(uint32_t), 4096);
> > - scratch = gem_create(fd, ALIGN(num_ctx * sizeof(uint32_t), 4096));
> > + scratch = gem_create(fd, size);
> > gem_set_caching(fd, scratch, I915_CACHING_CACHED);
> > - obj = calloc(num_ctx, 2 * sizeof(*obj));
> > - reloc = calloc(num_ctx, sizeof(*reloc));
> > + obj = calloc(num_ctx, 3 * sizeof(*obj));
> > + reloc = calloc(num_ctx, 2 * sizeof(*reloc));
> >
> > ctx = malloc(num_ctx * sizeof(uint32_t));
> > igt_assert(ctx);
> > for (unsigned n = 0; n < num_ctx; n++) {
> > ctx[n] = gem_context_create(fd);
> > - obj[2*n + 0].handle = scratch;
> > -
> > - reloc[n].target_handle = scratch;
> > - reloc[n].presumed_offset = 0;
> > - reloc[n].offset = sizeof(uint32_t);
> > - reloc[n].delta = n * sizeof(uint32_t);
> > - reloc[n].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
> > - reloc[n].write_domain = 0; /* lies! */
> > +
> > + obj[3*n + 0].handle = gem_create(fd, 4096);
> > + reloc[2*n + 0].target_handle = obj[3*n + 0].handle;
> > + reloc[2*n + 0].presumed_offset = 0;
> > + reloc[2*n + 0].offset = 4000;
> > + reloc[2*n + 0].delta = 0;
> > + reloc[2*n + 0].read_domains = I915_GEM_DOMAIN_RENDER;
> > + reloc[2*n + 0].write_domain = I915_GEM_DOMAIN_RENDER;
> > +
> > + obj[3*n + 1].handle = scratch;
> > + reloc[2*n + 1].target_handle = scratch;
> > + reloc[2*n + 1].presumed_offset = 0;
> > + reloc[2*n + 1].offset = sizeof(uint32_t);
> > + reloc[2*n + 1].delta = n * sizeof(uint32_t);
> > + reloc[2*n + 1].read_domains = I915_GEM_DOMAIN_RENDER;
> > + reloc[2*n + 1].write_domain = 0; /* lies! */
> > if (gen >= 4 && gen < 8)
> > - reloc[n].offset += sizeof(uint32_t);
> > + reloc[2*n + 1].offset += sizeof(uint32_t);
> >
> > - obj[2*n + 1].relocs_ptr = to_user_pointer(&reloc[n]);
> > - obj[2*n + 1].relocation_count = 1;
> > + obj[3*n + 2].relocs_ptr = to_user_pointer(&reloc[2*n]);
> > + obj[3*n + 2].relocation_count = 2;
> > }
> >
> > map = gem_mmap__cpu(fd, scratch, 0, size, PROT_WRITE);
> > - for (unsigned loop = 1; loop <= MAX_LOOP; loop <<= 1) {
> > - unsigned count
Re: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions
Thank you for the review comments Uma Shankar! On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:27 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; jani.nik...@linux.intel.com; Winkler, Tomas ; Usyskin, Alexander Cc: Vivi, Rodrigo Subject: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions This patch defines the hdcp2.2 protocol messages for the Drop redundant "the" and one of the hdcp2.2. Not required. ok HDCP2.2 authentication. v2: bit_fields are removed. Instead bitmasking used. [Tomas and Jani] prefix HDCP_2_2_ is added to the macros. [Tomas] v3: No Changes. Signed-off-by: Ramalingam C --- include/drm/drm_hdcp.h | 183 + 1 file changed, 183 insertions(+) diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index 562fa7df2637..5e0a5ed1a08e 100644 --- a/include/drm/drm_hdcp.h +++ b/include/drm/drm_hdcp.h @@ -38,4 +38,187 @@ #define DRM_HDCP_DDC_BSTATUS0x41 #define DRM_HDCP_DDC_KSV_FIFO 0x43 +#define DRM_HDCP_1_4_SRM_ID0x8 +#define DRM_HDCP_1_4_VRL_LENGTH_SIZE 3 +#define DRM_HDCP_1_4_DCP_SIG_SIZE 40 + +/** + * Protocol message definition for HDCP2.2 specification */ Multi Line comment style not needed here. Ok + +#define HDCP_STREAM_TYPE0 0x00 +#define HDCP_STREAM_TYPE1 0x01 + +/* HDCP2.2 Msg IDs */ +#define HDCP_2_2_NULL_MSG 1 +#define HDCP_2_2_AKE_INIT 2 +#define HDCP_2_2_AKE_SEND_CERT 3 +#define HDCP_2_2_AKE_NO_STORED_KM 4 +#define HDCP_2_2_AKE_STORED_KM 5 +#define HDCP_2_2_AKE_SEND_HPRIME 7 +#define HDCP_2_2_AKE_SEND_PARING_INFO 8 Typo in Pairing Fixed +#define HDCP_2_2_LC_INIT 9 +#define HDCP_2_2_LC_SEND_LPRIME10 +#define HDCP_2_2_SKE_SEND_EKS 11 +#define HDCP_2_2_REP_SEND_RECVID_LIST 12 +#define HDCP_2_2_REP_SEND_ACK 15 +#define HDCP_2_2_REP_STREAM_MANAGE 16 +#define HDCP_2_2_REP_STREAM_READY 17 +#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50 + +#define HDCP_2_2_RTX_LEN 8 +#define HDCP_2_2_RRX_LEN 8 + +#define HDCP_2_2_K_PUB_RX_MOD_N_LEN128 +#define HDCP_2_2_K_PUB_RX_EXP_E_LEN3 +#define HDCP_2_2_K_PUB_RX_LEN (HDCP_2_2_K_PUB_RX_MOD_N_LEN + \ + HDCP_2_2_K_PUB_RX_EXP_E_LEN) + +#define HDCP_2_2_DCP_LLC_SIG_LEN 384 + +#define HDCP_2_2_E_KPUB_KM_LEN 128 +#define HDCP_2_2_E_KH_KM_M_LEN (16 + 16) +#define HDCP_2_2_H_PRIME_LEN 32 +#define HDCP_2_2_E_KH_KM_LEN 16 +#define HDCP_2_2_RN_LEN8 +#define HDCP_2_2_L_PRIME_LEN 32 +#define HDCP_2_2_E_DKEY_KS_LEN 16 +#define HDCP_2_2_RIV_LEN 8 +#define HDCP_2_2_SEQ_NUM_LEN 3 +#define HDCP_2_2_LPRIME_HALF_LEN (HDCP_2_2_L_PRIME_LEN / 2) +#define HDCP_2_2_RECEIVER_ID_LEN DRM_HDCP_KSV_LEN +#define HDCP_2_2_MAX_DEVICE_COUNT 31 +#define HDCP_2_2_RECEIVER_IDS_MAX_LEN (HDCP_2_2_RECEIVER_ID_LEN * \ + HDCP_2_2_MAX_DEVICE_COUNT) +#define HDCP_2_2_MPRIME_LEN32 + +/** Remove an extra "*". + * TODO: This has to be changed for DP MST, as multiple stream on + * same port is possible. + * For HDCP2.2 on HDMI and DP SST this value is always 1. + */ +#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT 1 +#define HDCP_2_2_TXCAP_MASK_LEN2 +#define HDCP_2_2_RXCAPS_LEN3 +#define HDCP_2_2_RX_REPEATER(x)(x & BIT(0)) +#define HDCP_2_2_DP_HDCP_CAPABLE(x)(x & BIT(1)) +#define HDCP_2_2_RXINFO_LEN2 + +/* HDCP1.x compliant device in downstream */ +#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x) (x & BIT(0)) + +/* HDCP2.0 Compliant repeater in downstream */ +#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x) (x & BIT(1)) +#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x) (x & BIT(2)) +#define HDCP_2_2_MAX_DEVS_EXCEEDED(x) (x & BIT(3)) +#define HDCP_2_2_DEV_COUNT_LO(x) ((x & (0xF << 4)) >> 4) +#define HDCP_2_2_DEV_COUNT_HI(x) (x & BIT(0)) As per 2.2 spec this is a 5 bit field and no mention of HI and LO is there for dev count. A comment explaining why this masking style is chosen will be helpful since it doesn't match exactly with spec. dev count is spread across multi byte value. And these macros are processing the each byte separately. Agreed
[Intel-gfx] [PATCH v5 5/7] drm/i915/perf: lock powergating configuration to default when active
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.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 24 +++-
drivers/gpu/drm/i915/i915_request.c| 2 ++
drivers/gpu/drm/i915/i915_request.h| 11 +++
drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 26 +-
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
6 files changed, 58 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index fc5b5d66abcd..9cfbd5075097 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1577,7 +1577,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,
+ union intel_sseu sseu)
{
struct drm_i915_private *dev_priv = ctx->i915;
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
@@ -1623,6 +1624,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(&INTEL_INFO(dev_priv)->sseu, sseu));
}
/*
@@ -1754,6 +1758,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
const struct i915_oa_config *oa_config)
{
struct intel_engine_cs *engine = dev_priv->engine[RCS];
+ union intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
struct i915_gem_context *ctx;
int ret;
unsigned int wait_flags = I915_WAIT_LOCKED;
@@ -1798,7 +1804,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);
i915_gem_object_unpin_map(ce->state->obj);
}
@@ -2170,14 +2177,21 @@ void i915_oa_init_reg_state(struct intel_engine_cs
*engine,
struct i915_gem_context *ctx,
u32 *reg_state)
{
+ struct drm_i915_private *dev_priv = engine->i915;
struct i915_perf_stream *stream;
if (engine->id != RCS)
return;
- stream = engine->i915->perf.oa.exclusive_stream;
- if (stream)
- gen8_update_reg_state_unlocked(ctx, reg_state,
stream->oa_config);
+ stream = dev_priv->perf.oa.exclusive_stream;
+ if (stream) {
+ union intel_sseu default_sseu =
+
intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
+
+ gen8_update_reg_state_unlocked(ctx, reg_state,
+ stream->oa_config,
+ default_sseu);
+ }
}
[Intel-gfx] [PATCH v5 1/7] 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 15434cad5430..690b41b751ec 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2397,13 +2397,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.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/7] 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)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.c | 9 +
drivers/gpu/drm/i915/i915_gem_context.h | 16
drivers/gpu/drm/i915/i915_request.h | 13 +
drivers/gpu/drm/i915/intel_lrc.c| 22 +++---
4 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 33f8a4b3c981..01310c99e032 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -266,6 +266,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
{
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -314,6 +316,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
* is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+ /* On all engines, use the whole device by default */
+ for_each_engine(engine, dev_priv, id) {
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ ce->sseu =
intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
+ }
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index ace3b129c189..5a2d10f03787 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -30,6 +30,7 @@
#include
#include "i915_gem.h"
+#include "intel_device_info.h"
struct pid;
@@ -149,6 +150,8 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ /** sseu: Control eu/slice partitioning */
+ union intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
@@ -326,4 +329,17 @@ static inline void i915_gem_context_put(struct
i915_gem_context *ctx)
kref_put(&ctx->ref, i915_gem_context_release);
}
+static inline union intel_sseu
+intel_sseu_from_device_sseu(const struct sseu_dev_info *sseu)
+{
+ union 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;
+}
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index eddbd4245cb3..beb312ac9aa0 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,19 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+union intel_sseu {
+ struct {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+ };
+ u64 value;
+};
+
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 690b41b751ec..f188ba1b5608 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2392,8 +2392,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,
+union intel_sseu ctx_sseu)
{
u32 rpcs = 0;
@@ -2403,24 +2403,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) << GEN
[Intel-gfx] [PATCH v5 3/7] drm/i915/perf: simplify configure all context function
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
---
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 019bd2d073ad..94466aeafd02 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1765,7 +1765,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
@@ -1782,7 +1782,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
*/
ret = i915_gem_wait_for_idle(dev_priv, wait_flags);
if (ret)
- goto out;
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
@@ -1794,10 +1794,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);
@@ -1807,7 +1805,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.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/7] drm/i915: per context slice/subslice powergating
Hi, This is a different approach to the perf & powergating interaction problem. In this version we basically disable powergating when i915/perf is on. We do something similar already in that we disable RC6 for similar reasons. Cheers, 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 (4): 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 drm/i915: count powergating transitions per engine drivers/gpu/drm/i915/i915_gem_context.c | 178 drivers/gpu/drm/i915/i915_gem_context.h | 16 +++ drivers/gpu/drm/i915/i915_perf.c| 69 + drivers/gpu/drm/i915/i915_request.c | 2 + drivers/gpu/drm/i915/i915_request.h | 24 drivers/gpu/drm/i915/intel_engine_cs.c | 5 + drivers/gpu/drm/i915/intel_lrc.c| 148 ++-- drivers/gpu/drm/i915/intel_lrc.h| 3 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + drivers/gpu/drm/i915/intel_ringbuffer.h | 16 +++ include/uapi/drm/i915_drm.h | 38 + 11 files changed, 425 insertions(+), 76 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 7/7] 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(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
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)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 169
drivers/gpu/drm/i915/intel_lrc.c| 103 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 38 ++
5 files changed, 281 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 01310c99e032..0b72a771c3f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -734,6 +734,110 @@ int i915_gem_context_destroy_ioctl(struct drm_device
*dev, void *data,
return 0;
}
+static int
+intel_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+ const struct drm_i915_gem_context_param_sseu
*user_sseu,
+ union intel_sseu *ctx_sseu)
+{
+ if ((user_sseu->slice_mask & ~sseu->slice_mask) != 0 ||
+ user_sseu->slice_mask == 0)
+ return -EINVAL;
+
+ if ((user_sseu->subslice_mask & ~sseu->subslice_mask[0]) != 0 ||
+ user_sseu->subslice_mask == 0)
+ return -EINVAL;
+
+ if (user_sseu->min_eus_per_subslice > sseu->max_eus_per_subslice)
+ return -EINVAL;
+
+ if (user_sseu->max_eus_per_subslice > sseu->max_eus_per_subslice ||
+ user_sseu->max_eus_per_subslice < user_sseu->min_eus_per_subslice ||
+ user_sseu->max_eus_per_subslice == 0)
+ return -EINVAL;
+
+ ctx_sseu->slice_mask = user_sseu->slice_mask;
+ ctx_sseu->subslice_mask = user_sseu->subslice_mask;
+ ctx_sseu->min_eus_per_subslice = user_sseu->min_eus_per_subslice;
+ ctx_sseu->max_eus_per_subslice = user_sseu->max_eus_per_subslice;
+
+ return 0;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ union intel_sseu sseu)
+{
+ struct drm_i915_private *dev_priv = ctx->i915;
+ struct i915_timeline *timeline;
+ struct i915_request *rq;
+ union intel_sseu actual_sseu;
+ enum intel_engine_id id;
+ int ret;
+
+ /*
+* First notify user when this capability is not available so that it
+* can be detected with any valid input.
+*/
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ if (to_intel_context(ctx, engine)->sseu.value == sseu.value)
+ return 0;
+
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
+ i915_retire_requests(dev_priv);
+
+ /* Now use the RCS to actually reconfigure. */
+ engine = dev_priv->engine[RCS];
+
+ rq = i915_request_alloc(engine, dev_priv->kernel_context);
+ if (IS_ERR(rq))
+ re
[Intel-gfx] [PATCH v5 6/7] drm/i915: count powergating transitions per engine
This can be used to monitor the number of powergating transition
changes for a particular workload.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 12
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 9f86e40f22a7..ab3ab80daf62 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -494,6 +494,7 @@ void intel_engine_setup_common(struct intel_engine_cs
*engine)
i915_timeline_init(engine->i915, &engine->timeline, engine->name);
memset(&engine->last_sseu, 0, sizeof(engine->last_sseu));
+ atomic_set(&engine->sseu_transitions, 0);
intel_engine_init_execlist(engine);
intel_engine_init_hangcheck(engine);
@@ -1428,6 +1429,8 @@ void intel_engine_dump(struct intel_engine_cs *engine,
hexdump(m, engine->status_page.page_addr, PAGE_SIZE);
drm_printf(m, "Idle? %s\n", yesno(intel_engine_is_idle(engine)));
+
+ drm_printf(m, "Powergating transitions: %u\n",
atomic_read(&engine->sseu_transitions));
}
static u8 user_class_map[] = {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0e93ad90d039..320b416482e1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -520,6 +520,11 @@ static void port_assign(struct execlist_port *port, struct
i915_request *rq)
if (port_isset(port))
i915_request_put(port_request(port));
+ if (rq->sseu.value != rq->engine->last_sseu.value) {
+ rq->engine->last_sseu = rq->sseu;
+ atomic_inc(&rq->engine->sseu_transitions);
+ }
+
port_set(port, port_pack(i915_request_get(rq), port_count(port)));
}
@@ -779,6 +784,7 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
while (num_ports-- && port_isset(port)) {
struct i915_request *rq = port_request(port);
+ bool completed = i915_request_completed(rq);
GEM_TRACE("%s:port%u global=%d (fence %llx:%d), (current %d)\n",
rq->engine->name,
@@ -789,10 +795,18 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
GEM_BUG_ON(!execlists->active);
execlists_context_schedule_out(rq,
- i915_request_completed(rq) ?
+ completed ?
INTEL_CONTEXT_SCHEDULE_OUT :
INTEL_CONTEXT_SCHEDULE_PREEMPTED);
+ /*
+* Update the last known sseu configuration to the first
+* uncompleted request. Notice this works because we pop the
+* requests out of the ports in reverse order.
+*/
+ if (!completed)
+ rq->engine->last_sseu = rq->sseu;
+
i915_request_put(rq);
memset(port, 0, sizeof(*port));
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 010750e8ee44..cc7e73730469 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -343,6 +343,18 @@ struct intel_engine_cs {
struct drm_i915_gem_object *default_state;
+ /**
+* @last_sseu: The last SSEU configuration submitted to the
+* hardware. Set to 0 if unknown.
+*/
+ union intel_sseu last_sseu;
+
+ /**
+* @sseu_transitions: A counter of the number of powergating
+* transition this engine has gone through.
+*/
+ atomic_t sseu_transitions;
+
atomic_t irq_count;
unsigned long irq_posted;
#define ENGINE_IRQ_BREADCRUMB 0
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/7] drm/i915/perf: reuse intel_lrc ctx regs macro
Signed-off-by: Lionel Landwerlin
---
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 94466aeafd02..fc5b5d66abcd 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
@@ -1582,27 +1583,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
@@ -1622,8 +1621,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.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines
On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:27 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; jani.nik...@linux.intel.com; Winkler, Tomas ; Usyskin, Alexander Cc: Vivi, Rodrigo Subject: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines In preparation for implementing HDCP2.2 in I915, this patch adds HDCP register definitions for HDMI and DP HDCP adaptations. I believe we can just keep this message generic at drm layer, instead of calling out i915 specifically. Currently it may be enabled for i915, but it will used for other drivers as well in future. ok HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h, where are Make it "where as". ok HDCP2.2 register offsets in DPCD offsets are defined at drm_dp_helper.h. v2: bit_field definitions are replaced by macros. [Tomas and Jany] Typo in "Jani's" name. Sorry Jani. v3: No Changes. Signed-off-by: Ramalingam C --- include/drm/drm_dp_helper.h | 54 + include/drm/drm_hdcp.h | 29 2 files changed, 83 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 4de97e94ef9d..2185b3a88911 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -887,6 +887,60 @@ #define DP_AUX_HDCP_KSV_FIFO0x6802C #define DP_AUX_HDCP_AINFO 0x6803B +/** + * DP HDCP2.2 parameter offsets in DPCD address space */ Rectify the comment style ok +#define DP_HDCP_2_2_REG_RTX_OFFSET 0x69000 +#define DP_HDCP_2_2_REG_TXCAPS_OFFSET 0x69008 +#define DP_HDCP_2_2_REG_CERT_RX_OFFSET 0x6900B +#define DP_HDCP_2_2_REG_RRX_OFFSET 0x69215 +#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET 0x6921D +#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET0x69220 +#define DP_HDCP_2_2_REG_EKH_KM_OFFSET 0x692A0 +#define DP_HDCP_2_2_REG_M_OFFSET 0x692B0 +#define DP_HDCP_2_2_REG_HPRIME_OFFSET 0x692C0 +#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET 0x692E0 +#define DP_HDCP_2_2_REG_RN_OFFSET 0x692F0 +#define DP_HDCP_2_2_REG_LPRIME_OFFSET 0x692F8 +#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET0x69318 +#defineDP_HDCP_2_2_REG_RIV_OFFSET 0x69328 +#define DP_HDCP_2_2_REG_RXINFO_OFFSET 0x69330 +#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET 0x69332 +#define DP_HDCP_2_2_REG_VPRIME_OFFSET 0x69335 +#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET0x69345 +#define DP_HDCP_2_2_REG_V_OFFSET 0x693E0 +#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET 0x693F0 +#define DP_HDCP_2_2_REG_K_OFFSET 0x693F3 +#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET 0x693F5 +#define DP_HDCP_2_2_REG_MPRIME_OFFSET 0x69473 +#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET0x69493 +#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494 This is not matching to the spec. Seems reserved in spec. Not really. Register is defined in the DP HDCP2.2 Spec. +#define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518 + +/** + * DP HDCP message start offsets in DPCD address space */ Rectify comment style +#define DP_HDCP_2_2_AKE_INIT_OFFSET DP_HDCP_2_2_REG_RTX_OFFSET +#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET +#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET DP_HDCP_2_2_REG_EKPUB_KM_OFFSET +#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET DP_HDCP_2_2_REG_EKH_KM_OFFSET +#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET DP_HDCP_2_2_REG_HPRIME_OFFSET +#define DP_HDCP_2_2_AKE_SEND_PARING_INFO_OFFSET Typo in pairing Fixed. DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET +#define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET +#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET DP_HDCP_2_2_REG_LPRIME_OFFSET +#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET DP_HDCP_2_2_REG_EDKEY_KS_OFFSET +#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET DP_HDCP_2_2_REG_RXINFO_OFFSET +#define DP_HDCP_2_2_REP_SEND_ACK_OFFSET DP_HDCP_2_2_REG_V_OFFSET +#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET +#define DP_HDCP_2_2_REP_STREAM_READY_OFFSET DP_HDCP_2_2_REG_MPRIME_OFFSET + +#define HDCP_2_2_DP_RXSTATUS_LEN 1 +#define HDCP_2_2_DP_RXSTATUS_READY(x) (x & BIT(0)) +#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x)(x & BIT(1)) +#define HDCP_2_2_DP_RXSTATUS_PAIRING(x)(x & BIT(2)) +#define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x) (x & BIT(3)) +#define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x)(x & BIT(4)) + /* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ Make it multi
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating (rev4)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev4) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip d66d43edbd8d drm/i915: Program RPCS for Broadwell 61ad4a566887 drm/i915: Record the sseu configuration per-context & engine ad11435f9851 drm/i915/perf: simplify configure all context function c5534ae9cbfb drm/i915/perf: reuse intel_lrc ctx regs macro 5d2fc23e9965 drm/i915/perf: lock powergating configuration to default when active 2060fd56a22b drm/i915: count powergating transitions per engine a68f546b6c49 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, 374 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating (rev4)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev4) URL : https://patchwork.freedesktop.org/series/42285/ 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 Okay! 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 -drivers/gpu/drm/i915/gvt/gtt.c:671:9:expected void [noderef] **slot -drivers/gpu/drm/i915/gvt/gtt.c:671:9:expected void **slot -drivers/gpu/drm/i915/gvt/gtt.c:671:9:expected void **slot -drivers/gpu/drm/i915/gvt/gtt.c:671:9:expected void **slot -drivers/gpu/drm/i915/gvt/gtt.c:671:9:got void [noderef] ** -drivers/gpu/drm/i915/gvt/gtt.c:671:9:got void [noderef] ** -drivers/gpu/drm/i915/gvt/gtt.c:671:9:got void [noderef] ** -drivers/gpu/drm/i915/gvt/gtt.c:671:9:got void **slot -drivers/gpu/drm/i915/gvt/gtt.c:671:9: warning: incorrect type in argument 1 (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:671:9: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:671:9: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:671:9: warning: incorrect type in assignment (different address spaces) -drivers/gpu/drm/i915/gvt/gtt.c:672:45:expected void [noderef] **slot -drivers/gpu/drm/i915/gvt/gtt.c:672:45:got void **slot -drivers/gpu/drm/i915/gvt/gtt.c:672:45: warning: incorrect type in argument 1 (different address spaces) -drivers/gpu/drm/i915/gvt/mmio.c:253:23: warning: memcpy with byte count of 279040 -drivers/gpu/drm/i915/gvt/mmio.c:254:23: warning: memcpy with byte count of 279040 -drivers/gpu/drm/i915/gvt/vgpu.c:144:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:144:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gvt/vgpu.c:192:48: warning: expression using sizeof(void) +^~ + ^~ -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_drv.h:3663:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gpu_error.c:955:21: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gpu_error.c:955:21: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_perf.c:1368:15: warning: memset with byte count of 16777216 -drivers/gpu/drm/i915/i915_perf.c:1426:15: warning: memset with byte count of 16777216 -drivers/gpu/drm/i915/intel_bios.c:1489:24: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2136:37: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2139:37: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2159:29: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2167:29: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2200:29: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2200:29: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2236:37: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2236:37: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_cdclk.c:2438:17: warning: expression using sizeof(void) -driver
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: per context slice/subslice powergating (rev4)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev4) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4178 -> Patchwork_8994 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8994 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8994, 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/42285/revisions/4/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8994: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8994 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-elk-e7500: PASS -> DMESG-WARN (fdo#105225) igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: fi-elk-e7500: SKIP -> INCOMPLETE (fdo#103989) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-kbl-7567u: PASS -> FAIL (fdo#103191, fdo#104724) igt@prime_vgem@basic-fence-flip: fi-kbl-7500u: PASS -> FAIL (fdo#104008) Possible fixes igt@drv_module_reload@basic-reload: fi-glk-j4005: DMESG-WARN (fdo#106248) -> PASS igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_busy@basic-flip-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS +2 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105225 https://bugs.freedesktop.org/show_bug.cgi?id=105225 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 == Participating hosts (41 -> 37) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4178 -> Patchwork_8994 CI_DRM_4178: 8213a085ddd82871fab4bf94d1a3555fcdf9e6ac @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4478: b871b10f2a6250d6dbe31665b267820fee829c84 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8994: a68f546b6c496e87a752530012cff9ce1a3a5bef @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4478: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Linux commits == a68f546b6c49 drm/i915: Expose RPCS (SSEU) configuration to userspace 2060fd56a22b drm/i915: count powergating transitions per engine 5d2fc23e9965 drm/i915/perf: lock powergating configuration to default when active c5534ae9cbfb drm/i915/perf: reuse intel_lrc ctx regs macro ad11435f9851 drm/i915/perf: simplify configure all context function 61ad4a566887 drm/i915: Record the sseu configuration per-context & engine d66d43edbd8d drm/i915: Program RPCS for Broadwell == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8994/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk
Factor in clear values wherever required while updating destination
min/max.
References: HSDES#160184
Signed-off-by: Michel Thierry
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala
Cc: Oscar Mateo
Reviewed-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
Cc: sta...@vger.kernel.org
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_engine_cs.c | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..8a69a9275e28 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7326,6 +7326,9 @@ enum {
#define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
#define PIXEL_MASK_CAMMING_DISABLE (1 << 14)
+#define GEN9_WM_CHICKEN3 _MMIO(0x5588)
+#define GEN9_FACTOR_IN_CLR_VAL_HIZ (1 << 9)
+
/* WaCatErrorRejectionIssue */
#define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
#define GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..f7c25828d3bb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1149,6 +1149,10 @@ static int gen9_init_workarounds(struct intel_engine_cs
*engine)
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
+ /* WaClearHIZ_WM_CHICKEN3:bxt,glk */
+ if (IS_GEN9_LP(dev_priv))
+ WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
+
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
if (ret)
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Nuke PSR support for VLV and CHV
On Mon, 2018-05-14 at 12:09 +0300, Jani Nikula wrote:
> On Fri, 11 May 2018, Dhinakaran Pandiyan om> wrote:
> >
> > PSR hardware and hence the driver code for VLV and CHV deviates a
> > lot from
> > their DDI counterparts. While the feature has been disabled for a
> > long time
> > now, retaining support for these platforms is a maintenance burden.
> > There
> > have been multiple refactoring commits to just keep the existing
> > code for
> > these platforms in line with the rest. There are known issues that
> > need to
> > be fixed to enable PSR on these platforms, and there is no PSR
> > capable
> > platform in CI to ensure the code does not break again if we get
> > around to
> > fixing the existing issues. On account of all these reasons, let's
> > nuke
> > this code for now and bring it back if a need arises in the future.
> >
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjälä
> > Signed-off-by: Dhinakaran Pandiyan
> Acked-by: Jani Nikula
>
Thank you.
Including Rodrigo's ack that was sent internally
Acked-by: Rodrigo Vivi
> >
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 42 +-
> > drivers/gpu/drm/i915/i915_drv.h | 1 -
> > drivers/gpu/drm/i915/i915_pci.c | 2 -
> > drivers/gpu/drm/i915/intel_drv.h | 2 -
> > drivers/gpu/drm/i915/intel_frontbuffer.c | 2 -
> > drivers/gpu/drm/i915/intel_psr.c | 248 +++--
> > --
> > 6 files changed, 27 insertions(+), 270 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 13e7b9e4a6e6..0096e209fe04 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2630,8 +2630,6 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > u32 psrperf = 0;
> > - u32 stat[3];
> > - enum pipe pipe;
> > bool enabled = false;
> > bool sink_support;
> >
> > @@ -2652,47 +2650,17 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "Re-enable work scheduled: %s\n",
> > yesno(work_busy(&dev_priv->psr.work.work)));
> >
> > - if (HAS_DDI(dev_priv)) {
> > - if (dev_priv->psr.psr2_enabled)
> > - enabled = I915_READ(EDP_PSR2_CTL) &
> > EDP_PSR2_ENABLE;
> > - else
> > - enabled = I915_READ(EDP_PSR_CTL) &
> > EDP_PSR_ENABLE;
> > - } else {
> > - for_each_pipe(dev_priv, pipe) {
> > - enum transcoder cpu_transcoder =
> > - intel_pipe_to_cpu_transcoder(dev_p
> > riv, pipe);
> > - enum intel_display_power_domain
> > power_domain;
> > -
> > - power_domain =
> > POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> > - if
> > (!intel_display_power_get_if_enabled(dev_priv,
> > - po
> > wer_domain))
> > - continue;
> > -
> > - stat[pipe] = I915_READ(VLV_PSRSTAT(pipe))
> > &
> > - VLV_EDP_PSR_CURR_STATE_MASK;
> > - if ((stat[pipe] ==
> > VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
> > - (stat[pipe] ==
> > VLV_EDP_PSR_ACTIVE_SF_UPDATE))
> > - enabled = true;
> > -
> > - intel_display_power_put(dev_priv,
> > power_domain);
> > - }
> > - }
> > + if (dev_priv->psr.psr2_enabled)
> > + enabled = I915_READ(EDP_PSR2_CTL) &
> > EDP_PSR2_ENABLE;
> > + else
> > + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> >
> > seq_printf(m, "Main link in standby mode: %s\n",
> > yesno(dev_priv->psr.link_standby));
> >
> > - seq_printf(m, "HW Enabled & Active bit: %s",
> > yesno(enabled));
> > -
> > - if (!HAS_DDI(dev_priv))
> > - for_each_pipe(dev_priv, pipe) {
> > - if ((stat[pipe] ==
> > VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
> > - (stat[pipe] ==
> > VLV_EDP_PSR_ACTIVE_SF_UPDATE))
> > - seq_printf(m, " pipe %c",
> > pipe_name(pipe));
> > - }
> > - seq_puts(m, "\n");
> > + seq_printf(m, "HW Enabled & Active bit: %s\n",
> > yesno(enabled));
> >
> > /*
> > - * VLV/CHV PSR has no kind of performance counter
> > * SKL+ Perf counter is reset to 0 everytime DC state is
> > entered
> > */
> > if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 57fb3aa09db0..7e2a400d33c3 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -607,7 +607,6 @@ struct i915_psr {
> > bool link_standby;
> > bool colorimetry_support;
> > bool alpm;
> > - bool has_hw_tracking;
> > bool
[Intel-gfx] [PATCH 1/5] drm/i915: Clean up ADPA pipe select bits
From: Ville Syrjälä
Clean up the ADPA pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 11 +-
drivers/gpu/drm/i915/intel_crt.c | 40 ++--
drivers/gpu/drm/i915/intel_display.c | 24 +-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
4 files changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f11bb213ec07..ae3c26216996 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4133,11 +4133,12 @@ enum {
#define ADPA_DAC_ENABLE (1<<31)
#define ADPA_DAC_DISABLE 0
-#define ADPA_PIPE_SELECT_MASK(1<<30)
-#define ADPA_PIPE_A_SELECT 0
-#define ADPA_PIPE_B_SELECT (1<<30)
-#define ADPA_PIPE_SELECT(pipe) ((pipe) << 30)
-/* CPT uses bits 29:30 for pch transcoder select */
+#define ADPA_PIPE_SEL_SHIFT 30
+#define ADPA_PIPE_SEL_MASK (1<<30)
+#define ADPA_PIPE_SEL(pipe) ((pipe) << 30)
+#define ADPA_PIPE_SEL_SHIFT_CPT 29
+#define ADPA_PIPE_SEL_MASK_CPT (3<<29)
+#define ADPA_PIPE_SEL_CPT(pipe) ((pipe) << 29)
#define ADPA_CRT_HOTPLUG_MASK 0x03ff /* bit 25-16 */
#define ADPA_CRT_HOTPLUG_MONITOR_NONE (0<<24)
#define ADPA_CRT_HOTPLUG_MONITOR_MASK (3<<24)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index de0e22322c76..211d601cd1b1 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -63,33 +63,35 @@ static struct intel_crt *intel_attached_crt(struct
drm_connector *connector)
return intel_encoder_to_crt(intel_attached_encoder(connector));
}
+bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
+ i915_reg_t adpa_reg, enum pipe *pipe)
+{
+ u32 val;
+
+ val = I915_READ(adpa_reg);
+
+ /* asserts want to know the pipe even if the port is disabled */
+ if (HAS_PCH_CPT(dev_priv))
+ *pipe = (val & ADPA_PIPE_SEL_MASK_CPT) >>
ADPA_PIPE_SEL_SHIFT_CPT;
+ else
+ *pipe = (val & ADPA_PIPE_SEL_MASK) >> ADPA_PIPE_SEL_SHIFT;
+
+ return val & ADPA_DAC_ENABLE;
+}
+
static bool intel_crt_get_hw_state(struct intel_encoder *encoder,
enum pipe *pipe)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crt *crt = intel_encoder_to_crt(encoder);
- u32 tmp;
bool ret;
if (!intel_display_power_get_if_enabled(dev_priv,
encoder->power_domain))
return false;
- ret = false;
-
- tmp = I915_READ(crt->adpa_reg);
-
- if (!(tmp & ADPA_DAC_ENABLE))
- goto out;
+ ret = intel_crt_port_enabled(dev_priv, crt->adpa_reg, pipe);
- if (HAS_PCH_CPT(dev_priv))
- *pipe = PORT_TO_PIPE_CPT(tmp);
- else
- *pipe = PORT_TO_PIPE(tmp);
-
- ret = true;
-out:
intel_display_power_put(dev_priv, encoder->power_domain);
return ret;
@@ -168,11 +170,9 @@ static void intel_crt_set_dpms(struct intel_encoder
*encoder,
if (HAS_PCH_LPT(dev_priv))
; /* Those bits don't exist here */
else if (HAS_PCH_CPT(dev_priv))
- adpa |= PORT_TRANS_SEL_CPT(crtc->pipe);
- else if (crtc->pipe == 0)
- adpa |= ADPA_PIPE_A_SELECT;
+ adpa |= ADPA_PIPE_SEL_CPT(crtc->pipe);
else
- adpa |= ADPA_PIPE_B_SELECT;
+ adpa |= ADPA_PIPE_SEL(crtc->pipe);
if (!HAS_PCH_SPLIT(dev_priv))
I915_WRITE(BCLRPAT(crtc->pipe), 0);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad588d564198..6daa8d97a0aa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1360,21 +1360,6 @@ static bool lvds_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool adpa_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & ADPA_DAC_ENABLE) == 0)
- return false;
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
- return false;
- } else {
- if ((val & ADPA_PIPE_SELECT_MASK) != ADPA_PIPE_SELECT(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv
[Intel-gfx] [PATCH 2/5] drm/i915: Clean up LVDS pipe select bits
From: Ville Syrjälä
Clean up the LVDS pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Drop ruperfluous braces and whitesapce changes (Jani)
Combine masks in compute_is_dual_link_lvds() (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 ---
drivers/gpu/drm/i915/intel_display.c | 33 +--
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lvds.c| 52 +++-
4 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ae3c26216996..2953fc2717fc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4392,9 +4392,12 @@ enum {
*/
#define LVDS_PORT_EN (1 << 31)
/* Selects pipe B for LVDS data. Must be set on pre-965. */
-#define LVDS_PIPEB_SELECT(1 << 30)
-#define LVDS_PIPE_MASK (1 << 30)
-#define LVDS_PIPE(pipe) ((pipe) << 30)
+#define LVDS_PIPE_SEL_SHIFT 30
+#define LVDS_PIPE_SEL_MASK (1 << 30)
+#define LVDS_PIPE_SEL(pipe) ((pipe) << 30)
+#define LVDS_PIPE_SEL_SHIFT_CPT 29
+#define LVDS_PIPE_SEL_MASK_CPT (3 << 30)
+#define LVDS_PIPE_SEL_CPT(pipe) ((pipe) << 29)
/* LVDS dithering flag on 965/g4x platform */
#define LVDS_ENABLE_DITHER (1 << 25)
/* LVDS sync polarity flags. Set to invert (i.e. negative) */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6daa8d97a0aa..a1c6cc75f49c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1214,9 +1214,8 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
pp_reg = PP_CONTROL(0);
port_sel = I915_READ(PP_ON_DELAYS(0)) & PANEL_PORT_SELECT_MASK;
- if (port_sel == PANEL_PORT_SELECT_LVDS &&
- I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
+ if (port_sel == PANEL_PORT_SELECT_LVDS)
+ intel_lvds_port_enabled(dev_priv, PCH_LVDS,
&panel_pipe);
/* XXX: else fix for eDP */
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
/* presumably write lock depends on pipe, not port select */
@@ -1224,8 +1223,7 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
panel_pipe = pipe;
} else {
pp_reg = PP_CONTROL(0);
- if (I915_READ(LVDS) & LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
+ intel_lvds_port_enabled(dev_priv, LVDS, &panel_pipe);
}
val = I915_READ(pp_reg);
@@ -1344,22 +1342,6 @@ static bool hdmi_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool lvds_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & LVDS_PORT_EN) == 0)
- return false;
-
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
- return false;
- } else {
- if ((val & LVDS_PIPE_MASK) != LVDS_PIPE(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe, i915_reg_t reg,
u32 port_sel)
@@ -1391,7 +1373,6 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
enum pipe pipe)
{
enum pipe port_pipe;
- u32 val;
assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_B, TRANS_DP_PORT_SEL_B);
assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_C, TRANS_DP_PORT_SEL_C);
@@ -1402,10 +1383,10 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
"PCH VGA enabled on transcoder %c, should be
disabled\n",
pipe_name(pipe));
- val = I915_READ(PCH_LVDS);
- I915_STATE_WARN(lvds_pipe_enabled(dev_priv, pipe, val),
-"PCH LVDS enabled on transcoder %c, should be disabled\n",
-pipe_name(pipe));
+ I915_STATE_WARN(intel_lvds_port_enabled(dev_priv, PCH_LVDS, &port_pipe)
&&
+ port_pipe == pipe,
+ "PCH LVDS enabled on transcoder %c, should be
disabled\n",
+ pipe_name(pipe));
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIB);
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIC);
diff --git a/drivers/gpu/d
[Intel-gfx] [PATCH 5/5] drm/i915: Clean up DVO pipe select bits
From: Ville Syrjälä
Parametrize the DVO pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
drivers/gpu/drm/i915/intel_dvo.c | 13 -
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fd77d013c640..9b57632be7dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4357,7 +4357,9 @@ enum {
#define _DVOC 0x61160
#define DVOC _MMIO(_DVOC)
#define DVO_ENABLE (1 << 31)
-#define DVO_PIPE_B_SELECT(1 << 30)
+#define DVO_PIPE_SEL_SHIFT 30
+#define DVO_PIPE_SEL_MASK(1 << 30)
+#define DVO_PIPE_SEL(pipe) ((pipe) << 30)
#define DVO_PIPE_STALL_UNUSED(0 << 28)
#define DVO_PIPE_STALL (1 << 28)
#define DVO_PIPE_STALL_TV(2 << 28)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index eb0c559b2715..a86f0398570f 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -137,19 +137,15 @@ static bool intel_dvo_connector_get_hw_state(struct
intel_connector *connector)
static bool intel_dvo_get_hw_state(struct intel_encoder *encoder,
enum pipe *pipe)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dvo *intel_dvo = enc_to_dvo(encoder);
u32 tmp;
tmp = I915_READ(intel_dvo->dev.dvo_reg);
- if (!(tmp & DVO_ENABLE))
- return false;
-
- *pipe = PORT_TO_PIPE(tmp);
+ *pipe = (tmp & DVO_PIPE_SEL_MASK) >> DVO_PIPE_SEL_SHIFT;
- return true;
+ return tmp & DVO_ENABLE;
}
static void intel_dvo_get_config(struct intel_encoder *encoder,
@@ -276,8 +272,7 @@ static void intel_dvo_pre_enable(struct intel_encoder
*encoder,
dvo_val |= DVO_DATA_ORDER_FP | DVO_BORDER_ENABLE |
DVO_BLANK_ACTIVE_HIGH;
- if (pipe == 1)
- dvo_val |= DVO_PIPE_B_SELECT;
+ dvo_val |= DVO_PIPE_SEL(pipe);
dvo_val |= DVO_PIPE_STALL;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
dvo_val |= DVO_HSYNC_ACTIVE_HIGH;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Clean up TV pipe select bits
From: Ville Syrjälä
Parametrize the TV pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
v2: Order the defines shift,mask,value (Jani)
Clear the stale pipe select bit in load detection (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
drivers/gpu/drm/i915/intel_tv.c | 20 ++--
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 560168517918..fd77d013c640 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4696,7 +4696,9 @@ enum {
/* Enables the TV encoder */
# define TV_ENC_ENABLE (1 << 31)
/* Sources the TV encoder input from pipe B instead of A. */
-# define TV_ENC_PIPEB_SELECT (1 << 30)
+# define TV_ENC_PIPE_SEL_SHIFT 30
+# define TV_ENC_PIPE_SEL_MASK (1 << 30)
+# define TV_ENC_PIPE_SEL(pipe) ((pipe) << 30)
/* Outputs composite video (DAC A only) */
# define TV_ENC_OUTPUT_COMPOSITE (0 << 28)
/* Outputs SVideo video (DAC B/C) */
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 885fc3809f7f..99bc2368dda0 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -798,16 +798,12 @@ static struct intel_tv *intel_attached_tv(struct
drm_connector *connector)
static bool
intel_tv_get_hw_state(struct intel_encoder *encoder, enum pipe *pipe)
{
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 tmp = I915_READ(TV_CTL);
- if (!(tmp & TV_ENC_ENABLE))
- return false;
+ *pipe = (tmp & TV_ENC_PIPE_SEL_MASK) >> TV_ENC_PIPE_SEL_SHIFT;
- *pipe = PORT_TO_PIPE(tmp);
-
- return true;
+ return tmp & TV_ENC_ENABLE;
}
static void
@@ -1024,8 +1020,7 @@ static void intel_tv_pre_enable(struct intel_encoder
*encoder,
break;
}
- if (intel_crtc->pipe == 1)
- tv_ctl |= TV_ENC_PIPEB_SELECT;
+ tv_ctl |= TV_ENC_PIPE_SEL(intel_crtc->pipe);
tv_ctl |= tv_mode->oversample;
if (tv_mode->progressive)
@@ -1149,12 +1144,9 @@ intel_tv_detect_type(struct intel_tv *intel_tv,
save_tv_ctl = tv_ctl = I915_READ(TV_CTL);
/* Poll for TV detection */
- tv_ctl &= ~(TV_ENC_ENABLE | TV_TEST_MODE_MASK);
+ tv_ctl &= ~(TV_ENC_ENABLE | TV_ENC_PIPE_SEL_MASK | TV_TEST_MODE_MASK);
tv_ctl |= TV_TEST_MODE_MONITOR_DETECT;
- if (intel_crtc->pipe == 1)
- tv_ctl |= TV_ENC_PIPEB_SELECT;
- else
- tv_ctl &= ~TV_ENC_PIPEB_SELECT;
+ tv_ctl |= TV_ENC_PIPE_SEL(intel_crtc->pipe);
tv_dac &= ~(TVDAC_SENSE_MASK | DAC_A_MASK | DAC_B_MASK | DAC_C_MASK);
tv_dac |= (TVDAC_STATE_CHG_EN |
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Clean up SDVO pipe select bits
From: Ville Syrjälä
Clean up the SDVO pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 10
drivers/gpu/drm/i915/intel_display.c | 46 +---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 25
drivers/gpu/drm/i915/intel_sdvo.c| 38 ++---
5 files changed, 52 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2953fc2717fc..560168517918 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4297,9 +4297,9 @@ enum {
/* Gen 3 SDVO bits: */
#define SDVO_ENABLE (1 << 31)
-#define SDVO_PIPE_SEL(pipe) ((pipe) << 30)
+#define SDVO_PIPE_SEL_SHIFT 30
#define SDVO_PIPE_SEL_MASK (1 << 30)
-#define SDVO_PIPE_B_SELECT (1 << 30)
+#define SDVO_PIPE_SEL(pipe) ((pipe) << 30)
#define SDVO_STALL_SELECT(1 << 29)
#define SDVO_INTERRUPT_ENABLE(1 << 26)
/*
@@ -4339,12 +4339,14 @@ enum {
#define SDVOB_HOTPLUG_ENABLE (1 << 23) /* SDVO only */
/* Gen 6 (CPT) SDVO/HDMI bits: */
-#define SDVO_PIPE_SEL_CPT(pipe) ((pipe) << 29)
+#define SDVO_PIPE_SEL_SHIFT_CPT 29
#define SDVO_PIPE_SEL_MASK_CPT (3 << 29)
+#define SDVO_PIPE_SEL_CPT(pipe) ((pipe) << 29)
/* CHV SDVO/HDMI bits: */
-#define SDVO_PIPE_SEL_CHV(pipe) ((pipe) << 24)
+#define SDVO_PIPE_SEL_SHIFT_CHV 24
#define SDVO_PIPE_SEL_MASK_CHV (3 << 24)
+#define SDVO_PIPE_SEL_CHV(pipe) ((pipe) << 24)
/* DVO port control */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a1c6cc75f49c..817d5d3f65eb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1323,25 +1323,6 @@ static bool dp_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool hdmi_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & SDVO_ENABLE) == 0)
- return false;
-
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & SDVO_PIPE_SEL_MASK_CPT) != SDVO_PIPE_SEL_CPT(pipe))
- return false;
- } else if (IS_CHERRYVIEW(dev_priv)) {
- if ((val & SDVO_PIPE_SEL_MASK_CHV) != SDVO_PIPE_SEL_CHV(pipe))
- return false;
- } else {
- if ((val & SDVO_PIPE_SEL_MASK) != SDVO_PIPE_SEL(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe, i915_reg_t reg,
u32 port_sel)
@@ -1357,16 +1338,21 @@ static void assert_pch_dp_disabled(struct
drm_i915_private *dev_priv,
}
static void assert_pch_hdmi_disabled(struct drm_i915_private *dev_priv,
-enum pipe pipe, i915_reg_t reg)
+enum pipe pipe, enum port port,
+i915_reg_t hdmi_reg)
{
- u32 val = I915_READ(reg);
- I915_STATE_WARN(hdmi_pipe_enabled(dev_priv, pipe, val),
-"PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n",
-i915_mmio_reg_offset(reg), pipe_name(pipe));
+ enum pipe port_pipe;
+ bool state;
+
+ state = intel_sdvo_port_enabled(dev_priv, hdmi_reg, &port_pipe);
+
+ I915_STATE_WARN(state && port_pipe == pipe,
+ "PCH HDMI %c enabled on transcoder %c, should be
disabled\n",
+ port_name(port), pipe_name(pipe));
- I915_STATE_WARN(HAS_PCH_IBX(dev_priv) && (val & SDVO_ENABLE) == 0
-&& (val & SDVO_PIPE_B_SELECT),
-"IBX PCH hdmi port still using transcoder B\n");
+ I915_STATE_WARN(HAS_PCH_IBX(dev_priv) && !state && port_pipe == PIPE_B,
+ "IBX PCH HDMI %c still using transcoder B\n",
+ port_name(port));
}
static void assert_pch_ports_disabled(struct drm_i915_private *dev_priv,
@@ -1388,9 +1374,9 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
"PCH LVDS enabled on transcoder %c, should be
disabled\n",
pipe_name(pipe));
- assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIB);
- assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIC);
- assert_
[Intel-gfx] ✗ Fi.CI.IGT: failure for benchmarks/gem_syslatency: Pass a write hazard around
== Series Details == Series: benchmarks/gem_syslatency: Pass a write hazard around URL : https://patchwork.freedesktop.org/series/43126/ State : failure == Summary == = CI Bug Log - changes from IGT_4477_full -> IGTPW_1353_full = == Summary - FAILURE == Serious unknown changes coming with IGTPW_1353_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_1353_full, 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/43126/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in IGTPW_1353_full: === IGT changes === Possible regressions igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL +1 Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP +4 == Known issues == Here are the changes found in IGTPW_1353_full that come from known issues: === IGT changes === Issues hit igt@kms_busy@extended-modeset-hang-newfb-render-c: shard-kbl: PASS -> DMESG-FAIL (fdo#105602, fdo#103558) igt@kms_flip@2x-absolute-wf_vblank-interruptible: shard-glk: PASS -> FAIL (fdo#106087) igt@kms_flip@2x-flip-vs-wf_vblank-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +2 igt@kms_flip@modeset-vs-vblank-race: shard-kbl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +2 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt: shard-glk: PASS -> FAIL (fdo#103167, fdo#104724) igt@kms_frontbuffer_tracking@fbc-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) Possible fixes igt@kms_flip@absolute-wf_vblank-interruptible: shard-glk: FAIL (fdo#106087) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +3 igt@testdisplay: shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * IGT: IGT_4477 -> IGTPW_1353 * Linux: CI_DRM_4175 -> CI_DRM_4176 CI_DRM_4175: a57366b6029ac86436ad36bbf8b9a31549ef2905 @ git://anongit.freedesktop.org/gfx-ci/linux CI_DRM_4176: d6984daab2a47e5afeb638f31b40c36693c93d6c @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_1353: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1353/ IGT_4477: 395c23946b44b071cc376f488a3205bedb02b382 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools piglit_4477: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1353/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 drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (rev2)
== Series Details == Series: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (rev2) URL : https://patchwork.freedesktop.org/series/43024/ State : failure == Summary == Applying: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_engine_cs.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_engine_cs.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_engine_cs.c Patch failed at 0001 drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk The copy of the patch that failed is found in: .git/rebase-apply/patch 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] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Clean up ADPA pipe select bits
== Series Details == Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits URL : https://patchwork.freedesktop.org/series/43151/ State : warning == Summary == $ dim checkpatch origin/drm-tip afd2d93c4687 drm/i915: Clean up ADPA pipe select bits -:32: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #32: FILE: drivers/gpu/drm/i915/i915_reg.h:4137: +#define ADPA_PIPE_SEL_MASK (1<<30) ^ -:35: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #35: FILE: drivers/gpu/drm/i915/i915_reg.h:4140: +#define ADPA_PIPE_SEL_MASK_CPT (3<<29) ^ total: 0 errors, 0 warnings, 2 checks, 131 lines checked 17bebe27c017 drm/i915: Clean up LVDS pipe select bits be3c8193750e drm/i915: Clean up SDVO pipe select bits 0b3a16eec107 drm/i915: Clean up TV pipe select bits c634a7255d97 drm/i915: Clean up DVO pipe select bits ___ 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/5] drm/i915: Clean up ADPA pipe select bits
== Series Details == Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits URL : https://patchwork.freedesktop.org/series/43151/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4179 -> Patchwork_8996 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8996 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8996, 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/43151/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8996: === IGT changes === Possible regressions igt@core_auth@basic-auth: fi-ivb-3520m: PASS -> INCOMPLETE Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8996 that come from known issues: === IGT changes === Issues hit igt@core_auth@basic-auth: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2600:DMESG-WARN (fdo#102365) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 == Participating hosts (41 -> 37) == Additional (1): fi-byt-j1900 Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4179 -> Patchwork_8996 CI_DRM_4179: be6d36ea8d6130f54ab5ec816555f1a46bd95f7b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4479: 89ae332745e31a075747a63ac5acc5baccf75769 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8996: c634a7255d9797834b6e7db10e43ec971a9517f1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4479: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit == Linux commits == c634a7255d97 drm/i915: Clean up DVO pipe select bits 0b3a16eec107 drm/i915: Clean up TV pipe select bits be3c8193750e drm/i915: Clean up SDVO pipe select bits 17bebe27c017 drm/i915: Clean up LVDS pipe select bits afd2d93c4687 drm/i915: Clean up ADPA pipe select bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8996/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/5] drm/i915: Clean up LVDS pipe select bits
From: Ville Syrjälä
Clean up the LVDS pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Drop ruperfluous braces and whitesapce changes (Jani)
Combine masks in compute_is_dual_link_lvds() (Jani)
v3: Fix LVDS_PIPE_SEL_MASK_CPT
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 ---
drivers/gpu/drm/i915/intel_display.c | 33 +--
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lvds.c| 52 +++-
4 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ae3c26216996..753b8f110e2e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4392,9 +4392,12 @@ enum {
*/
#define LVDS_PORT_EN (1 << 31)
/* Selects pipe B for LVDS data. Must be set on pre-965. */
-#define LVDS_PIPEB_SELECT(1 << 30)
-#define LVDS_PIPE_MASK (1 << 30)
-#define LVDS_PIPE(pipe) ((pipe) << 30)
+#define LVDS_PIPE_SEL_SHIFT 30
+#define LVDS_PIPE_SEL_MASK (1 << 30)
+#define LVDS_PIPE_SEL(pipe) ((pipe) << 30)
+#define LVDS_PIPE_SEL_SHIFT_CPT 29
+#define LVDS_PIPE_SEL_MASK_CPT (3 << 29)
+#define LVDS_PIPE_SEL_CPT(pipe) ((pipe) << 29)
/* LVDS dithering flag on 965/g4x platform */
#define LVDS_ENABLE_DITHER (1 << 25)
/* LVDS sync polarity flags. Set to invert (i.e. negative) */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6daa8d97a0aa..a1c6cc75f49c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1214,9 +1214,8 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
pp_reg = PP_CONTROL(0);
port_sel = I915_READ(PP_ON_DELAYS(0)) & PANEL_PORT_SELECT_MASK;
- if (port_sel == PANEL_PORT_SELECT_LVDS &&
- I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
+ if (port_sel == PANEL_PORT_SELECT_LVDS)
+ intel_lvds_port_enabled(dev_priv, PCH_LVDS,
&panel_pipe);
/* XXX: else fix for eDP */
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
/* presumably write lock depends on pipe, not port select */
@@ -1224,8 +1223,7 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
panel_pipe = pipe;
} else {
pp_reg = PP_CONTROL(0);
- if (I915_READ(LVDS) & LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
+ intel_lvds_port_enabled(dev_priv, LVDS, &panel_pipe);
}
val = I915_READ(pp_reg);
@@ -1344,22 +1342,6 @@ static bool hdmi_pipe_enabled(struct drm_i915_private
*dev_priv,
return true;
}
-static bool lvds_pipe_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe, u32 val)
-{
- if ((val & LVDS_PORT_EN) == 0)
- return false;
-
- if (HAS_PCH_CPT(dev_priv)) {
- if ((val & PORT_TRANS_SEL_MASK) != PORT_TRANS_SEL_CPT(pipe))
- return false;
- } else {
- if ((val & LVDS_PIPE_MASK) != LVDS_PIPE(pipe))
- return false;
- }
- return true;
-}
-
static void assert_pch_dp_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe, i915_reg_t reg,
u32 port_sel)
@@ -1391,7 +1373,6 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
enum pipe pipe)
{
enum pipe port_pipe;
- u32 val;
assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_B, TRANS_DP_PORT_SEL_B);
assert_pch_dp_disabled(dev_priv, pipe, PCH_DP_C, TRANS_DP_PORT_SEL_C);
@@ -1402,10 +1383,10 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
"PCH VGA enabled on transcoder %c, should be
disabled\n",
pipe_name(pipe));
- val = I915_READ(PCH_LVDS);
- I915_STATE_WARN(lvds_pipe_enabled(dev_priv, pipe, val),
-"PCH LVDS enabled on transcoder %c, should be disabled\n",
-pipe_name(pipe));
+ I915_STATE_WARN(intel_lvds_port_enabled(dev_priv, PCH_LVDS, &port_pipe)
&&
+ port_pipe == pipe,
+ "PCH LVDS enabled on transcoder %c, should be
disabled\n",
+ pipe_name(pipe));
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMIB);
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDM
Re: [Intel-gfx] [PATCH v10 1/2] drm: content-type property for HDMI connector
On Tue, May 08, 2018 at 10:44:56AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
>
> v2:
> * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
>
> v3:
> * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
>
> v4:
> * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
>
> v5:
> * Moved patch revision's description to commit messages.
>
> v6:
> * Minor naming fix for the content type enumeration string.
>
> v7:
> * Fix parameter name for documentation and parameter alignment
>in order not to get warning. Added Content Type description to
>new HDMI connector properties section.
>
> v8:
> * Thrown away unneeded numbers from HDMI content-type property
>description. Switch to strings desription instead of plain
>definitions.
>
> v9:
> * Moved away hdmi specific content-type enum from
>drm_connector_state. Content type property should probably not
>be bound to any specific connector interface in
>drm_connector_state.
>Same probably should be done to hdmi_picture_aspect_ration enum
>which is also contained in drm_connector_state. Added special
>helper function to get derive hdmi specific relevant infoframe
>fields.
>
> v10:
> * Added usage description to HDMI properties kernel doc.
>
> Acked-by: Hans Verkuil
> Acked-by: Daniel Vetter
> Signed-off-by: Stanislav Lisovskiy
> ---
> Documentation/gpu/drm-kms.rst| 6 +++
> Documentation/gpu/kms-properties.csv | 1 +
> drivers/gpu/drm/drm_atomic.c | 4 ++
> drivers/gpu/drm/drm_connector.c | 80
> drivers/gpu/drm/drm_edid.c | 55 +++
> include/drm/drm_connector.h | 12 +
> include/drm/drm_edid.h | 6 +++
> include/drm/drm_mode_config.h| 5 ++
> include/uapi/drm/drm_mode.h | 7 +++
> 9 files changed, 176 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1dffd1ac4cd4..e233c2626bd0 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -517,6 +517,12 @@ Standard Connector Properties
> .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: standard connector properties
>
> +HDMI Specific Connector Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> + :doc: HDMI connector properties
> +
> Plane Composition Properties
>
>
> diff --git a/Documentation/gpu/kms-properties.csv
> b/Documentation/gpu/kms-properties.csv
> index 07ed22ea3bd6..bfde04eddd14 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> Values,Object attached,De
> ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property
> to suggest an X offset for a connector
> ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest
> an Y offset for a connector
> ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"",
> ""Cinema"", ""Game"" }",Connector,TBD
> i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
> set, the hardware will be programmed with the result of the multiplication of
> CTM by the limited range matrix to ensure the pixels normaly in the range
> 0..1.0 are remapped to the range 16/255..235/255."
> ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3d9ae057a6cd..6c1e1e774517 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->link_status = val;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + state->content_type = va
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Clean up ADPA pipe select bits (rev2)
== Series Details == Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits (rev2) URL : https://patchwork.freedesktop.org/series/43151/ State : warning == Summary == $ dim checkpatch origin/drm-tip eedc0c805469 drm/i915: Clean up ADPA pipe select bits -:32: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #32: FILE: drivers/gpu/drm/i915/i915_reg.h:4137: +#define ADPA_PIPE_SEL_MASK (1<<30) ^ -:35: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #35: FILE: drivers/gpu/drm/i915/i915_reg.h:4140: +#define ADPA_PIPE_SEL_MASK_CPT (3<<29) ^ total: 0 errors, 0 warnings, 2 checks, 131 lines checked 4791448a0def drm/i915: Clean up LVDS pipe select bits 2e5e4eaeb9da drm/i915: Clean up SDVO pipe select bits 077d5e8b84ad drm/i915: Clean up TV pipe select bits 004ffb58f527 drm/i915: Clean up DVO pipe select bits ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 09/14] drm/i915/gvt: Add 64K huge gtt support
On 8 May 2018 at 10:05, wrote: > From: Changbin Du > > Finally, this add the first huge gtt support for GVTg - 64K pages. Since > 64K page and 4K page cannot be mixed on the same page table, so we always > split a 64K entry into small 4K page. And when unshadow guest 64K entry, > we need ensure all the shadowed entries in shadow page table also get > cleared. > > For page table which has 64K gtt entry, only PTE#0, PTE#16, PTE#32, ... > PTE#496 are used. Unused PTEs update should be ignored. > > Signed-off-by: Changbin Du > --- > drivers/gpu/drm/i915/gvt/gtt.c | 86 > +++--- > 1 file changed, 80 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > index 30b15e4..2f13464 100644 > --- a/drivers/gpu/drm/i915/gvt/gtt.c > +++ b/drivers/gpu/drm/i915/gvt/gtt.c > @@ -978,9 +978,12 @@ static int ppgtt_invalidate_spt(struct > intel_vgpu_ppgtt_spt *spt) > ppgtt_invalidate_pte(spt, &e); > break; > case GTT_TYPE_PPGTT_PTE_64K_ENTRY: > + /* We don't setup 64K shadow entry so far. */ > + WARN(1, "suspicious 64K gtt entry\n"); > + continue; > case GTT_TYPE_PPGTT_PTE_2M_ENTRY: > case GTT_TYPE_PPGTT_PTE_1G_ENTRY: > - WARN(1, "GVT doesn't support 64K/2M/1GB page\n"); > + WARN(1, "GVT doesn't support 2M/1GB page\n"); > continue; > case GTT_TYPE_PPGTT_PML4_ENTRY: > case GTT_TYPE_PPGTT_PDP_ENTRY: > @@ -1073,9 +1076,44 @@ static inline void ppgtt_generate_shadow_entry(struct > intel_gvt_gtt_entry *se, > se->type = ge->type; > se->val64 = ge->val64; > > + /* Because we always split 64KB pages, so clear IPS in shadow PDE. */ > + if (se->type == GTT_TYPE_PPGTT_PDE_ENTRY) > + ops->clear_ips(se); IIUC we are disabling 64K entries for the spt(we clear the IPS bit), so what are we actually gaining by going through the trouble of supporting them in the guest, as opposed to just disabling them? ___ 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] igt/gem_eio: Exercise banning
On 14/05/18 08:02, Chris Wilson wrote: Quoting Antonio Argenziano (2018-05-14 15:51:04) On 12/05/18 02:03, Chris Wilson wrote: If we trigger "too many" resets, the context and even the file, will be banend and subsequent execbufs should fail with -EIO. Signed-off-by: Chris Wilson Does this replace gem_reset_stats@test_ban? gem_reset_stats was queued to be rewritten from scratch a few years ago. In short, no it doesn't replace as they are asking slightly different questions. gem_eio is asking that if banned we get EIO. I have no idea what API gem_reset_stats is supposed to be asking about, since banning is not an aspect of DRM_IOCTL_I915_GET_RESET_STATS and so should be treated very lightly to avoid over-specificity. (Banning is an internal kernel policy in the name of DoS prevention and not a rigorous defense or subject to user control.) I am not sure how much the intention of the tests are different :), but if that is the case then we need to check that other contexts are not being affected after a ban and they do not report -EIO on submission. Thanks, Antonio -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused.
intel_pipe_update_start also needs to wait for PSR to idle
out. Need some minor modifications in psr_wait_for_idle in
order to reuse it.
Cc: Chris Wilson
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_psr.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index db27f2faa1de..40aafc0f4513 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -889,11 +889,15 @@ static bool psr_wait_for_idle(struct drm_i915_private
*dev_priv)
i915_reg_t reg;
u32 mask;
int err;
+ bool wait = false;
+
+ mutex_lock(&dev_priv->psr.lock);
intel_dp = dev_priv->psr.enabled;
if (!intel_dp)
- return false;
+ goto unlock;
+ wait = true;
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_enabled) {
reg = EDP_PSR2_STATUS;
@@ -911,15 +915,18 @@ static bool psr_wait_for_idle(struct drm_i915_private
*dev_priv)
mask = VLV_EDP_PSR_IN_TRANS;
}
+unlock:
mutex_unlock(&dev_priv->psr.lock);
- err = intel_wait_for_register(dev_priv, reg, mask, 0, 50);
- if (err)
- DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n");
+ if(wait) {
+ err = intel_wait_for_register(dev_priv, reg, mask, 0, 50);
+ if (err) {
+ DRM_ERROR("Timed out waiting for PSR Idle for
re-enable\n");
+ wait = false;
+ }
+ }
- /* After the unlocked wait, verify that PSR is still wanted! */
- mutex_lock(&dev_priv->psr.lock);
- return err == 0 && dev_priv->psr.enabled;
+ return wait;
}
static void intel_psr_work(struct work_struct *work)
@@ -927,7 +934,6 @@ static void intel_psr_work(struct work_struct *work)
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work.work);
- mutex_lock(&dev_priv->psr.lock);
/*
* We have to make sure PSR is ready for re-enable
@@ -936,14 +942,15 @@ static void intel_psr_work(struct work_struct *work)
* and be ready for re-enable.
*/
if (!psr_wait_for_idle(dev_priv))
- goto unlock;
+ return;
- /*
+ /* After the unlocked wait, verify that PSR is still wanted!
* The delayed work can race with an invalidate hence we need to
* recheck. Since psr_flush first clears this and then reschedules we
* won't ever miss a flush when bailing out here.
*/
- if (dev_priv->psr.busy_frontbuffer_bits)
+ mutex_lock(&dev_priv->psr.lock);
+ if (dev_priv->psr.enabled && dev_priv->psr.busy_frontbuffer_bits)
goto unlock;
intel_psr_activate(dev_priv->psr.enabled);
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion
The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then the pipe_update_start call schedules itself out to check back later. On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but lags w.r.t core kernel code, hot plugging an external display triggers tons of "potential atomic update errors" in the dmesg, on *pipe A*. A closer analysis reveals that we try to read the scanline 3 times and eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL stuck @ 1599. This issue is not seen on upstream kernels, b/c for *some* reason we loop inside intel_pipe_update start for ~2+ msec which in this case is more than enough to exit PSR fully, hence an *unstuck* PIPEDSL counter, hence no error. On the other hand, the ChromeOS kernel spends ~1.1 msec looping inside intel_pipe_update_start and hence errors out b/c the source is still in PSR. Regardless, we should wait for PSR exit (if PSR is supported and active on the current pipe) before reading the PIPEDSL, b/c if we haven't fully exited PSR, then checking for vblank evasion isn't actually applicable. This scenario applies to a configuration with an additional pipe, as of now Signed-off-by: Tarun Vyas --- drivers/gpu/drm/i915/intel_sprite.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index ee23613f9fd4..481d310e5c3b 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -107,14 +107,17 @@ void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state) VBLANK_EVASION_TIME_US); max = vblank_start - 1; - local_irq_disable(); - if (min <= 0 || max <= 0) return; if (WARN_ON(drm_crtc_vblank_get(&crtc->base))) return; + if(new_crtc_state->has_psr && dev_priv->psr.active) + psr_wait_for_idle(dev_priv); + + local_irq_disable(); + crtc->debug.min_vbl = min; crtc->debug.max_vbl = max; trace_i915_pipe_update_start(crtc); -- 2.13.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Un-statify psr_wait_for_idle
We have new users (follow up patch). So, un-statify it
Cc: Chris Wilson
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7dbca1aabff..d8f8282f1fad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1919,6 +1919,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state);
void intel_psr_irq_control(struct drm_i915_private *dev_priv, bool debug);
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir);
+bool psr_wait_for_idle(struct drm_i915_private *dev_priv);
/* intel_runtime_pm.c */
int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 40aafc0f4513..e69859fa782f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -883,7 +883,7 @@ void intel_psr_disable(struct intel_dp *intel_dp,
cancel_delayed_work_sync(&dev_priv->psr.work);
}
-static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
+bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
{
struct intel_dp *intel_dp;
i915_reg_t reg;
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Allow i915_gem_reset_prepare_engine to recurse
We call i915_gem_reset_prepare_engine() during reset and then upon
wedging if the reset fails. Unfortunately, kthread_park and similar do
not support being called recursively and so we must count the number of
times we prepare for reset and only actually prepare on the outermost
layer. (Similarly for finish on unwinding the onion.)
[ 87.705581] WARNING: CPU: 2 PID: 1377 at kernel/kthread.c:505
kthread_park+0x55/0x60
[ 87.705583] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec
snd_hwdep snd_hda_core snd_pcm broadcom bcm_phy_lib tg3 mei_me prime_numbers
mei lpc_ich
[ 87.705618] CPU: 2 PID: 1377 Comm: gem_eio Tainted: G U
4.17.0-rc5-CI-CI_DRM_4177+ #1
[ 87.705620] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011
[ 87.705622] RIP: 0010:kthread_park+0x55/0x60
[ 87.705624] RSP: 0018:c951bac0 EFLAGS: 00010202
[ 87.705627] RAX: 0004 RBX: 88021ca13de8 RCX: 0001
[ 87.705629] RDX: 8001 RSI: 821228a9 RDI: 88020e8f0040
[ 87.705630] RBP: 880215937670 R08: bae32d65 R09:
[ 87.705632] R10: R11: R12: 8802159376b0
[ 87.705634] R13: 880215937670 R14: 88021593 R15: a01c8d60
[ 87.705636] FS: 7f0c32061980() GS:88022fa8()
knlGS:
[ 87.705637] CS: 0010 DS: ES: CR0: 80050033
[ 87.705639] CR2: 7f0c32094000 CR3: 00021a0d4004 CR4: 000606e0
[ 87.705641] Call Trace:
[ 87.705668] i915_gem_reset_prepare_engine+0x1d/0xa0 [i915]
[ 87.705694] i915_gem_set_wedged+0x7b/0x1e0 [i915]
[ 87.705699] ? __drm_printfn_info+0x20/0x20
[ 87.705722] i915_reset+0x14a/0x290 [i915]
[ 87.705743] i915_reset_device+0x1fb/0x290 [i915]
[ 87.705767] ? __intel_get_crtc_scanline+0x1c0/0x1c0 [i915]
[ 87.705772] ? work_on_cpu_safe+0x50/0x50
[ 87.705798] i915_handle_error+0x207/0x4a0 [i915]
[ 87.705810] ? __might_fault+0x39/0x90
[ 87.705835] i915_wedged_set+0x7f/0xc0 [i915]
[ 87.705841] simple_attr_write+0xb0/0xd0
[ 87.705847] full_proxy_write+0x51/0x80
[ 87.705852] __vfs_write+0x31/0x160
[ 87.705857] ? rcu_read_lock_sched_held+0x6f/0x80
[ 87.705860] ? rcu_sync_lockdep_assert+0x29/0x50
[ 87.705862] ? __sb_start_write+0x152/0x1f0
[ 87.705864] ? __sb_start_write+0x168/0x1f0
[ 87.705868] vfs_write+0xbd/0x1a0
[ 87.705872] ksys_write+0x50/0xc0
[ 87.705877] do_syscall_64+0x55/0x190
[ 87.705880] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 87.705882] RIP: 0033:0x7f0c315df281
[ 87.705884] RSP: 002b:7ffc9c990328 EFLAGS: 0246 ORIG_RAX:
0001
[ 87.705887] RAX: ffda RBX: RCX: 7f0c315df281
[ 87.705889] RDX: 0002 RSI: 55a5e23ef276 RDI: 0047
[ 87.705890] RBP: 7ffc9c990350 R08: R09: 0034
[ 87.705892] R10: R11: 0246 R12: 55a5e23ebc50
[ 87.705894] R13: 7ffc9c990dc0 R14: R15:
[ 87.705902] Code: 00 31 ed 48 39 c7 74 0e e8 79 db 00 00 48 8d 7b 18 e8 a0
05 88 00 89 e8 5b 5d c3 0f 0b bd da ff ff ff 89 e8 5b 5d c3 0f 0b eb b7 <0f> 0b
bd f0 ff ff ff eb e2 66 90 41 57 41 56 49 c7 c6 f4 ff ff
References: 85f1abe0019f ("kthread, sched/wait: Fix kthread_parkme() completion
issue")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 52 ++---
drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
3 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a2070112b66..b169b630bf78 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2997,14 +2997,11 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
return active;
}
-/*
- * Ensure irq handler finishes, and not run again.
- * Also return the active request so that we only search for it once.
- */
-struct i915_request *
-i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
+static void __i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
{
- struct i915_request *request = NULL;
+ mutex_lock(&engine->reset_lock);
+ if (engine->reset_depth++)
+ goto unlock;
/*
* During the reset sequence, we must prevent the engine from
@@ -3057,6 +3054,38 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
if (engine->i915->guc.preempt_wq)
flush_workqueue(engine->i915->guc.preempt_wq);
+unlock:
+ mutex_unlock(&engine->reset_lock);
+}
+
+static void __i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
+{
Re: [Intel-gfx] [PATCH] drm/i915: Allow i915_gem_reset_prepare_engine to recurse
Quoting Chris Wilson (2018-05-14 21:52:13) > We call i915_gem_reset_prepare_engine() during reset and then upon > wedging if the reset fails. Unfortunately, kthread_park and similar do > not support being called recursively and so we must count the number of > times we prepare for reset and only actually prepare on the outermost > layer. (Similarly for finish on unwinding the onion.) On an alternate timeline, I posted patches to remove the call to kthread_park... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Remove tasklet flush before disable
The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution after reset (after spinning a bit during reset), but before we allow it to resume we will have cleared all the pending state. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 0a2070112b66..0dc369a9ec4d 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs *engine) * calling engine->init_hw() and also writing the ELSP. * Turning off the execlists->tasklet until the reset is over * prevents the race. -* -* Note that this needs to be a single atomic operation on the -* tasklet (flush existing tasks, prevent new tasks) to prevent -* a race between reset and set-wedged. It is not, so we do the best -* we can atm and make sure we don't lock the machine up in the more -* common case of recursively being called from set-wedged from inside -* i915_reset. */ - if (!atomic_read(&engine->execlists.tasklet.count)) - tasklet_kill(&engine->execlists.tasklet); tasklet_disable(&engine->execlists.tasklet); /* -- 2.17.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/execlists: Refactor out complete_preempt_context()
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Reviewed-by: Jeff McGee #v1
---
drivers/gpu/drm/i915/intel_guc_submission.c | 26 ++---
drivers/gpu/drm/i915/intel_lrc.c| 23 ++
2 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index a7afc976c3b9..89b9863091df 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -623,6 +623,21 @@ static void wait_for_guc_preempt_report(struct
intel_engine_cs *engine)
report->report_return_status = INTEL_GUC_REPORT_STATUS_UNKNOWN;
}
+static void complete_preempt_context(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+ execlists_cancel_port_requests(execlists);
+ execlists_unwind_incomplete_requests(execlists);
+
+ wait_for_guc_preempt_report(engine);
+ intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
+
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
/**
* guc_submit() - Submit commands through GuC
* @engine: engine associated with the commands
@@ -793,15 +808,8 @@ static void guc_submission_tasklet(unsigned long data)
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
- GUC_PREEMPT_FINISHED) {
- execlists_cancel_port_requests(&engine->execlists);
- execlists_unwind_incomplete_requests(execlists);
-
- wait_for_guc_preempt_report(engine);
-
- execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
- intel_write_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX, 0);
- }
+ GUC_PREEMPT_FINISHED)
+ complete_preempt_context(engine);
if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
guc_dequeue(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0c3dad5c9709..58640f9f83c1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -552,8 +552,18 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
- execlists_clear_active(&engine->execlists, EXECLISTS_ACTIVE_HWACK);
- execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+ execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
+static void complete_preempt_context(struct intel_engine_execlists *execlists)
+{
+ GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT));
+
+ execlists_cancel_port_requests(execlists);
+ execlists_unwind_incomplete_requests(execlists);
+
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
}
static bool __execlists_dequeue(struct intel_engine_cs *engine)
@@ -1063,14 +1073,7 @@ static void execlists_submission_tasklet(unsigned long
data)
if (status & GEN8_CTX_STATUS_COMPLETE &&
buf[2*head + 1] ==
execlists->preempt_complete_status) {
GEM_TRACE("%s preempt-idle\n", engine->name);
-
- execlists_cancel_port_requests(execlists);
- execlists_unwind_incomplete_requests(execlists);
-
- GEM_BUG_ON(!execlists_is_active(execlists,
-
EXECLISTS_ACTIVE_PREEMPT));
- execlists_clear_active(execlists,
-
EXECLISTS_ACTIVE_PREEMPT);
+ complete_preempt_context(execlists);
continue;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: Wrap tasklet_struct for abuse
In the next few patches, we want to abuse tasklet to avoid ksoftirqd
latency along critical paths. To make that abuse easily to swallow,
first coat the tasklet in a little syntactic sugar.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_tasklet.h | 78 +
drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
drivers/gpu/drm/i915/intel_lrc.c| 18 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
7 files changed, 102 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0dc369a9ec4d..75668b50c81e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
* Turning off the execlists->tasklet until the reset is over
* prevents the race.
*/
- tasklet_disable(&engine->execlists.tasklet);
+ i915_tasklet_disable(&engine->execlists.tasklet);
/*
* We're using worker to queue preemption requests from the tasklet in
@@ -3256,7 +3256,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
{
- tasklet_enable(&engine->execlists.tasklet);
+ i915_tasklet_enable(&engine->execlists.tasklet);
kthread_unpark(engine->breadcrumbs.signaler);
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f9bc3aaa90d0..f8aff5a5aa83 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1477,7 +1477,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ i915_tasklet_schedule(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
new file mode 100644
index ..e24e4f77fe8e
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -0,0 +1,78 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _I915_TASKLET_H_
+#define _I915_TASKLET_H_
+
+#include
+#include
+
+/**
+ * struct i915_tasklet - wrapper around tasklet_struct
+ *
+ * We want to abuse tasklets slightly, such as calling them directly. In some
+ * cases, this requires some auxiliary tracking so subclass the tasklet_struct
+ * so that we have a central place and helpers.
+ */
+struct i915_tasklet {
+ struct tasklet_struct base;
+};
+
+static inline void i915_tasklet_init(struct i915_tasklet *t,
+void (*func)(unsigned long),
+unsigned long data)
+{
+ tasklet_init(&t->base, func, data);
+}
+
+static inline bool i915_tasklet_is_scheduled(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_SCHED, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_running(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_RUN, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_enabled(const struct i915_tasklet *t)
+{
+ return likely(!atomic_read(&t->base.count));
+}
+
+static inline void i915_tasklet_schedule(struct i915_tasklet *t)
+{
+ tasklet_hi_schedule(&t->base);
+}
+
+static inline void i915_tasklet_flush(struct i915_tasklet *t)
+{
+ tasklet_kill(&t->base);
+}
+
+static inline void i915_tasklet_disable(struct i915_tasklet *t)
+{
+ tasklet_disable(&t->base);
+}
+
+static inline void i915_tasklet_enable(struct i915_tasklet *t)
+{
+ tasklet_enable(&t->base);
+}
+
+static inline void i915_tasklet_set_func(struct i915_tasklet *t,
+void (*func)(unsigned long data),
+unsigned long data)
+{
+ i915_tasklet_disable(t);
+
+ t->base.func = func;
+ t->base.data = data;
+
+ i915_tasklet_enable(t);
+}
+
+#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 6bfd7e3ed152..70595e995c45 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1021,7 +1021,7 @@ void intel_engines_park(struct drm_i915_private *i915)
for_each_engine(engine, i915, id) {
/* Flush the residual irq tasklets first. */
intel_engine_disarm_breadcrumbs(engine);
- tasklet_kill(&engine->execlists.tasklet);
+ i915_tasklet_flush(&engine->execlists.tasklet);
