[Intel-gfx] [PATCH v5] drm/i915/guc: Preemption! With GuC
Pretty similar to what we have on execlists.
We're reusing most of the GEM code, however, due to GuC quirks we need a
couple of extra bits.
Preemption is implemented as GuC action, and actions can be pretty slow.
Because of that, we're using a mutex to serialize them. Since we're
requesting preemption from the tasklet, the task of creating a workitem
and wrapping it in GuC action is delegated to a worker.
To distinguish that preemption has finished, we're using additional
piece of HWSP, and since we're not getting context switch interrupts,
we're also adding a user interrupt.
The fact that our special preempt context has completed unfortunately
doesn't mean that we're ready to submit new work. We also need to wait
for GuC to finish its own processing.
v2: Don't compile out the wait for GuC, handle workqueue flush on reset,
no need for ordered workqueue, put on a reviewer hat when looking at my own
patches (Chris)
Move struct work around in intel_guc, move user interruput outside of
conditional (Michał)
Keep ring around rather than chase though intel_context
v3: Extract WA for flushing ggtt writes to a helper (Chris)
Keep work_struct in intel_guc rather than engine (Michał)
Use ordered workqueue for inject_preempt worker to avoid GuC quirks.
v4: Drop now unused INTEL_GUC_PREEMPT_OPTION_IMMEDIATE (Daniele)
Drop stray newlines, use container_of for intel_guc in worker,
check for presence of workqueue when flushing it, rather than
enable_guc_submission modparam, reorder preempt postprocessing (Chris)
v5: Make wq NULL after destroying it
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jeff McGee
Cc: Joonas Lahtinen
Cc: Oscar Mateo
Cc: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c| 3 +-
drivers/gpu/drm/i915/i915_gem.c| 10 ++
drivers/gpu/drm/i915/i915_guc_submission.c | 208 +++--
drivers/gpu/drm/i915/intel_guc.h | 8 ++
drivers/gpu/drm/i915/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.h | 1 -
drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +
7 files changed, 222 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7b871802ae36..af745749509c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -373,8 +373,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value |= I915_SCHEDULER_CAP_PRIORITY;
if (HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
- i915_modparams.enable_execlists &&
- !i915_modparams.enable_guc_submission)
+ i915_modparams.enable_execlists)
value |= I915_SCHEDULER_CAP_PREEMPTION;
}
break;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d803ef5f4a7f..c2506fb3a483 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2921,6 +2921,16 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
tasklet_kill(&engine->execlists.irq_tasklet);
tasklet_disable(&engine->execlists.irq_tasklet);
+ /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+ if (engine->i915->guc.preempt_wq)
+ flush_workqueue(engine->i915->guc.preempt_wq);
+
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 600ef9d33773..c3eaeb4485e1 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -561,6 +561,108 @@ static void guc_add_request(struct intel_guc *guc,
spin_unlock(&client->wq_lock);
}
+/*
+ * When we're doing submissions using regular execlists backend, writing to
+ * ELSP from CPU side is enough to make sure that writes to ringbuffer pages
+ * pinned in mappable aperture portion of GGTT are visible to command streamer.
+ * Writes done by GuC on our behalf are not guaranteeing such ordering,
+ * therefore, to ensure the flush, we're issuing a POSTING READ.
+ */
+static void flush_ggtt_writes(struct i915_vma *vma)
+{
+ struct drm_i915_private *dev_priv = to_i915(vma->obj->base.dev);
+
+ if (i915_vma_is_map_and_fenceable(vma))
+ POSTING_READ_FW(GUC_STATUS);
+}
+
+#define GUC_PREEMPT_FINISHED 0x1
+#define GUC_PREEMPT_BREADCRUMB_DWORDS 0x8
+static void inject_preempt_context(struct work_struct *work)
+{
+ struct guc_preempt_work *preempt_work =
+
[Intel-gfx] [PATCH] MAINTAINERS: Update gvt-linux.git new repo place
gvt-linux.git repo is moved for its new place under https://github.com/intel/gvt-linux.git Old https://github.com/01org/gvt-linux.git is set only for redirect now. Signed-off-by: Zhenyu Wang --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3f1f24c86fd2..f6fde90fb725 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6930,7 +6930,7 @@ M:Zhi Wang L: intel-gvt-...@lists.freedesktop.org L: intel-gfx@lists.freedesktop.org W: https://01.org/igvt-g -T: git https://github.com/01org/gvt-linux.git +T: git https://github.com/intel/gvt-linux.git S: Supported F: drivers/gpu/drm/i915/gvt/ -- 2.15.0.rc1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel the modeset retry work during modeset cleanup
Op 26-10-17 om 03:20 schreef Manasi Navare: > During modeset cleanup on driver unload we may have a pending > hotplug work. This needs to be cancel early during the teardown > so that it does not fire after we have freed the connector. > We do this after drm_kms_helper_poll_fini(dev) since this might > cause link retrain and before intel_fbdev_fini() since this tries to > free the connector. > > If this is not done we may see something like: > DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) > [ cut here ] > WARNING: CPU: 4 PID: 5010 at kernel/locking/mutex-debug.c:103 > mutex_destroy+0x4e/0x60 > Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem > ax88179_178 > +a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul > crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid > +[last unloaded: snd_hda_intel] > CPU: 4 PID: 5010 Comm: drv_module_relo Tainted: G U > 4.14.0-rc3-CI-CI_DRM_3186+ #1 > Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S > UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017 > task: 8803c827aa40 task.stack: c952 > RIP: 0010:mutex_destroy+0x4e/0x60 > RSP: 0018:c9523d58 EFLAGS: 00010292 > RAX: 002a RBX: 88044fbef648 RCX: > RDX: 8001 RSI: 0001 RDI: 810f0cf0 > RBP: c9523d60 R08: 0001 R09: 0001 > R10: 0f21cb81 R11: R12: 88044f71efc8 > R13: a02b3d20 R14: a02b3d90 R15: 880459b29308 > FS: 7f5df4d6e8c0() GS:88045d30() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 55ec51f00a18 CR3: 000451782006 CR4: 003606e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > drm_fb_helper_fini+0xd9/0x130 > intel_fbdev_destroy+0x12/0x60 [i915] > intel_fbdev_fini+0x28/0x30 [i915] > intel_modeset_cleanup+0x45/0xa0 [i915] > i915_driver_unload+0x92/0x180 [i915] > i915_pci_remove+0x19/0x30 [i915] > i915_driver_unload+0x92/0x180 [i915] > i915_pci_remove+0x19/0x30 [i915] > pci_device_remove+0x39/0xb0 > device_release_driver_internal+0x15d/0x220 > driver_detach+0x40/0x80 > bus_remove_driver+0x58/0xd0 > driver_unregister+0x2c/0x40 > pci_unregister_driver+0x36/0xb0 > i915_exit+0x1a/0x8b [i915] > SyS_delete_module+0x18c/0x1e0 > entry_SYSCALL_64_fastpath+0x1c/0xb1 > RIP: 0033:0x7f5df3286287 > RSP: 002b:7fff8e107cc8 EFLAGS: 0246 ORIG_RAX: 00b0 > RAX: ffda RBX: 81493a03 RCX: 7f5df3286287 > RDX: 0001 RSI: 0800 RDI: 564c7be02e48 > RBP: c9523f88 R08: R09: 0080 > R10: 7f5df4d6e8c0 R11: 0246 R12: > R13: 7fff8e107eb0 R14: R15: Or a GPF like: general protection fault: [#1] PREEMPT SMP Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid [last unloaded: snd_hda_intel] CPU: 0 PID: 82 Comm: kworker/0:1 Tainted: G U W 4.14.0-rc3-CI-CI_DRM_3186+ #1 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017 Workqueue: events intel_dp_modeset_retry_work_fn [i915] task: 88045a5caa40 task.stack: c9378000 RIP: 0010:drm_setup_crtcs+0x143/0xbf0 RSP: 0018:c937bd20 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b6b RBX: 0002 RCX: 0001 RDX: 0001 RSI: 0780 RDI: RBP: c937bdb8 R08: 0001 R09: 0001 R10: 0780 R11: R12: 0002 R13: 88044fbef4e8 R14: 0780 R15: 0438 FS: () GS:88045d20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55ec51ee5168 CR3: 00044c89d003 CR4: 003606f0 Call Trace: drm_fb_helper_hotplug_event.part.18+0x7e/0xc0 drm_fb_helper_hotplug_event+0x1a/0x20 intel_fbdev_output_poll_changed+0x1a/0x20 [i915] drm_kms_helper_hotplug_event+0x27/0x30 intel_dp_modeset_retry_work_fn+0x77/0x80 [i915] process_one_work+0x233/0x660 worker_thread+0x206/0x3b0 kthread+0x152/0x190 ? process_one_work+0x660/0x660 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x27/0x40 Code: 06 00 00 45 8b 45 20 31 db 45 31 e4 45 85 c0 0f 8e 91 06 00 00 44 8b 75 94 44 8b 7d 90 49
[Intel-gfx] [PATCH igt] igt/gem_exec_latency: Wire up an interloper for preemption
For measuring the cost of preemption, inject a low priority spinner
between the two measurements; the difference between the preemption and
the normal dispatch includes both the cost of the spinner dispatch and
of preempting it. Close enough for us to estimate the cost of
preemption, though we don't measure the cost of preemption on the local
ring!
Signed-off-by: Chris Wilson
CC: Michał Winiarski
---
tests/gem_exec_latency.c | 88
1 file changed, 59 insertions(+), 29 deletions(-)
diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index e9d93440..850404b9 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -50,7 +50,8 @@
#define ENGINE_FLAGS (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
-#define CORK 1
+#define CORK 0x1
+#define PREEMPT 0x2
static unsigned int ring_size;
@@ -284,13 +285,23 @@ static void latency_from_ring(int fd,
struct drm_i915_gem_execbuffer2 execbuf;
const unsigned int repeats = ring_size / 2;
uint32_t *map, *results;
+ uint32_t ctx[2] = {};
int i, j;
+ if (flags & PREEMPT) {
+ ctx[0] = gem_context_create(fd);
+ gem_context_set_priority(fd, ctx[0], -1023);
+
+ ctx[1] = gem_context_create(fd);
+ gem_context_set_priority(fd, ctx[1], 1023);
+ }
+
memset(&execbuf, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer(&obj[1]);
execbuf.buffer_count = 2;
execbuf.flags = ring;
execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC | LOCAL_I915_EXEC_HANDLE_LUT;
+ execbuf.rsvd1 = ctx[1];
memset(obj, 0, sizeof(obj));
obj[1].handle = gem_create(fd, 4096);
@@ -319,6 +330,7 @@ static void latency_from_ring(int fd,
reloc.target_handle = flags & CORK ? 1 : 0;
for (e = intel_execution_engines; e->name; e++) {
+ igt_spin_t *spin = NULL;
struct cork c;
if (e->exec_id == 0)
@@ -331,6 +343,9 @@ static void latency_from_ring(int fd,
I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
+ if (flags & PREEMPT)
+ spin = igt_spin_batch_new(fd, ctx[0], ring, 0);
+
if (flags & CORK) {
plug(fd, &c);
obj[0].handle = c.handle;
@@ -349,6 +364,7 @@ static void latency_from_ring(int fd,
execbuf.batch_start_offset + sizeof(uint32_t);
reloc.delta = sizeof(uint32_t) * j;
+ reloc.presumed_offset = obj[1].offset;
offset = reloc.presumed_offset;
offset += reloc.delta;
@@ -373,6 +389,7 @@ static void latency_from_ring(int fd,
execbuf.batch_start_offset + sizeof(uint32_t);
reloc.delta = sizeof(uint32_t) * (j + repeats);
+ reloc.presumed_offset = obj[1].offset;
offset = reloc.presumed_offset;
offset += reloc.delta;
@@ -392,10 +409,10 @@ static void latency_from_ring(int fd,
if (flags & CORK)
unplug(&c);
-
gem_set_domain(fd, obj[1].handle,
I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
+ igt_spin_batch_free(fd, spin);
igt_info("%s-%s delay: %.2f\n",
name, e->name, (results[2*repeats-1] - results[0]) /
(double)repeats);
@@ -405,6 +422,11 @@ static void latency_from_ring(int fd,
munmap(results, 4096);
gem_close(fd, obj[1].handle);
gem_close(fd, obj[2].handle);
+
+ if (flags & PREEMPT) {
+ gem_context_destroy(fd, ctx[1]);
+ gem_context_destroy(fd, ctx[0]);
+ }
}
igt_main
@@ -437,37 +459,45 @@ igt_main
if (e->exec_id == 0)
continue;
- igt_subtest_f("%s-dispatch", e->name) {
- gem_require_ring(device, e->exec_id | e->flags);
- latency_on_ring(device,
- e->exec_id | e->flags,
- e->name, 0);
- }
-
- igt_subtest_f("%s-dispatch-queued", e->name) {
- gem_require_ring(device, e->exec_id | e->flags);
- latency_on_ring(device,
- e->exec_id | e->flags,
- e->name, CORK);
- }
-
- igt_subtest_f("%s-synchronisation", e->name) {
- gem_require_ring(device, e->exec_id | e->flags);
-
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
On 25/10/2017 18:38, Chris Wilson wrote: > Quoting Chris Wilson (2017-10-25 16:47:13) >> Quoting Tvrtko Ursulin (2017-10-25 16:36:15) >>> From: Tvrtko Ursulin >> I've prototyped a quick demo of intel-client-top which produces output like: >> >> neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% vecs0: >> 0.00% >> Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% vecs0: >> 0.00% >> xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% vecs0: >> 0.00% > > +1 > +2 for a graph ;) Where are those placement students when you need them! :) >>> Another potential use for the per-client infrastructure is tieing it up with >>> perf PMU. At the moment our perf PMU are global counters only. With the per- >>> client infrastructure it should be possible to make it work in the task >>> mode as >>> well and so enable GPU busyness profiling of single tasks. >> >> ctx->pid can be misleading, as it set on creation, but the context can >> be transferred over fd to the real client. (Typically that applies to >> the default context, 0.) > > Ok, I see that you update the pid when a new context is created. Still > have the likes of libva that may use DRI3 without creating a context > itself. Hm, how rude of the protocol to provide this anonymization service! I guess I could update on submission as well and then there is no escape. > Back to the general niggle; I really would like to avoid adding custom > i915 interfaces for this, that should be a last resort if we can find no > way through e.g. perf. I certainly plan to investigate adding pid filtering to the PMU. It is supposed to be possible but I haven't tried it yet. Also not sure if it will be exactly suitable for a top like tool. Will see if I manage to have it working. But what do you say about the simple per-context API (patch 13)? Do you find using ctx get param for this acceptable or you can think of a different way? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Preemption with GuC, fourth try (rev2)
== Series Details == Series: Preemption with GuC, fourth try (rev2) URL : https://patchwork.freedesktop.org/series/32654/ State : warning == Summary == Series 32654v2 Preemption with GuC, fourth try https://patchwork.freedesktop.org/api/1.0/series/32654/revisions/2/mbox/ Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-cnl-y) Subgroup basic-no-display: pass -> DMESG-WARN (fi-cnl-y) Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-cnl-y) fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:370s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:527s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:264s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:503s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:503s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:492s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:470s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:551s fi-cnl-y total:289 pass:259 dwarn:3 dfail:0 fail:0 skip:27 time:620s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:246s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:576s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:482s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:431s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:431s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:442s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:461s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:492s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:574s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:479s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:584s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:449s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:590s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:648s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:519s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:454s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:555s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:415s 2ea0b3d47030274c97624258e09fc7d1ffd0e0f2 drm-tip: 2017y-10m-25d-18h-42m-20s UTC integration manifest d8525b3f8fda HAX Enable GuC Submission for CI ca766427cf88 drm/i915/guc: Preemption! With GuC 5c250d581667 drm/i915: Rename helpers used for unwinding, use macro for can_preempt dee14752e8a2 drm/i915/guc: Keep request->priority for its lifetime 8be229d8c330 drm/i915: Add information needed to track engine preempt state ebe667124190 drm/i915: Extract "emit write" part of emit breadcrumb functions e03bf3d7119c drm/i915/guc: Split guc_wq_item_append f4bdf01a19d4 drm/i915/guc: Add a second client, to be used for preemption 55ce81eb7f4b drm/i915/guc: Add preemption action to GuC firmware interface 47cc469a334c drm/i915/guc: Allocate separate shared data object for GuC communication ced55050645b drm/i915/guc: Extract GuC stage desc pool creation into a helper 814910338e4f drm/i915/guc: Do not use 0 for GuC doorbell cookie == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6198/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
Quoting Tvrtko Ursulin (2017-10-26 08:34:24) > > On 25/10/2017 18:38, Chris Wilson wrote: > > Quoting Chris Wilson (2017-10-25 16:47:13) > >> Quoting Tvrtko Ursulin (2017-10-25 16:36:15) > >>> From: Tvrtko Ursulin > > >> I've prototyped a quick demo of intel-client-top which produces output > >> like: > >> > >> neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% > >> vecs0: 0.00% > >> Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% > >> vecs0: 0.00% > >> xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% > >> vecs0: 0.00% > > > > +1 > > +2 for a graph ;) > > Where are those placement students when you need them! :) > > >>> Another potential use for the per-client infrastructure is tieing it up > >>> with > >>> perf PMU. At the moment our perf PMU are global counters only. With the > >>> per- > >>> client infrastructure it should be possible to make it work in the task > >>> mode as > >>> well and so enable GPU busyness profiling of single tasks. > >> > >> ctx->pid can be misleading, as it set on creation, but the context can > >> be transferred over fd to the real client. (Typically that applies to > >> the default context, 0.) > > > Ok, I see that you update the pid when a new context is created. Still > > have the likes of libva that may use DRI3 without creating a context > > itself. > > Hm, how rude of the protocol to provide this anonymization service! > > I guess I could update on submission as well and then there is no escape. (Just make it conditional; a pid per request was one of the low hanging expenses. In general, I'd rather not use pid here as ctx is our encapsulation, but meh, it's a tid vs pid debate. Answer is usually both and which to use depends on circumstance.) > > Back to the general niggle; I really would like to avoid adding custom > > i915 interfaces for this, that should be a last resort if we can find no > > way through e.g. perf. > > I certainly plan to investigate adding pid filtering to the PMU. It is > supposed to be possible but I haven't tried it yet. Also not sure if it > will be exactly suitable for a top like tool. Will see if I manage to have > it working. > > But what do you say about the simple per-context API (patch 13)? Do you > find using ctx get param for this acceptable or you can think of a different > way? Certainly not with a struct_mutex! ;) I can see a parallel to sysinfo for GETPARAM and getrusage for context. We probably want to plan for more than just accumulated gputime though. (An extensible struct?) So yes, if you have something that wants to monitor themselves, we will just have to bite the bullet. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Bit definition for D3 power state that keeps AUX fully powered
On Thu, 10 Aug 2017, Dhinakaran Pandiyan wrote: > DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state > > 101 = Set Main-Link for local Sink device and all downstream Sink > devices to D3 (power-down mode), keep AUX block fully powered, ready to > reply within a Response Timeout period of 300us. > > This state is useful in a MST dock + MST monitor configuration that > doesn't wake up from D3 state. Dhinakaran, these two seem to have fallen through the cracks, please resend. Sorry & thanks, Jani. > > Signed-off-by: Dhinakaran Pandiyan > --- > include/drm/drm_dp_helper.h | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index b17476a..d77e0f5 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -614,10 +614,11 @@ > #define DP_BRANCH_HW_REV0x509 > #define DP_BRANCH_SW_REV0x50A > > -#define DP_SET_POWER0x600 > -# define DP_SET_POWER_D00x1 > -# define DP_SET_POWER_D30x2 > -# define DP_SET_POWER_MASK 0x3 > +#define DP_SET_POWER 0x600 > +# define DP_SET_POWER_D0 0x1 > +# define DP_SET_POWER_D3 0x2 > +# define DP_SET_POWER_MASK 0x3 > +# define DP_SET_POWER_D3_AUX_ON 0x5 > > #define DP_EDP_DPCD_REV 0x700/* eDP 1.2 */ > # define DP_EDP_11 0x00 -- 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] drm/i915/selftests: Hide dangerous tests
On Wed, 25 Oct 2017, Chris Wilson wrote: > Some tests are designed to exercise the limits of the HW and may trigger > unintended side-effects making the machine unusable. This should not be > executed by default, but are still useful for early platform validation. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103453 Bugzilla: is the preferred tag to reference bugs that the patch fixes. Reference: is more like, "see also". You can use it to reference bugs too, but it generally doesn't imply that the bug gets fixed by the patch. At least that's what I've gone by for a very long time now. BR, Jani. > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > --- > drivers/gpu/drm/i915/Kconfig.debug| 14 ++ > drivers/gpu/drm/i915/selftests/intel_uncore.c | 8 > 2 files changed, 18 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index aed7d207ea84..19c77c6feb24 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -90,6 +90,20 @@ config DRM_I915_SELFTEST > > If in doubt, say "N". > > +config DRM_I915_SELFTEST_BROKEN > + bool "Enable broken and dangerous selftests" > + depends on DRM_I915_SELFTEST > + depends on BROKEN > + default n > + help > + This option enables the execution of selftests that are "dangerous" > + and may trigger unintended HW side-effects as they break strict > + rules given in the HW specification. For science. > + > + Recommended for masochistic driver developers only. > + > + If in doubt, say "N". > + > config DRM_I915_LOW_LEVEL_TRACEPOINTS > bool "Enable low level request tracing events" > depends on DRM_I915 > diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c > b/drivers/gpu/drm/i915/selftests/intel_uncore.c > index 3cac22eb47ce..f52a4ab9aa98 100644 > --- a/drivers/gpu/drm/i915/selftests/intel_uncore.c > +++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c > @@ -120,10 +120,10 @@ static int intel_uncore_check_forcewake_domains(struct > drm_i915_private *dev_pri > !IS_CHERRYVIEW(dev_priv)) > return 0; > > - if (IS_VALLEYVIEW(dev_priv)) /* XXX system lockup! */ > - return 0; > - > - if (IS_BROADWELL(dev_priv)) /* XXX random GPU hang afterwards! */ > + /* > + * This test may lockup the machine or cause GPU hangs afterwards. > + */ > + if (!IS_ENABLED(CONFIG_DRM_I915_SELFTEST_BROKEN)) > return 0; > > valid = kzalloc(BITS_TO_LONGS(FW_RANGE) * sizeof(*valid), -- 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: warning for MAINTAINERS: Update gvt-linux.git new repo place
== Series Details == Series: MAINTAINERS: Update gvt-linux.git new repo place URL : https://patchwork.freedesktop.org/series/32678/ State : warning == Summary == Series 32678v1 MAINTAINERS: Update gvt-linux.git new repo place https://patchwork.freedesktop.org/api/1.0/series/32678/revisions/1/mbox/ Test drv_getparams_basic: Subgroup basic-eu-total: pass -> DMESG-WARN (fi-bsw-n3050) Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> INCOMPLETE (fi-cnl-y) fdo#102035 fdo#102035 https://bugs.freedesktop.org/show_bug.cgi?id=102035 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:457s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:368s fi-bsw-n3050 total:289 pass:242 dwarn:1 dfail:0 fail:0 skip:46 time:522s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:493s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:491s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:483s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:556s fi-cnl-y total:61 pass:44 dwarn:0 dfail:0 fail:0 skip:16 fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:415s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:248s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:581s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:486s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:429s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:429s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:432s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:491s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:458s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:496s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:576s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:584s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:554s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:596s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:647s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:525s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:499s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:454s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:568s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:419s 2ea0b3d47030274c97624258e09fc7d1ffd0e0f2 drm-tip: 2017y-10m-25d-18h-42m-20s UTC integration manifest 71cb1c122589 MAINTAINERS: Update gvt-linux.git new repo place == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6199/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for igt/gem_exec_latency: Wire up an interloper for preemption
== Series Details == Series: igt/gem_exec_latency: Wire up an interloper for preemption URL : https://patchwork.freedesktop.org/series/32679/ State : warning == Summary == IGT patchset tested on top of latest successful build 12ee485a1e23bd49b754751fa82859012f751a1a igt/drv_hangman: Skip aliased I915_EXEC_BSD with latest DRM-Tip kernel build CI_DRM_3285 2ea0b3d47030 drm-tip: 2017y-10m-25d-18h-42m-20s UTC integration manifest Testlist changes: +igt@gem_exec_latency@blt-preemption +igt@gem_exec_latency@bsd1-preemption +igt@gem_exec_latency@bsd2-preemption +igt@gem_exec_latency@bsd-preemption +igt@gem_exec_latency@render-preemption +igt@gem_exec_latency@vebox-preemption Test kms_busy: Subgroup basic-flip-a: pass -> DMESG-WARN (fi-ilk-650) Test kms_frontbuffer_tracking: Subgroup basic: fail -> PASS (fi-glk-dsi) fdo#103167 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:450s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:450s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:376s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:525s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:506s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:497s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:495s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:481s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:553s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:600s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:252s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:584s fi-glk-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:492s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:432s fi-ilk-650 total:289 pass:227 dwarn:1 dfail:0 fail:0 skip:61 time:435s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:463s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:492s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:583s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:552s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:593s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:646s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:520s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:502s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:461s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:575s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:425s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_425/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: set minimum CD clock to twice the BCLK.
On Wed, 25 Oct 2017, Dhinakaran Pandiyan wrote:
> On Wednesday, October 25, 2017 3:02:12 PM PDT abhay.ku...@intel.com wrote:
>> From: Abhay Kumar
>>
>> In glk when device boots with only 1366x768 panel, HDA codec doesn't comeup.
>> This result in no audio forever as cdclk is < 96Mhz.
Forever... or until next modeset with audio enabled?
>> This chagne will ensure CD clock to be twice of BCLK.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
>> Signed-off-by: Abhay Kumar
>> ---
>> drivers/gpu/drm/i915/intel_cdclk.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
>> b/drivers/gpu/drm/i915/intel_cdclk.c index e8884c2ade98..185a70f0921c
>> 100644
>> --- a/drivers/gpu/drm/i915/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
>> @@ -1920,7 +1920,7 @@ int intel_crtc_compute_min_cdclk(const struct
>> intel_crtc_state *crtc_state) /* According to BSpec, "The CD clock
>> frequency must be at least twice * the frequency of the Azalia BCLK." and
>> BCLK is 96 MHz by default. */
>> -if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
>> +if (INTEL_GEN(dev_priv) >= 9)
>
> Why should cdclk be increased when audio is not being enabled?
Indeed. I can easily imagine a counter-bug reporting excessive cdclk
when audio is not enabled.
BR,
Jani.
>
>> min_cdclk = max(2 * 96000, min_cdclk);
>>
>> if (min_cdclk > dev_priv->max_cdclk_freq) {
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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.IGT: success for igt/gem_exec_latency: Wire up an interloper for preemption
== Series Details == Series: igt/gem_exec_latency: Wire up an interloper for preemption URL : https://patchwork.freedesktop.org/series/32679/ State : success == Summary == Test drv_suspend: Subgroup fence-restore-untiled-hibernate: dmesg-fail -> FAIL (shard-hsw) k.org#196691 Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-B: dmesg-warn -> PASS (shard-hsw) fdo#102249 Test kms_flip: Subgroup plain-flip-ts-check: pass -> FAIL (shard-hsw) fdo#100368 Test kms_cursor_legacy: Subgroup flip-vs-cursor-legacy: fail -> PASS (shard-hsw) fdo#102670 Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (shard-hsw) fdo#102707 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691 fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2539 pass:1430 dwarn:2 dfail:0 fail:10 skip:1097 time:9223s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_425/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
On 26/10/17 08:34, Tvrtko Ursulin wrote: On 25/10/2017 18:38, Chris Wilson wrote: Quoting Chris Wilson (2017-10-25 16:47:13) Quoting Tvrtko Ursulin (2017-10-25 16:36:15) From: Tvrtko Ursulin I've prototyped a quick demo of intel-client-top which produces output like: neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% +1 +2 for a graph ;) Where are those placement students when you need them! :) I won't be your student, but I could like to wire this into gputop. Another potential use for the per-client infrastructure is tieing it up with perf PMU. At the moment our perf PMU are global counters only. With the per- client infrastructure it should be possible to make it work in the task mode as well and so enable GPU busyness profiling of single tasks. ctx->pid can be misleading, as it set on creation, but the context can be transferred over fd to the real client. (Typically that applies to the default context, 0.) Ok, I see that you update the pid when a new context is created. Still have the likes of libva that may use DRI3 without creating a context itself. Hm, how rude of the protocol to provide this anonymization service! I guess I could update on submission as well and then there is no escape. Back to the general niggle; I really would like to avoid adding custom i915 interfaces for this, that should be a last resort if we can find no way through e.g. perf. I certainly plan to investigate adding pid filtering to the PMU. It is supposed to be possible but I haven't tried it yet. Also not sure if it will be exactly suitable for a top like tool. Will see if I manage to have it working. But what do you say about the simple per-context API (patch 13)? Do you find using ctx get param for this acceptable or you can think of a different way? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3] lib: Move __gem_context_create to common ioctl wrapper library.
On Wed, Oct 25, 2017 at 05:28:39PM -0700, Antonio Argenziano wrote:
> This patch adds a context creation ioctl wrapper that returns the error
> for the caller to consume. Multiple tests that implemented this already,
> have been changed to use the new library function.
>
> v2:
> - Add gem_require_contexts() to check for contexts support (Chris)
>
> v3:
> - Add gem_has_contexts to check for contexts support and change
> gem_require_contexts to skip if contests support is not available.
> (Chris)
>
> Signed-off-by: Antonio Argenziano
>
> Cc: Chris Wilson
> Cc: Michał Winiarski
> ---
> benchmarks/gem_exec_ctx.c | 6 ++---
> benchmarks/gem_exec_trace.c | 4 +--
> lib/i915/gem_context.c | 62
> +
> lib/i915/gem_context.h | 3 +++
> tests/gem_ctx_create.c | 10
> tests/gem_ctx_switch.c | 13 --
> tests/gem_eio.c | 13 +-
> tests/gem_exec_await.c | 14 ++
> tests/gem_exec_nop.c| 13 --
> tests/gem_exec_parallel.c | 15 +++
> tests/gem_exec_reuse.c | 13 --
> tests/gem_exec_whisper.c| 13 --
> 12 files changed, 71 insertions(+), 108 deletions(-)
>
> diff --git a/benchmarks/gem_exec_ctx.c b/benchmarks/gem_exec_ctx.c
> index 0eac04b0..a1c6e5d7 100644
> --- a/benchmarks/gem_exec_ctx.c
> +++ b/benchmarks/gem_exec_ctx.c
> @@ -64,7 +64,7 @@ static uint32_t batch(int fd)
> return handle;
> }
>
> -static uint32_t __gem_context_create(int fd)
> +static uint32_t __gem_context_create_local(int fd)
We only need this _local helper in negative parameters checks (in
tests/gem_ctx_create - and perhaps we can open-code those two ioctl calls?).
Both gem_exec_trace, gem_exec_ctx can use the helpers from lib.
> {
> struct drm_i915_gem_context_create create;
>
> @@ -101,7 +101,7 @@ static int loop(unsigned ring,
> execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
> execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
> if (mode != DEFAULT) {
> - execbuf.rsvd1 = __gem_context_create(fd);
> + execbuf.rsvd1 = __gem_context_create_local(fd);
> if (execbuf.rsvd1 == 0)
> return 77;
> }
> @@ -125,7 +125,7 @@ static int loop(unsigned ring,
> uint32_t ctx = 0;
>
> if (mode != DEFAULT && mode != NOP) {
> - execbuf.rsvd1 = __gem_context_create(fd);
> + execbuf.rsvd1 = __gem_context_create_local(fd);
> ctx = gem_context_create(fd);
> }
>
> diff --git a/benchmarks/gem_exec_trace.c b/benchmarks/gem_exec_trace.c
> index 12577649..2724ee92 100644
> --- a/benchmarks/gem_exec_trace.c
> +++ b/benchmarks/gem_exec_trace.c
> @@ -105,7 +105,7 @@ static double elapsed(const struct timespec *start, const
> struct timespec *end)
> return 1e3*(end->tv_sec - start->tv_sec) + 1e-6*(end->tv_nsec -
> start->tv_nsec);
> }
>
> -static uint32_t __gem_context_create(int fd)
> +static uint32_t __gem_context_create_local(int fd)
> {
> struct drm_i915_gem_context_create arg = {};
> drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &arg);
> @@ -216,7 +216,7 @@ static double replay(const char *filename, long nop, long
> range)
> num_ctx = new_ctx;
> }
>
> - ctx[t->handle] = __gem_context_create(fd);
> + ctx[t->handle] = __gem_context_create_local(fd);
> break;
> }
> case DEL_CTX:
> diff --git a/lib/i915/gem_context.c b/lib/i915/gem_context.c
> index 6d9edf5e..a6c37051 100644
> --- a/lib/i915/gem_context.c
> +++ b/lib/i915/gem_context.c
> @@ -43,6 +43,22 @@
> * software features improving submission model (context priority).
> */
>
> +int __gem_context_create(int fd, uint32_t *ctx_id)
> +{
> + struct drm_i915_gem_context_create create;
> + int err = 0;
> +
> + memset(&create, 0, sizeof(create));
> + if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create) == 0)
> + *ctx_id = create.ctx_id;
> + else
> + err = -errno;
> +
> + errno = 0;
> + return err;
> +}
> +
> +
Stray newline
> /**
> * gem_context_create:
> * @fd: open i915 drm file descriptor
> @@ -55,18 +71,44 @@
> */
> uint32_t gem_context_create(int fd)
> {
> - struct drm_i915_gem_context_create create;
> + uint32_t ctx_id;
> + gem_require_contexts(fd);
>
> - memset(&create, 0, sizeof(create));
> - if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create)) {
> - int err = -errno;
> - igt_skip_on(err == -ENODEV || errno == -EINVAL);
> - igt_assert_eq(err, 0);
> - }
> - igt_assert(create.ctx_id != 0);
> - errno = 0;
> + igt_assert_eq(__gem_context_create(
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Save PM interrupt register offsets in device info
On 25/10/2017 08:45, Jani Nikula wrote:
On Tue, 24 Oct 2017, Tvrtko Ursulin wrote:
On 24/10/17 18:48, Jani Nikula wrote:
On Tue, 24 Oct 2017, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2017-10-24 11:41:13)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 875d428..d1a4911 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -462,4 +462,15 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
info->sseu.has_subslice_pg ? "y" : "n");
DRM_DEBUG_DRIVER("has EU power gating: %s\n",
info->sseu.has_eu_pg ? "y" : "n");
+
+ /* Initialize PM interrupt register offsets */
+ if (INTEL_GEN(dev_priv) >= 8) {
+ info->pm_iir_offset = GEN8_GT_IIR(2);
+ info->pm_imr_offset = GEN8_GT_IMR(2);
+ info->pm_ier_offset = GEN8_GT_IER(2);
+ } else {
+ info->pm_iir_offset = GEN6_PMIIR;
+ info->pm_imr_offset = GEN6_PMIMR;
+ info->pm_ier_offset = GEN6_PMIER;
+ }
If you are going to take another pass at this, move these into the
static tables in i915_pci.c
Updating GEN6_FEATURES and GEN8_FEATURES will then percolate into
individual platform defines.
Like I wrote in reply to v1, I'm not convinced we should do this at all.
What makes *these* registers so important they must be in device info?
What makes most of i915_reg.h so unimportant they don't deserve the same
treatment? Where do you draw the line?
I'd draw the line at, no registers at device info.
I suggested to Sagar this change during review so feel responsible to
chime in.
So in general I just find the amount of times our driver asks itself
what it's running on a bit tasteless. :(
I did quick and dirty check by bumping a counter in all the
IS_this|or|that checks, all which can be known at driver probe time, and
wired it up to the PMU so I can check their frequency. The annotated
perf stat output:
root@e31:~# perf stat -a -e i915/whoami/ -I 1000
# time counts unit events
# idle system no X running
1.000298100 10 i915/whoami/
2.000750955 8 i915/whoami/
3.001104193 10 i915/whoami/
4.001333433 10 i915/whoami/
5.001703162 10 i915/whoami/
6.002122721 10 i915/whoami/
# starting X now..
7.002266228 2,203 i915/whoami/
8.002392598 4,682 i915/whoami/
9.002764398 0 i915/whoami/
10.003027119 0 i915/whoami/
11.003486048 42 i915/whoami/
# X idling..
12.003854660 0 i915/whoami/
13.004221680 0 i915/whoami/
14.004622571 0 i915/whoami/
15.004968110 0 i915/whoami/
16.005372363 0 i915/whoami/
17.005778034 0 i915/whoami/
18.005941970 0 i915/whoami/
19.006313427 0 i915/whoami/
20.006676048 0 i915/whoami/
21.007059927 0 i915/whoami/
22.007507818 0 i915/whoami/
23.007887628 0 i915/whoami/
24.008207035 0 i915/whoami/
25.008580496 0 i915/whoami/
# time counts unit events
26.008949236 0 i915/whoami/
27.009433473 0 i915/whoami/
# gfxbench trex starting up
28.009677600 2,605 i915/whoami/
29.009941972716 i915/whoami/
30.010127588 2,190 i915/whoami/
31.010249535 46 i915/whoami/
32.010383565 36 i915/whoami/
33.010527674 0 i915/whoami/
# trex running
34.010760584 4,709 i915/whoami/
35.011079891 5,381 i915/whoami/
36.011280234 5,306 i915/whoami/
37.011719986 5,505 i915/whoami/
38.012017531 5,386 i915/whoami/
39.012529241 5,687 i915/whoami/
40.012922986 6,009 i915/whoami/
41.013120143 5,791 i915/whoami/
42.013399982 5,296 i915/whoami/
43.013712979 5,349 i915/whoami/
44.014107375 5,127 i915/whoami/
45.014553950 5,387 i915/whoami/
46.014953020 5,364 i915/whoami/
47.015243748 4,738 i9
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
Quoting Lionel Landwerlin (2017-10-26 10:50:57) > On 26/10/17 08:34, Tvrtko Ursulin wrote: > > On 25/10/2017 18:38, Chris Wilson wrote: > >> Quoting Chris Wilson (2017-10-25 16:47:13) > >>> Quoting Tvrtko Ursulin (2017-10-25 16:36:15) > From: Tvrtko Ursulin > >>> I've prototyped a quick demo of intel-client-top which produces output > >>> like: > >>> > >>> neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% > >>> vecs0: 0.00% > >>>Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% > >>> vecs0: 0.00% > >>> xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% > >>> vecs0: 0.00% > >> +1 > >> +2 for a graph ;) > > Where are those placement students when you need them! :) > > I won't be your student, but I could like to wire this into gputop. See intel_gpu_overlay for a set of graphs where this would fit in nicely (but not neatly). It's certainly not a robust user-friendly UI (or code), but for measuring kernel-level activity, there's nothing else that tries to put all the information in the same place. Hint ;) -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 v3] lib: Move __gem_context_create to common ioctl wrapper library.
Quoting Michał Winiarski (2017-10-26 11:05:14) > On Wed, Oct 25, 2017 at 05:28:39PM -0700, Antonio Argenziano wrote: > > This patch adds a context creation ioctl wrapper that returns the error > > for the caller to consume. Multiple tests that implemented this already, > > have been changed to use the new library function. > > > > v2: > > - Add gem_require_contexts() to check for contexts support (Chris) > > > > v3: > > - Add gem_has_contexts to check for contexts support and change > > gem_require_contexts to skip if contests support is not available. > > (Chris) > > > > Signed-off-by: Antonio Argenziano > > > > Cc: Chris Wilson > > Cc: Michał Winiarski > > --- > > benchmarks/gem_exec_ctx.c | 6 ++--- > > benchmarks/gem_exec_trace.c | 4 +-- > > lib/i915/gem_context.c | 62 > > + > > lib/i915/gem_context.h | 3 +++ > > tests/gem_ctx_create.c | 10 > > tests/gem_ctx_switch.c | 13 -- > > tests/gem_eio.c | 13 +- > > tests/gem_exec_await.c | 14 ++ > > tests/gem_exec_nop.c| 13 -- > > tests/gem_exec_parallel.c | 15 +++ > > tests/gem_exec_reuse.c | 13 -- > > tests/gem_exec_whisper.c| 13 -- > > 12 files changed, 71 insertions(+), 108 deletions(-) > > > > diff --git a/benchmarks/gem_exec_ctx.c b/benchmarks/gem_exec_ctx.c > > index 0eac04b0..a1c6e5d7 100644 > > --- a/benchmarks/gem_exec_ctx.c > > +++ b/benchmarks/gem_exec_ctx.c > > @@ -64,7 +64,7 @@ static uint32_t batch(int fd) > > return handle; > > } > > > > -static uint32_t __gem_context_create(int fd) > > +static uint32_t __gem_context_create_local(int fd) > > We only need this _local helper in negative parameters checks (in > tests/gem_ctx_create - and perhaps we can open-code those two ioctl calls?). > Both gem_exec_trace, gem_exec_ctx can use the helpers from lib. This benchmarks/, where life is a little different as most igt macros falter (as we aren't inside the test framework). It's a bit of a mess. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6
It has been many years since the last confirmed sighting (and fix) of an
RC6 related bug (usually a system hang). Remove the parameter to stop
users from setting dangerous values, as they often set it during triage
and end up disabling the entire runtime pm instead (the option is not a
fine scalpel!).
Furthermore, it allows users to set known dangerous values which were
intended for testing and not for production use. For testing, we can
always patch in the required setting without having to expose ourselves
to random abuse.
v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the
lack of ilk support better.
v3: Clear intel_info->rc6p if we don't support rc6 itself.
Signed-off-by: Chris Wilson
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_params.c | 7 --
drivers/gpu/drm/i915/i915_params.h | 1 -
drivers/gpu/drm/i915/i915_pci.c | 3 +
drivers/gpu/drm/i915/i915_sysfs.c | 13 +++-
drivers/gpu/drm/i915/intel_drv.h| 5 --
drivers/gpu/drm/i915/intel_guc.c| 3 +-
drivers/gpu/drm/i915/intel_pm.c | 134 +++-
drivers/gpu/drm/i915/intel_uncore.c | 3 -
10 files changed, 57 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3db5851756f0..ca3d5f39338e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2503,7 +2503,7 @@ static int intel_runtime_suspend(struct device *kdev)
struct drm_i915_private *dev_priv = to_i915(dev);
int ret;
- if (WARN_ON_ONCE(!(dev_priv->gt_pm.rc6.enabled && intel_rc6_enabled(
+ if (WARN_ON_ONCE(!(dev_priv->gt_pm.rc6.enabled && HAS_RC6(dev_priv
return -ENODEV;
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 366ba74b0ad2..75100c6e35c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3193,6 +3193,7 @@ intel_info(const struct drm_i915_private *dev_priv)
#define HAS_PSR(dev_priv) ((dev_priv)->info.has_psr)
#define HAS_RC6(dev_priv) ((dev_priv)->info.has_rc6)
#define HAS_RC6p(dev_priv) ((dev_priv)->info.has_rc6p)
+#define HAS_RC6pp(dev_priv) (false)
#define HAS_CSR(dev_priv) ((dev_priv)->info.has_csr)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b4faeb6aa2bd..6da48a77d70c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -50,13 +50,6 @@ i915_param_named_unsafe(semaphores, int, 0400,
"Use semaphores for inter-ring sync "
"(default: -1 (use per-chip defaults))");
-i915_param_named_unsafe(enable_rc6, int, 0400,
- "Enable power-saving render C-state 6. "
- "Different stages can be selected via bitmask values "
- "(0 = disable; 1 = enable rc6; 2 = enable deep rc6; 4 = enable deepest
rc6). "
- "For example, 3 would enable rc6 and deep rc6, and 7 would enable
everything. "
- "default: -1 (use per-chip default)");
-
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
"(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c7292268ed43..374d3a7cb687 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -35,7 +35,6 @@
param(int, lvds_channel_mode, 0) \
param(int, panel_use_ssc, -1) \
param(int, vbt_sdvo_panel_type, -1) \
- param(int, enable_rc6, -1) \
param(int, enable_dc, -1) \
param(int, enable_fbc, -1) \
param(int, enable_ppgtt, -1) \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6458c309c039..f1c6756440a9 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -216,6 +216,9 @@ static const struct intel_device_info intel_gm45_info
__initconst = {
static const struct intel_device_info intel_ironlake_d_info __initconst = {
GEN5_FEATURES,
.platform = INTEL_IRONLAKE,
+ /* ilk does support rc6, but we do not implement [power] contexts */
+ .has_rc6 = 0,
+
};
static const struct intel_device_info intel_ironlake_m_info __initconst = {
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 791759f632e1..1c95c2167d10 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -49,7 +49,18 @@ static u32 calc_residency(struct drm_i915_private *dev_priv,
static ssize_t
show_rc6_mask(struct device *kdev, struct device_attribute *attr, char *buf)
{
- return snp
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_latency: Wire up an interloper for preemption
On Thu, Oct 26, 2017 at 08:31:27AM +0100, Chris Wilson wrote: > For measuring the cost of preemption, inject a low priority spinner > between the two measurements; the difference between the preemption and > the normal dispatch includes both the cost of the spinner dispatch and > of preempting it. Close enough for us to estimate the cost of > preemption, though we don't measure the cost of preemption on the local > ring! And as expected, we're seeing more delay with GuC, probably from worker scheduling delay (~2ms on my SKL if I'm reading the results correctly). Reviewed-by: Michał Winiarski -Michał > > Signed-off-by: Chris Wilson > CC: Michał Winiarski > --- > tests/gem_exec_latency.c | 88 > > 1 file changed, 59 insertions(+), 29 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_eio: Skip in-flight-suspend on snb
Since the discussion on this died and I believe that everyone are scared that the dodge suggestion would require someone to do some work. I could Ack the patch if: + igt_skip_on_f(IS_SANDYBRIDGE(intel_get_drm_devid(fd)), + "random incompletes in CI with this test\n"); + Was replaced with an igt_warn /Marta > -Original Message- > From: Martin Peres [mailto:martin.pe...@linux.intel.com] > Sent: Monday, October 23, 2017 12:29 PM > To: Joonas Lahtinen ; Daniel Vetter: > ; Intel Graphics Development g...@lists.freedesktop.org>; Latvala, Petri > Cc: Chris Wilson ; Lofstedt, Marta > > Subject: Re: [PATCH i-g-t] tests/gem_eio: Skip in-flight-suspend on snb > > On 20/10/17 12:26, Joonas Lahtinen wrote: > > + Petri > > > > On Thu, 2017-10-19 at 16:29 +0300, Martin Peres wrote: > >> On 19/10/17 12:51, Daniel Vetter wrote: > >>> CI gets upset about it resulting in an incomplete, let's skip it > >>> until that's fixed to avoid havoc in the CI farm. Of course this > >>> should/will be reverted as soon as we have a fix (similar to how we > >>> dealt with the snb-dies-in-blt-hangs issue). > >>> > >>> Cc: Joonas Lahtinen > >>> Cc: Chris Wilson > >>> Cc: "Lofstedt, Marta" > >>> Cc: Martin Peres > >>> References: > >>> https://intel-gfx-ci.01.org/tree/drm-tip/igt@gem_eio@in-flight-suspe > >>> nd.html > >>> References: https://bugs.freedesktop.org/show_bug.cgi?id=103289 > >>> Signed-off-by: Daniel Vetter > > > > > > > >> So, let's recap the problem here: > >> - Any incomplete in sharded runs mean that the platform is unfit > >> for pre-merge (because any other test after will go from pass to notrun) > >> - We can't fix issues immediately, especially for old platforms > >> > >> This patch is sweeping the test under the rug by using the skip > >> output, which is not only hard to track, it is also misleading. > >> > >> After discussing with Marta, Arek and Petri, we found some consensus > >> on the following proposal (terminology is up for debate): > >> > >> - Introduce igt_dodge_on(cond, label): Report a pre-emptive 'fail' > >> when the condition is true. Make sure this is over-ridable with > >> IGT_DODGE=0 so as we can easily run these tests without recompiling > them. > > > > Make this igt_skip_on_ci(cond) and require IGT_CI=1 to activate them. > > Much like with simulation. > > replace skip with fail, and we agree. Skips are too easy to ignore! > > > > > Still, a BIOS update to one of the CI machines might mean (if it's not > > now the case, not very far fetched for the future) that we go churn in > > the IGT codebase to drop bunch of these. That's not the optimal > > workflow I can think of when we're discussing a separate mailing list > > for IGT discussion and patches to make it more self-contained. Then we > > bind that new mailing list to our CI farm contents, and bind making > > fixes to the CI farm operation directly to the IGT reviewing bandwidth? > > Isn't what we are proposing doing exactly this? By changing the source code > of IGT, we allow people to send patches to remove some workarounds and > see if they pass or fail in the same way they would propose any change to > IGT. Moreover, we make the running of IGT in our farm as transparent as > possible. > > > > > I'm still thinking best way would be that CI would mask the known > > problematic ones from the failure/pass criteria, and then somebody > > actually looks at the masked on after their testing coverage is > > prioritized. I think IGT should try to provide a wide range of tests > > that are supposed to work on any certain hardware. If they don't, it's > > not a reason to change the tests itself. > > This is true that some skips will be highly-machine specific, but isn't our > role > as developers to know what and what doesn't work? By pushing this to an > external whitelist only for CI, we miss an opportunity to improve this CI > blacklist. > > Now, let me remind you that this blacklist is *only* for tests that hang the > machine or leave it in an inconsistant state which will lead to a crash later. > > > > > With the filter, we can grow the testing coverage for the new > > platforms, even if CI happens to have odd machines that may not pass > > those tests (and we may not have the resources to immediately fix > > those). All this without churning on the IGT codebase. > > You are describing what cibuglog is already doing. Failing tests cases are > suppressed in pre-merge, and associated bugs[1]. > > See above for what this proposal is about. > > [1] https://intel-gfx-ci.01.org/cibuglog/ > > > > > But if this is the only technically viable solution in short-term, > > then so be it. I just see better options too. > > Maybe we need a write up our workflow. This time, a public one! > > I hope ___ 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: Remove unsafe i915.enable_rc6 (rev3)
== Series Details == Series: drm/i915: Remove unsafe i915.enable_rc6 (rev3) URL : https://patchwork.freedesktop.org/series/21884/ State : failure == Summary == Series 21884v3 drm/i915: Remove unsafe i915.enable_rc6 https://patchwork.freedesktop.org/api/1.0/series/21884/revisions/3/mbox/ Test gem_exec_reloc: Subgroup basic-gtt-active: pass -> FAIL (fi-gdg-551) fdo#102582 +2 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-cnl-y) fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:447s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:374s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:531s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:264s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:499s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:506s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:497s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:483s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:565s fi-cnl-y total:284 pass:221 dwarn:0 dfail:0 fail:0 skip:24 fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:415s fi-gdg-551 total:289 pass:175 dwarn:1 dfail:0 fail:4 skip:109 time:249s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:580s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:488s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:429s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:428s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:440s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:487s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:574s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:582s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:593s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:648s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:519s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:507s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:459s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:571s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:417s 2ea0b3d47030274c97624258e09fc7d1ffd0e0f2 drm-tip: 2017y-10m-25d-18h-42m-20s UTC integration manifest e1feeba5a496 drm/i915: Remove unsafe i915.enable_rc6 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6200/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_latency: Wire up an interloper for preemption
Quoting Michał Winiarski (2017-10-26 11:52:31) > On Thu, Oct 26, 2017 at 08:31:27AM +0100, Chris Wilson wrote: > > For measuring the cost of preemption, inject a low priority spinner > > between the two measurements; the difference between the preemption and > > the normal dispatch includes both the cost of the spinner dispatch and > > of preempting it. Close enough for us to estimate the cost of > > preemption, though we don't measure the cost of preemption on the local > > ring! > > And as expected, we're seeing more delay with GuC, probably from worker > scheduling delay (~2ms on my SKL if I'm reading the results correctly). Don't look at bxt then ;) Another order or magnitude. Most of that can be ascribed to using a worker, so we should be able to pare it back somewhat. Just the idea that the GuC may take 10ms to respond to a request is a bit disconcerting! Do we have to wait for the ack from the preempt request? Could we farm that off to some other poor task? Then we would be in a position to avoid that mutex and process-context worker. Oh well, you probably already have ideas and plans for replacing that mutex :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_latency: Wire up an interloper for preemption
Quoting Michał Winiarski (2017-10-26 11:52:31) > On Thu, Oct 26, 2017 at 08:31:27AM +0100, Chris Wilson wrote: > > For measuring the cost of preemption, inject a low priority spinner > > between the two measurements; the difference between the preemption and > > the normal dispatch includes both the cost of the spinner dispatch and > > of preempting it. Close enough for us to estimate the cost of > > preemption, though we don't measure the cost of preemption on the local > > ring! > > And as expected, we're seeing more delay with GuC, probably from worker > scheduling delay (~2ms on my SKL if I'm reading the results correctly). > > Reviewed-by: Michał Winiarski And I forgot to copy'n'paste the r-b before pushing. The inquisition will be calling shortly. I was going to say, no reason to hold back on pushing this, as this is a benchmark for our informational purposes only. One day, it shall be moved to benchmarks/ -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] tests/gem_eio: Skip in-flight-suspend on snb
> -Original Message- > From: Lofstedt, Marta > Sent: Thursday, October 26, 2017 1:57 PM > To: 'Martin Peres' ; Joonas Lahtinen > ; Daniel Vetter ; > Intel Graphics Development ; Latvala, Petri > > Cc: Chris Wilson > Subject: RE: [PATCH i-g-t] tests/gem_eio: Skip in-flight-suspend on snb > > Since the discussion on this died and I believe that everyone are scared that > the dodge suggestion would require someone to do some work. > I could Ack the patch if: > > + igt_skip_on_f(IS_SANDYBRIDGE(intel_get_drm_devid(fd)), > + "random incompletes in CI with this test\n"); > + > > Was replaced with an igt_warn > Forgot to write, it should be igt_warn paired with success on the test. This will produce the WARN result, note this is not the same as dmesg-warn. This is quite rare and it will be noticed. > /Marta > > > -Original Message- > > From: Martin Peres [mailto:martin.pe...@linux.intel.com] > > Sent: Monday, October 23, 2017 12:29 PM > > To: Joonas Lahtinen ; Daniel Vetter: > > ; Intel Graphics Development > g...@lists.freedesktop.org>; Latvala, Petri > > Cc: Chris Wilson ; Lofstedt, Marta > > > > Subject: Re: [PATCH i-g-t] tests/gem_eio: Skip in-flight-suspend on > > snb > > > > On 20/10/17 12:26, Joonas Lahtinen wrote: > > > + Petri > > > > > > On Thu, 2017-10-19 at 16:29 +0300, Martin Peres wrote: > > >> On 19/10/17 12:51, Daniel Vetter wrote: > > >>> CI gets upset about it resulting in an incomplete, let's skip it > > >>> until that's fixed to avoid havoc in the CI farm. Of course this > > >>> should/will be reverted as soon as we have a fix (similar to how > > >>> we dealt with the snb-dies-in-blt-hangs issue). > > >>> > > >>> Cc: Joonas Lahtinen > > >>> Cc: Chris Wilson > > >>> Cc: "Lofstedt, Marta" > > >>> Cc: Martin Peres > > >>> References: > > >>> https://intel-gfx-ci.01.org/tree/drm-tip/igt@gem_eio@in-flight-sus > > >>> pe > > >>> nd.html > > >>> References: https://bugs.freedesktop.org/show_bug.cgi?id=103289 > > >>> Signed-off-by: Daniel Vetter > > > > > > > > > > > >> So, let's recap the problem here: > > >> - Any incomplete in sharded runs mean that the platform is unfit > > >> for pre-merge (because any other test after will go from pass to notrun) > > >> - We can't fix issues immediately, especially for old platforms > > >> > > >> This patch is sweeping the test under the rug by using the skip > > >> output, which is not only hard to track, it is also misleading. > > >> > > >> After discussing with Marta, Arek and Petri, we found some > > >> consensus on the following proposal (terminology is up for debate): > > >> > > >> - Introduce igt_dodge_on(cond, label): Report a pre-emptive 'fail' > > >> when the condition is true. Make sure this is over-ridable with > > >> IGT_DODGE=0 so as we can easily run these tests without recompiling > > them. > > > > > > Make this igt_skip_on_ci(cond) and require IGT_CI=1 to activate them. > > > Much like with simulation. > > > > replace skip with fail, and we agree. Skips are too easy to ignore! > > > > > > > > Still, a BIOS update to one of the CI machines might mean (if it's > > > not now the case, not very far fetched for the future) that we go > > > churn in the IGT codebase to drop bunch of these. That's not the > > > optimal workflow I can think of when we're discussing a separate > > > mailing list for IGT discussion and patches to make it more > > > self-contained. Then we bind that new mailing list to our CI farm > > > contents, and bind making fixes to the CI farm operation directly to the > IGT reviewing bandwidth? > > > > Isn't what we are proposing doing exactly this? By changing the source > > code of IGT, we allow people to send patches to remove some > > workarounds and see if they pass or fail in the same way they would > > propose any change to IGT. Moreover, we make the running of IGT in our > > farm as transparent as possible. > > > > > > > > I'm still thinking best way would be that CI would mask the known > > > problematic ones from the failure/pass criteria, and then somebody > > > actually looks at the masked on after their testing coverage is > > > prioritized. I think IGT should try to provide a wide range of tests > > > that are supposed to work on any certain hardware. If they don't, > > > it's not a reason to change the tests itself. > > > > This is true that some skips will be highly-machine specific, but > > isn't our role as developers to know what and what doesn't work? By > > pushing this to an external whitelist only for CI, we miss an > > opportunity to improve this CI blacklist. > > > > Now, let me remind you that this blacklist is *only* for tests that > > hang the machine or leave it in an inconsistant state which will lead to a > crash later. > > > > > > > > With the filter, we can grow the testing coverage for the new > > > platforms, even if CI happens to have odd machines that may not pass > > > those tests (and we may not have the resources to immediately fix
[Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Remove support for legacy CRC api.
In kernel v4.10 the legacy crc api has been replaced by a generic
drm crc API. While at it, fix igt_require_pipe_crc, the file cannot be
opened any more when the crtc is not active after kernel commit 8038e09be5a3
("drm/crc: Only open CRC on atomic drivers when the CRTC is active.").
Statting the file should be enough for testing it's supported.
Cc: Tomi Sarvela
Cc: Petri Latvala
Cc: Jani Nikula
Signed-off-by: Maarten Lankhorst
---
lib/igt_debugfs.c | 231 +++---
1 file changed, 28 insertions(+), 203 deletions(-)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 8b33b478a9a9..63a0989e5ceb 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -416,16 +416,12 @@ char *igt_crc_to_string(igt_crc_t *crc)
#define MAX_CRC_ENTRIES 10
#define MAX_LINE_LEN (10 + 11 * MAX_CRC_ENTRIES + 1)
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define LEGACY_LINE_LEN (6 * 8 + 5 + 1)
-
struct _igt_pipe_crc {
int fd;
int dir;
int ctl_fd;
int crc_fd;
int flags;
- bool is_legacy;
enum pipe pipe;
enum intel_pipe_crc_source source;
@@ -449,130 +445,6 @@ static const char *pipe_crc_source_name(enum
intel_pipe_crc_source source)
return pipe_crc_sources[source];
}
-static bool igt_pipe_crc_do_start(igt_pipe_crc_t *pipe_crc)
-{
- char buf[64];
-
- /* Stop first just to make sure we don't have lingering state left. */
- igt_pipe_crc_stop(pipe_crc);
-
- if (pipe_crc->is_legacy)
- sprintf(buf, "pipe %s %s", kmstest_pipe_name(pipe_crc->pipe),
- pipe_crc_source_name(pipe_crc->source));
- else
- sprintf(buf, "%s", pipe_crc_source_name(pipe_crc->source));
-
- igt_assert_eq(write(pipe_crc->ctl_fd, buf, strlen(buf)), strlen(buf));
-
- if (!pipe_crc->is_legacy) {
- int err;
-
- sprintf(buf, "crtc-%d/crc/data", pipe_crc->pipe);
- err = 0;
-
- pipe_crc->crc_fd = openat(pipe_crc->dir, buf, pipe_crc->flags);
- if (pipe_crc->crc_fd < 0)
- err = -errno;
-
- if (err == -EINVAL)
- return false;
-
- igt_assert_eq(err, 0);
- }
-
- errno = 0;
- return true;
-}
-
-static void igt_pipe_crc_pipe_off(int fd, enum pipe pipe)
-{
- char buf[32];
-
- sprintf(buf, "pipe %s none", kmstest_pipe_name(pipe));
- igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
-}
-
-static void igt_pipe_crc_reset(int drm_fd)
-{
- struct dirent *dirent;
- const char *cmd = "none";
- bool done = false;
- DIR *dir;
- int fdir;
- int fd;
-
- fdir = igt_debugfs_dir(drm_fd);
- if (fdir < 0)
- return;
-
- dir = fdopendir(fdir);
- if (!dir) {
- close(fdir);
- return;
- }
-
- while ((dirent = readdir(dir))) {
- char buf[PATH_MAX];
-
- if (strcmp(dirent->d_name, "crtc-") != 0)
- continue;
-
- sprintf(buf, "%s/crc/control", dirent->d_name);
- fd = openat(fdir, buf, O_WRONLY);
- if (fd < 0)
- continue;
-
- igt_assert_eq(write(fd, cmd, strlen(cmd)), strlen(cmd));
- close(fd);
-
- done = true;
- }
- closedir(dir);
-
- if (!done) {
- fd = openat(fdir, "i915_display_crtc_ctl", O_WRONLY);
- if (fd != -1) {
- igt_pipe_crc_pipe_off(fd, PIPE_A);
- igt_pipe_crc_pipe_off(fd, PIPE_B);
- igt_pipe_crc_pipe_off(fd, PIPE_C);
-
- close(fd);
- }
- }
-
- close(fdir);
-}
-
-static void pipe_crc_exit_handler(int sig)
-{
- struct dirent *dirent;
- char buf[PATH_MAX];
- DIR *dir;
- int fd;
-
- dir = opendir("/dev/dri");
- if (!dir)
- return;
-
- /*
-* Try to reset CRC capture for all DRM devices, this is only needed
-* for the legacy CRC ABI and can be completely removed once the
-* legacy codepaths are removed.
-*/
- while ((dirent = readdir(dir))) {
- if (strncmp(dirent->d_name, "card", 4) != 0)
- continue;
-
- sprintf(buf, "/dev/dri/%s", dirent->d_name);
- fd = open(buf, O_WRONLY);
-
- igt_pipe_crc_reset(fd);
-
- close(fd);
- }
- closedir(dir);
-}
-
/**
* igt_require_pipe_crc:
*
@@ -582,20 +454,15 @@ static void pipe_crc_exit_handler(int sig)
*/
void igt_require_pipe_crc(int fd)
{
- const char *cmd = "pipe A none";
- int ctl, written;
-
- ctl = igt_debugfs_open(fd, "crtc-0/crc/control", O_RDONLY);
- if (ctl < 0) {
- c
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_latency: Wire up an interloper for preemption
On Thu, Oct 26, 2017 at 12:04:11PM +0100, Chris Wilson wrote: > Quoting Michał Winiarski (2017-10-26 11:52:31) > > On Thu, Oct 26, 2017 at 08:31:27AM +0100, Chris Wilson wrote: > > > For measuring the cost of preemption, inject a low priority spinner > > > between the two measurements; the difference between the preemption and > > > the normal dispatch includes both the cost of the spinner dispatch and > > > of preempting it. Close enough for us to estimate the cost of > > > preemption, though we don't measure the cost of preemption on the local > > > ring! > > > > And as expected, we're seeing more delay with GuC, probably from worker > > scheduling delay (~2ms on my SKL if I'm reading the results correctly). > > Don't look at bxt then ;) Another order or magnitude. > > Most of that can be ascribed to using a worker, so we should be able to > pare it back somewhat. Just the idea that the GuC may take 10ms to > respond to a request is a bit disconcerting! Naively replacing send_mutex with spinlock brings us back into tens of microseconds range. > > Do we have to wait for the ack from the preempt request? Could we farm > that off to some other poor task? Then we would be in a position to > avoid that mutex and process-context worker. Oh well, you probably > already have ideas and plans for replacing that mutex :) > -Chris Error handling becomes more problematic (but doable... we're not doing anything that affects execution while waiting for preemption to complete). I was thinking about fast-path for preemption when it responds with a reasonable amount of time, with fallback to worker when it doesn't. -Michał ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Include RING_MODE when dumping the engine state
Knowing the RING_MODE flags is useful for checking the state of the
engine, such as whether the CS is idle after trying to stop the engines
before reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index fedb839dff61..e676e345c453 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1726,6 +1726,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
struct drm_printer *m)
drm_printf(m, "\tRING_CTL: 0x%08x [%s]\n",
I915_READ(RING_CTL(engine->mmio_base)),
I915_READ(RING_CTL(engine->mmio_base)) & (RING_WAIT |
RING_WAIT_SEMAPHORE) ? "waiting" : "");
+ if (INTEL_GEN(engine->i915) > 2) {
+ drm_printf(m, "\tRING_MODE: 0x%08x [%s]\n",
+ I915_READ(RING_MI_MODE(engine->mmio_base)),
+ I915_READ(RING_MI_MODE(engine->mmio_base)) &
(MODE_IDLE) ? "idle" : "");
+ }
rcu_read_unlock();
--
2.15.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Abandon the reset if we fail to stop the engines
Some machines, *cough* snb *cough*, fail catastrophically if asked to
reset the GPU under certain conditions. The initial guess is that this
is when the rings are still busy at the time of the reset request
(because that's a pattern we've seen elsewhere, hence why we do try
gen3_stop_engines() before reset) so abandon the reset and leave the
device wedged, if gen3_stop_engines() fails.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103240
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Whee! Let's see how much breaks!
-Chris
---
drivers/gpu/drm/i915/intel_uncore.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 20e3c65c0999..c9a254b6125f 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1372,20 +1372,23 @@ int i915_reg_read_ioctl(struct drm_device *dev,
return ret;
}
-static void gen3_stop_engine(struct intel_engine_cs *engine)
+static bool gen3_stop_engine(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
const u32 base = engine->mmio_base;
const i915_reg_t mode = RING_MI_MODE(base);
+
I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));
if (intel_wait_for_register_fw(dev_priv,
mode,
MODE_IDLE,
MODE_IDLE,
- 500))
+ 500)) {
DRM_DEBUG_DRIVER("%s: timed out on STOP_RING\n",
engine->name);
+ return false;
+ }
I915_WRITE_FW(RING_CTL(base), 0);
I915_WRITE_FW(RING_HEAD(base), 0);
@@ -1395,19 +1398,32 @@ static void gen3_stop_engine(struct intel_engine_cs
*engine)
if (I915_READ_FW(RING_HEAD(base)) != 0)
DRM_DEBUG_DRIVER("%s: ring head not parked\n",
engine->name);
+
+ return true;
}
-static void i915_stop_engines(struct drm_i915_private *dev_priv,
- unsigned engine_mask)
+static int i915_stop_engines(struct drm_i915_private *dev_priv,
+unsigned engine_mask)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ bool idle;
if (INTEL_GEN(dev_priv) < 3)
- return;
+ return true;
+ idle = true;
for_each_engine_masked(engine, dev_priv, engine_mask, id)
- gen3_stop_engine(engine);
+ idle &= gen3_stop_engine(engine);
+ if (idle)
+ return idle;
+
+ dev_err(dev_priv->drm.dev, "Failed to stop all engines\n");
+ for_each_engine_masked(engine, dev_priv, engine_mask, id) {
+ struct drm_printer p = drm_debug_printer(__func__);
+ intel_engine_dump(engine, &p);
+ }
+ return false;
}
static bool i915_reset_complete(struct pci_dev *pdev)
@@ -1768,7 +1784,10 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
unsigned engine_mask)
*
* FIXME: Wa for more modern gens needs to be validated
*/
- i915_stop_engines(dev_priv, engine_mask);
+ if (!i915_stop_engines(dev_priv, engine_mask)) {
+ ret = -EIO;
+ break;
+ }
ret = -ENODEV;
if (reset)
--
2.15.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include RING_MODE when dumping the engine state
== Series Details == Series: drm/i915: Include RING_MODE when dumping the engine state URL : https://patchwork.freedesktop.org/series/32691/ State : success == Summary == Series 32691v1 drm/i915: Include RING_MODE when dumping the engine state https://patchwork.freedesktop.org/api/1.0/series/32691/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-gdg-551) fdo#102618 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:437s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:447s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:371s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:516s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:262s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:493s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:490s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:475s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:543s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:596s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:415s fi-gdg-551 total:289 pass:177 dwarn:1 dfail:0 fail:2 skip:109 time:267s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:582s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:481s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:431s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:427s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:430s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:488s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:476s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:584s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:548s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:587s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:644s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:519s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:503s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:453s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:562s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:416s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 4a92e1608691 drm/i915: Include RING_MODE when dumping the engine state == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6201/ ___ 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: Abandon the reset if we fail to stop the engines
== Series Details == Series: drm/i915: Abandon the reset if we fail to stop the engines URL : https://patchwork.freedesktop.org/series/32692/ State : failure == Summary == Series 32692v1 drm/i915: Abandon the reset if we fail to stop the engines https://patchwork.freedesktop.org/api/1.0/series/32692/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> SKIP (fi-ilk-650) Test core_prop_blob: Subgroup basic: pass -> SKIP (fi-ilk-650) Test debugfs_test: Subgroup read_all_entries: pass -> SKIP (fi-ilk-650) Test drv_getparams_basic: Subgroup basic-eu-total: pass -> SKIP (fi-ilk-650) Subgroup basic-subslice-total: pass -> SKIP (fi-ilk-650) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (fi-ilk-650) Test gem_basic: Subgroup bad-close: pass -> SKIP (fi-ilk-650) Subgroup create-close: pass -> SKIP (fi-ilk-650) Subgroup create-fd-close: pass -> SKIP (fi-ilk-650) Test gem_busy: Subgroup basic-busy-default: pass -> SKIP (fi-ilk-650) Subgroup basic-hang-default: pass -> SKIP (fi-ilk-650) Test gem_close_race: Subgroup basic-process: pass -> SKIP (fi-ilk-650) Subgroup basic-threads: pass -> SKIP (fi-ilk-650) Test gem_cpu_reloc: Subgroup basic: pass -> SKIP (fi-ilk-650) Test gem_cs_tlb: Subgroup basic-default: pass -> SKIP (fi-ilk-650) Test gem_exec_basic: Subgroup basic-bsd: pass -> SKIP (fi-ilk-650) Subgroup basic-default: pass -> SKIP (fi-ilk-650) Subgroup basic-render: pass -> SKIP (fi-ilk-650) Subgroup gtt-bsd: pass -> SKIP (fi-ilk-650) Subgroup gtt-default: pass -> SKIP (fi-ilk-650) Subgroup gtt-render: pass -> SKIP (fi-ilk-650) Subgroup readonly-bsd: pass -> SKIP (fi-ilk-650) Subgroup readonly-default: pass -> SKIP (fi-ilk-650) Subgroup readonly-render: pass -> SKIP (fi-ilk-650) Test gem_exec_create: Subgroup basic: pass -> SKIP (fi-ilk-650) Test gem_exec_fence: Subgroup basic-busy-default: pass -> SKIP (fi-ilk-650) Subgroup basic-wait-default: pass -> SKIP (fi-ilk-650) Subgroup basic-await-default: pass -> SKIP (fi-ilk-650) Subgroup await-hang-default: pass -> SKIP (fi-ilk-650) Subgroup nb-await-default: pass -> SKIP (fi-ilk-650) Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> SKIP (fi-ilk-650) Subgroup basic-batch-kernel-default-wb: pass -> SKIP (fi-ilk-650) Subgroup basic-uc-pro-default: pass -> SKIP (fi-ilk-650) Subgroup basic-uc-prw-default: pass -> SKIP (fi-ilk-650) Subgroup basic-uc-ro-default: pass -> SKIP (fi-ilk-650) Subgroup basic-uc-rw-default: pass -> SKIP (fi-ilk-650) Subgroup basic-uc-set-default: pass -> SKIP (fi-ilk-650) Subgroup basic-wb-pro-default: pass -> SKIP (fi-ilk-650) Subgroup basic-wb-prw-default: pass -> SKIP (fi-ilk-650) Subgroup basic-wb-ro-before-default: pass -> SKIP (fi-ilk-650) Subgroup basic-wb-ro-default: pass -> SKIP (fi-ilk-650) Subgroup basic-wb-rw-before-default: WARNING: Long output truncated fi-cnl-y failed to connect after reboot df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 5d5082c1ab71 drm/i915: Abandon the reset if we fail to stop the engines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6202/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_exec_latency: Wire up an interloper for preemption
== Series Details == Series: igt/gem_exec_latency: Wire up an interloper for preemption URL : https://patchwork.freedesktop.org/series/32679/ State : failure == Summary == Series 32679 revision 1 was fully merged or fully failed: no git log == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_425/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Abandon the reset if we fail to stop the engines
Quoting Patchwork (2017-10-26 13:33:06) > == Series Details == > > Series: drm/i915: Abandon the reset if we fail to stop the engines > URL : https://patchwork.freedesktop.org/series/32692/ > State : failure > > == Summary == > > Series 32692v1 drm/i915: Abandon the reset if we fail to stop the engines > https://patchwork.freedesktop.org/api/1.0/series/32692/revisions/1/mbox/ > > Test core_auth: > Subgroup basic-auth: > pass -> SKIP (fi-ilk-650) > Test core_prop_blob: > Subgroup basic: > pass -> SKIP (fi-ilk-650) > Test debugfs_test: > Subgroup read_all_entries: > pass -> SKIP (fi-ilk-650) > Test drv_getparams_basic: > Subgroup basic-eu-total: > pass -> SKIP (fi-ilk-650) > Subgroup basic-subslice-total: > pass -> SKIP (fi-ilk-650) > Test drv_hangman: > Subgroup error-state-basic: > pass -> SKIP (fi-ilk-650) > Test gem_basic: > Subgroup bad-close: > pass -> SKIP (fi-ilk-650) > Subgroup create-close: > pass -> SKIP (fi-ilk-650) > Subgroup create-fd-close: > pass -> SKIP (fi-ilk-650) > Test gem_busy: > Subgroup basic-busy-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-hang-default: > pass -> SKIP (fi-ilk-650) > Test gem_close_race: > Subgroup basic-process: > pass -> SKIP (fi-ilk-650) > Subgroup basic-threads: > pass -> SKIP (fi-ilk-650) > Test gem_cpu_reloc: > Subgroup basic: > pass -> SKIP (fi-ilk-650) > Test gem_cs_tlb: > Subgroup basic-default: > pass -> SKIP (fi-ilk-650) > Test gem_exec_basic: > Subgroup basic-bsd: > pass -> SKIP (fi-ilk-650) > Subgroup basic-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-render: > pass -> SKIP (fi-ilk-650) > Subgroup gtt-bsd: > pass -> SKIP (fi-ilk-650) > Subgroup gtt-default: > pass -> SKIP (fi-ilk-650) > Subgroup gtt-render: > pass -> SKIP (fi-ilk-650) > Subgroup readonly-bsd: > pass -> SKIP (fi-ilk-650) > Subgroup readonly-default: > pass -> SKIP (fi-ilk-650) > Subgroup readonly-render: > pass -> SKIP (fi-ilk-650) > Test gem_exec_create: > Subgroup basic: > pass -> SKIP (fi-ilk-650) > Test gem_exec_fence: > Subgroup basic-busy-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-wait-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-await-default: > pass -> SKIP (fi-ilk-650) > Subgroup await-hang-default: > pass -> SKIP (fi-ilk-650) > Subgroup nb-await-default: > pass -> SKIP (fi-ilk-650) > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > pass -> SKIP (fi-ilk-650) > Subgroup basic-batch-kernel-default-wb: > pass -> SKIP (fi-ilk-650) > Subgroup basic-uc-pro-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-uc-prw-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-uc-ro-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-uc-rw-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-uc-set-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-wb-pro-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-wb-prw-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-wb-ro-before-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-wb-ro-default: > pass -> SKIP (fi-ilk-650) > Subgroup basic-wb-rw-before-default: > WARNING: Long output truncated > fi-cnl-y failed to connect after reboot That's suspiciously much less fallout than I expected. We have a severe lack of GPU reset stress. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Save PM interrupt register offsets in device info
On Thu, 26 Oct 2017, Tvrtko Ursulin wrote:
> On 25/10/2017 08:45, Jani Nikula wrote:
>> On Tue, 24 Oct 2017, Tvrtko Ursulin wrote:
>>> On 24/10/17 18:48, Jani Nikula wrote:
On Tue, 24 Oct 2017, Chris Wilson wrote:
> Quoting Sagar Arun Kamble (2017-10-24 11:41:13)
>> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
>> b/drivers/gpu/drm/i915/intel_device_info.c
>> index 875d428..d1a4911 100644
>> --- a/drivers/gpu/drm/i915/intel_device_info.c
>> +++ b/drivers/gpu/drm/i915/intel_device_info.c
>> @@ -462,4 +462,15 @@ void intel_device_info_runtime_init(struct
>> drm_i915_private *dev_priv)
>>info->sseu.has_subslice_pg ? "y" : "n");
>> DRM_DEBUG_DRIVER("has EU power gating: %s\n",
>>info->sseu.has_eu_pg ? "y" : "n");
>> +
>> + /* Initialize PM interrupt register offsets */
>> + if (INTEL_GEN(dev_priv) >= 8) {
>> + info->pm_iir_offset = GEN8_GT_IIR(2);
>> + info->pm_imr_offset = GEN8_GT_IMR(2);
>> + info->pm_ier_offset = GEN8_GT_IER(2);
>> + } else {
>> + info->pm_iir_offset = GEN6_PMIIR;
>> + info->pm_imr_offset = GEN6_PMIMR;
>> + info->pm_ier_offset = GEN6_PMIER;
>> + }
>
> If you are going to take another pass at this, move these into the
> static tables in i915_pci.c
>
> Updating GEN6_FEATURES and GEN8_FEATURES will then percolate into
> individual platform defines.
Like I wrote in reply to v1, I'm not convinced we should do this at all.
What makes *these* registers so important they must be in device info?
What makes most of i915_reg.h so unimportant they don't deserve the same
treatment? Where do you draw the line?
I'd draw the line at, no registers at device info.
>>>
>>> I suggested to Sagar this change during review so feel responsible to
>>> chime in.
>>>
>>> So in general I just find the amount of times our driver asks itself
>>> what it's running on a bit tasteless. :(
>>>
>>> I did quick and dirty check by bumping a counter in all the
>>> IS_this|or|that checks, all which can be known at driver probe time, and
>>> wired it up to the PMU so I can check their frequency. The annotated
>>> perf stat output:
>>>
>>> root@e31:~# perf stat -a -e i915/whoami/ -I 1000
>>> # time counts unit events
>>>
>>> # idle system no X running
>>>
>>>1.000298100 10 i915/whoami/
>>>
>>>2.000750955 8 i915/whoami/
>>>
>>>3.001104193 10 i915/whoami/
>>>
>>>4.001333433 10 i915/whoami/
>>>
>>>5.001703162 10 i915/whoami/
>>>
>>>6.002122721 10 i915/whoami/
>>>
>>>
>>> # starting X now..
>>>
>>>7.002266228 2,203 i915/whoami/
>>>
>>>8.002392598 4,682 i915/whoami/
>>>
>>>9.002764398 0 i915/whoami/
>>>
>>> 10.003027119 0 i915/whoami/
>>>
>>> 11.003486048 42 i915/whoami/
>>>
>>>
>>> # X idling..
>>>
>>> 12.003854660 0 i915/whoami/
>>>
>>> 13.004221680 0 i915/whoami/
>>>
>>> 14.004622571 0 i915/whoami/
>>>
>>> 15.004968110 0 i915/whoami/
>>>
>>> 16.005372363 0 i915/whoami/
>>>
>>> 17.005778034 0 i915/whoami/
>>>
>>> 18.005941970 0 i915/whoami/
>>>
>>> 19.006313427 0 i915/whoami/
>>>
>>> 20.006676048 0 i915/whoami/
>>>
>>> 21.007059927 0 i915/whoami/
>>>
>>> 22.007507818 0 i915/whoami/
>>>
>>> 23.007887628 0 i915/whoami/
>>>
>>> 24.008207035 0 i915/whoami/
>>>
>>> 25.008580496 0 i915/whoami/
>>>
>>> # time counts unit events
>>> 26.008949236 0 i915/whoami/
>>>
>>> 27.009433473 0 i915/whoami/
>>>
>>>
>>> # gfxbench trex starting up
>>>
>>> 28.009677600 2,605 i915/whoami/
>>>
>>> 29.009941972716 i915/whoami/
>>>
>>> 30.010127588 2,190 i915/whoami/
>>>
>>> 31.010249535 46 i915/whoami/
>>>
>>> 32.010383565 36 i915/whoami/
>>>
>>> 33.010527674 0 i915/whoami/
>>>
>>>
>>> # trex running
>>>
>>> 34.010760584 4,709 i915/whoami/
>>>
>>> 35.011079891 5,381 i915/whoami/
>>>
>>> 36.011280234 5,306 i9
Re: [Intel-gfx] [PATCH v3 05/12] drm/i915/guc: Add a second client, to be used for preemption
On Wed, 25 Oct 2017 22:00:13 +0200, Michał Winiarski
wrote:
From: Dave Gordon
This second client is created with priority KMD_HIGH, and marked
as preemptive. This will allow us to request preemption using GuC
actions.
v2: Extract clients creation into a helper, debugfs fixups. (Michał)
Recreate doorbell on init. (Daniele)
Move clients into an array.
v3: And move clients back from an array, to get rid of the enum (Michał)
Signed-off-by: Dave Gordon
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Jeff McGee
Cc: Michal Wajdeczko
Cc: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +
drivers/gpu/drm/i915/i915_guc_submission.c | 112
-
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 82 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..6e178d75bb17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2484,6 +2484,8 @@ static int i915_guc_info(struct seq_file *m, void
*data)
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
+ seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client);
+ i915_guc_client_info(m, dev_priv, guc->preempt_client);
i915_guc_log_info(m, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d1a5613da24c..1d3123e74bc4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -33,10 +33,11 @@
*
* GuC client:
* A i915_guc_client refers to a submission path through GuC.
Currently, there
- * is only one of these (the execbuf_client) and this one is charged
with all
- * submissions to the GuC. This struct is the owner of a doorbell, a
process
- * descriptor and a workqueue (all of them inside a single gem object
that
- * contains all required pages for these elements).
+ * are two clients. One of them (the execbuf_client) is charged with all
+ * submissions to the GuC, the other one (preempt_client) is
responsible for
+ * preempting the execbuf_client. This struct is the owner of a
doorbell, a
+ * process descriptor and a workqueue (all of them inside a single gem
object
+ * that contains all required pages for these elements).
*
* GuC stage descriptor:
* During initialization, the driver allocates a static pool of 1024
such
@@ -363,6 +364,8 @@ static void guc_stage_desc_init(struct intel_guc
*guc,
memset(desc, 0, sizeof(*desc));
desc->attribute = GUC_STAGE_DESC_ATTR_ACTIVE |
GUC_STAGE_DESC_ATTR_KERNEL;
+ if (client->priority <= GUC_CLIENT_PRIORITY_HIGH)
Can we use
if (client->priority == GUC_CLIENT_PRIORITY_KMD_HIGH ||
client->priority == GUC_CLIENT_PRIORITY_HIGH)
I assume compiler will optimize it to the same asm, but then we can
avoid condition that may be read wrong (priority less then high)
+ desc->attribute |= GUC_STAGE_DESC_ATTR_PREEMPT;
desc->stage_id = client->stage_id;
desc->priority = client->priority;
desc->db_id = client->doorbell_id;
@@ -763,14 +766,18 @@ static int guc_init_doorbell_hw(struct intel_guc
*guc)
/* Now for every client (and not only execbuf_client) make sure their
* doorbells are known by the GuC */
- //for (client = client_list; client != NULL; client = client->next)
- {
- ret = __create_doorbell(client);
- if (ret) {
- DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
- client->stage_id, ret);
- return ret;
- }
+ ret = __create_doorbell(guc->execbuf_client);
+ if (ret) {
+ DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
+ guc->execbuf_client->stage_id, ret);
This
+ return ret;
+ }
+
+ ret = __create_doorbell(guc->preempt_client);
+ if (ret) {
+ DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
+ guc->preempt_client->stage_id, ret);
And this error can be moved to __create_doorbell to avoid duplication
+ return ret;
}
/* Read back & verify all (used & unused) doorbell registers */
@@ -895,6 +902,47 @@ static void guc_client_free(struct i915_guc_client
*client)
kfree(client);
}
+static int guc_clients_create(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct i915_guc_client *client;
+
+ client = guc_client_alloc(dev_priv,
+ INTEL_INFO(dev_priv)->ring_mask,
+ GUC_CLIENT_PRIORITY_KMD_NORMAL,
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for lib/igt_debugfs: Remove support for legacy CRC api.
== Series Details == Series: lib/igt_debugfs: Remove support for legacy CRC api. URL : https://patchwork.freedesktop.org/series/32689/ State : failure == Summary == IGT patchset tested on top of latest successful build 1fc4de1ca390adec9be8bd7cc0c36cab07465959 igt/gem_exec_latency: Wire up an interloper for preemption with latest DRM-Tip kernel build CI_DRM_3286 df3033b17405 drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest No testlist changes. Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> INCOMPLETE (fi-cnl-y) Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:444s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:454s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:374s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:528s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:264s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:500s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:502s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:502s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:484s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:561s fi-cnl-y total:231 pass:206 dwarn:0 dfail:0 fail:0 skip:24 fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:416s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:250s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:578s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:487s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:437s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:497s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:585s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:586s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:550s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:457s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:645s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:518s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:510s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:461s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:564s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:429s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_427/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Abandon the reset if we fail to stop the engines
On Thu, Oct 26, 2017 at 01:12:12PM +0100, Chris Wilson wrote:
> Some machines, *cough* snb *cough*, fail catastrophically if asked to
> reset the GPU under certain conditions.
Did we try skipping the gen6_rps_disable() already?
> The initial guess is that this
> is when the rings are still busy at the time of the reset request
> (because that's a pattern we've seen elsewhere, hence why we do try
> gen3_stop_engines() before reset) so abandon the reset and leave the
> device wedged, if gen3_stop_engines() fails.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103240
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> Whee! Let's see how much breaks!
> -Chris
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 33 ++---
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 20e3c65c0999..c9a254b6125f 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1372,20 +1372,23 @@ int i915_reg_read_ioctl(struct drm_device *dev,
> return ret;
> }
>
> -static void gen3_stop_engine(struct intel_engine_cs *engine)
> +static bool gen3_stop_engine(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> const u32 base = engine->mmio_base;
> const i915_reg_t mode = RING_MI_MODE(base);
>
> +
> I915_WRITE_FW(mode, _MASKED_BIT_ENABLE(STOP_RING));
> if (intel_wait_for_register_fw(dev_priv,
> mode,
> MODE_IDLE,
> MODE_IDLE,
> -500))
> +500)) {
> DRM_DEBUG_DRIVER("%s: timed out on STOP_RING\n",
>engine->name);
> + return false;
> + }
>
> I915_WRITE_FW(RING_CTL(base), 0);
> I915_WRITE_FW(RING_HEAD(base), 0);
> @@ -1395,19 +1398,32 @@ static void gen3_stop_engine(struct intel_engine_cs
> *engine)
> if (I915_READ_FW(RING_HEAD(base)) != 0)
> DRM_DEBUG_DRIVER("%s: ring head not parked\n",
>engine->name);
> +
> + return true;
> }
>
> -static void i915_stop_engines(struct drm_i915_private *dev_priv,
> - unsigned engine_mask)
> +static int i915_stop_engines(struct drm_i915_private *dev_priv,
> + unsigned engine_mask)
> {
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
> + bool idle;
>
> if (INTEL_GEN(dev_priv) < 3)
> - return;
> + return true;
>
> + idle = true;
> for_each_engine_masked(engine, dev_priv, engine_mask, id)
> - gen3_stop_engine(engine);
> + idle &= gen3_stop_engine(engine);
> + if (idle)
> + return idle;
> +
> + dev_err(dev_priv->drm.dev, "Failed to stop all engines\n");
> + for_each_engine_masked(engine, dev_priv, engine_mask, id) {
> + struct drm_printer p = drm_debug_printer(__func__);
> + intel_engine_dump(engine, &p);
> + }
> + return false;
> }
>
> static bool i915_reset_complete(struct pci_dev *pdev)
> @@ -1768,7 +1784,10 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv,
> unsigned engine_mask)
>*
>* FIXME: Wa for more modern gens needs to be validated
>*/
> - i915_stop_engines(dev_priv, engine_mask);
> + if (!i915_stop_engines(dev_priv, engine_mask)) {
> + ret = -EIO;
> + break;
> + }
>
> ret = -ENODEV;
> if (reset)
> --
> 2.15.0.rc2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
On 26/10/2017 10:50, Lionel Landwerlin wrote: On 26/10/17 08:34, Tvrtko Ursulin wrote: On 25/10/2017 18:38, Chris Wilson wrote: Quoting Chris Wilson (2017-10-25 16:47:13) Quoting Tvrtko Ursulin (2017-10-25 16:36:15) From: Tvrtko Ursulin I've prototyped a quick demo of intel-client-top which produces output like: neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% +1 +2 for a graph ;) Where are those placement students when you need them! :) I won't be your student, but I could like to wire this into gputop. I was thinking gputop as well but did find the time to look at it yet. If you want to play with it, I have uploaded my kernel and igt branches which implement this to below locations*. But be aware the sysfs interface is at the moment a prototype and we haven't decided we are going with it 100%. So don't invest too much in any experiments you might decide to do. You'll see in the intel_client_top demo that I have also not invested a huge amount to make it nice and polished (and bug free!). *) https://cgit.freedesktop.org/~tursulin/drm-intel/log/?h=context-stats https://cgit.freedesktop.org/~tursulin/intel-gpu-tools/log/?h=context-stats Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)
Kasan spotted
[IGT] gem_tiled_pread_pwrite: exiting, ret=0
==
BUG: KASAN: use-after-free in __i915_gem_object_reset_page_iter+0x15c/0x170
[i915]
Read of size 8 at addr 8801359da310 by task kworker/3:2/182
CPU: 3 PID: 182 Comm: kworker/3:2 Tainted: G U
4.14.0-rc6-CI-Custom_3340+ #1
Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS
GELKRVPA.X64.0062.B30.1708222146 08/22/2017
Workqueue: events __i915_gem_free_work [i915]
Call Trace:
dump_stack+0x68/0xa0
print_address_description+0x78/0x290
? __i915_gem_object_reset_page_iter+0x15c/0x170 [i915]
kasan_report+0x23d/0x350
__asan_report_load8_noabort+0x19/0x20
__i915_gem_object_reset_page_iter+0x15c/0x170 [i915]
? i915_gem_object_truncate+0x100/0x100 [i915]
? lock_acquire+0x380/0x380
__i915_gem_object_put_pages+0x30d/0x530 [i915]
__i915_gem_free_objects+0x551/0xbd0 [i915]
? lock_acquire+0x13e/0x380
__i915_gem_free_work+0x4e/0x70 [i915]
process_one_work+0x6f6/0x1590
? pwq_dec_nr_in_flight+0x2b0/0x2b0
worker_thread+0xe6/0xe90
? pci_mmcfg_check_reserved+0x110/0x110
kthread+0x309/0x410
? process_one_work+0x1590/0x1590
? kthread_create_on_node+0xb0/0xb0
ret_from_fork+0x27/0x40
Allocated by task 1801:
save_stack_trace+0x1b/0x20
kasan_kmalloc+0xee/0x190
kasan_slab_alloc+0x12/0x20
kmem_cache_alloc+0xdc/0x2e0
radix_tree_node_alloc.constprop.12+0x48/0x330
__radix_tree_create+0x274/0x480
__radix_tree_insert+0xa2/0x610
i915_gem_object_get_sg+0x224/0x670 [i915]
i915_gem_object_get_page+0xb5/0x1c0 [i915]
i915_gem_pread_ioctl+0x822/0xf60 [i915]
drm_ioctl_kernel+0x13f/0x1c0
drm_ioctl+0x6cf/0x980
do_vfs_ioctl+0x184/0xf30
SyS_ioctl+0x41/0x70
entry_SYSCALL_64_fastpath+0x1c/0xb1
Freed by task 37:
save_stack_trace+0x1b/0x20
kasan_slab_free+0xaf/0x190
kmem_cache_free+0xbf/0x340
radix_tree_node_rcu_free+0x79/0x90
rcu_process_callbacks+0x46d/0xf40
__do_softirq+0x21c/0x8d3
The buggy address belongs to the object at 8801359da0f0
which belongs to the cache radix_tree_node of size 576
The buggy address is located 544 bytes inside of
576-byte region [8801359da0f0, 8801359da330)
The buggy address belongs to the page:
page:ea0004d67600 count:1 mapcount:0 mapping: (null) index:0x0
compound_mapcount: 0
flags: 0x80008100(slab|head)
raw: 80008100 000100110011
raw: ea0004b52920 ea0004b38020 88015b416a80
page dumped because: kasan: bad access detected
Memory state around the buggy address:
8801359da200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
8801359da280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>8801359da300: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
^
8801359da380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
8801359da400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
Disabling lock debugging due to kernel taint
which looks like the slab containing the radixtree iter was freed as we
traversed the tree, taking the rcu read lock across the loop should
prevent that (deferring all the frees until the end).
Reported-by: Tomi Sarvela
Fixes: 96d776345277 ("drm/i915: Use a radixtree for random access to the
object's backing storage")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d803ef5f4a7f..9d9c37ff51c9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2267,8 +2267,10 @@ static void __i915_gem_object_reset_page_iter(struct
drm_i915_gem_object *obj)
struct radix_tree_iter iter;
void __rcu **slot;
+ rcu_read_lock();
radix_tree_for_each_slot(slot, &obj->mm.get_page.radix, &iter, 0)
radix_tree_delete(&obj->mm.get_page.radix, iter.index);
+ rcu_read_unlock();
}
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
--
2.15.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)
Kasan spotted
[IGT] gem_tiled_pread_pwrite: exiting, ret=0
==
BUG: KASAN: use-after-free in __i915_gem_object_reset_page_iter+0x15c/0x170
[i915]
Read of size 8 at addr 8801359da310 by task kworker/3:2/182
CPU: 3 PID: 182 Comm: kworker/3:2 Tainted: G U
4.14.0-rc6-CI-Custom_3340+ #1
Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS
GELKRVPA.X64.0062.B30.1708222146 08/22/2017
Workqueue: events __i915_gem_free_work [i915]
Call Trace:
dump_stack+0x68/0xa0
print_address_description+0x78/0x290
? __i915_gem_object_reset_page_iter+0x15c/0x170 [i915]
kasan_report+0x23d/0x350
__asan_report_load8_noabort+0x19/0x20
__i915_gem_object_reset_page_iter+0x15c/0x170 [i915]
? i915_gem_object_truncate+0x100/0x100 [i915]
? lock_acquire+0x380/0x380
__i915_gem_object_put_pages+0x30d/0x530 [i915]
__i915_gem_free_objects+0x551/0xbd0 [i915]
? lock_acquire+0x13e/0x380
__i915_gem_free_work+0x4e/0x70 [i915]
process_one_work+0x6f6/0x1590
? pwq_dec_nr_in_flight+0x2b0/0x2b0
worker_thread+0xe6/0xe90
? pci_mmcfg_check_reserved+0x110/0x110
kthread+0x309/0x410
? process_one_work+0x1590/0x1590
? kthread_create_on_node+0xb0/0xb0
ret_from_fork+0x27/0x40
Allocated by task 1801:
save_stack_trace+0x1b/0x20
kasan_kmalloc+0xee/0x190
kasan_slab_alloc+0x12/0x20
kmem_cache_alloc+0xdc/0x2e0
radix_tree_node_alloc.constprop.12+0x48/0x330
__radix_tree_create+0x274/0x480
__radix_tree_insert+0xa2/0x610
i915_gem_object_get_sg+0x224/0x670 [i915]
i915_gem_object_get_page+0xb5/0x1c0 [i915]
i915_gem_pread_ioctl+0x822/0xf60 [i915]
drm_ioctl_kernel+0x13f/0x1c0
drm_ioctl+0x6cf/0x980
do_vfs_ioctl+0x184/0xf30
SyS_ioctl+0x41/0x70
entry_SYSCALL_64_fastpath+0x1c/0xb1
Freed by task 37:
save_stack_trace+0x1b/0x20
kasan_slab_free+0xaf/0x190
kmem_cache_free+0xbf/0x340
radix_tree_node_rcu_free+0x79/0x90
rcu_process_callbacks+0x46d/0xf40
__do_softirq+0x21c/0x8d3
The buggy address belongs to the object at 8801359da0f0
which belongs to the cache radix_tree_node of size 576
The buggy address is located 544 bytes inside of
576-byte region [8801359da0f0, 8801359da330)
The buggy address belongs to the page:
page:ea0004d67600 count:1 mapcount:0 mapping: (null) index:0x0
compound_mapcount: 0
flags: 0x80008100(slab|head)
raw: 80008100 000100110011
raw: ea0004b52920 ea0004b38020 88015b416a80
page dumped because: kasan: bad access detected
Memory state around the buggy address:
8801359da200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
8801359da280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>8801359da300: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
^
8801359da380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
8801359da400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
Disabling lock debugging due to kernel taint
which looks like the slab containing the radixtree iter was freed as we
traversed the tree, taking the rcu read lock across the loop should
prevent that (deferring all the frees until the end).
Reported-by: Tomi Sarvela
Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4f26f80b1b3e..10affb35ac56 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -104,6 +104,7 @@ static void lut_close(struct i915_gem_context *ctx)
kmem_cache_free(ctx->i915->luts, lut);
}
+ rcu_read_lock();
radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
struct i915_vma *vma = rcu_dereference_raw(*slot);
struct drm_i915_gem_object *obj = vma->obj;
@@ -115,6 +116,7 @@ static void lut_close(struct i915_gem_context *ctx)
__i915_gem_object_release_unless_active(obj);
}
+ rcu_read_unlock();
}
static void i915_gem_context_free(struct i915_gem_context *ctx)
--
2.15.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
Quoting Tvrtko Ursulin (2017-10-26 14:00:28) > > On 26/10/2017 10:50, Lionel Landwerlin wrote: > > On 26/10/17 08:34, Tvrtko Ursulin wrote: > >> On 25/10/2017 18:38, Chris Wilson wrote: > >>> Quoting Chris Wilson (2017-10-25 16:47:13) > Quoting Tvrtko Ursulin (2017-10-25 16:36:15) > > From: Tvrtko Ursulin > I've prototyped a quick demo of intel-client-top which produces > output like: > > neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: > 0.00% vecs0: 0.00% > Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: > 0.00% vecs0: 0.00% > xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: > 0.00% vecs0: 0.00% > >>> +1 > >>> +2 for a graph ;) > >> Where are those placement students when you need them! :) > > > > I won't be your student, but I could like to wire this into gputop. > > I was thinking gputop as well but did find the time to look at it yet. We don't even ship gputop or the perf generator in igt... Can we at least make noises towards owning that code... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Abandon the reset if we fail to stop the engines
Quoting Ville Syrjälä (2017-10-26 13:59:05) > On Thu, Oct 26, 2017 at 01:12:12PM +0100, Chris Wilson wrote: > > Some machines, *cough* snb *cough*, fail catastrophically if asked to > > reset the GPU under certain conditions. > > Did we try skipping the gen6_rps_disable() already? I had thought we had taken that out a while ago... commit f2a91d1a6f5960c08f1ca60bd076f4dc020c50c6 Author: Chris Wilson Date: Wed Sep 21 14:51:06 2016 +0100 drm/i915: Restore current RPS state after reset removes the frobbing inside i915_reset() itself, but still talks about RPS needing to be restored... Ok, that's the post-reset stuff to make sure that the hw/sw tracking align. We are not touching rc6/rps prior to hitting GDRST. Maybe we should? (Unless I'm blind and overlooked something in the reset.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/guc: Add a second client, to be used for preemption
From: Dave Gordon
This second client is created with priority KMD_HIGH, and marked
as preemptive. This will allow us to request preemption using GuC actions.
v2: Extract clients creation into a helper, debugfs fixups. (Michał)
Recreate doorbell on init. (Daniele)
Move clients into an array.
v3: And move clients back from an array, to get rid of the enum (Michał)
v4: Use is_high_priority, move DRM_ERROR into __create_doorbell, move
GEM_BUG_ON inside guc_clients_create (Michał)
Signed-off-by: Dave Gordon
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Jeff McGee
Cc: Michal Wajdeczko
Cc: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +
drivers/gpu/drm/i915/i915_guc_submission.c | 117 -
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 84 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..6e178d75bb17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2484,6 +2484,8 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
+ seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client);
+ i915_guc_client_info(m, dev_priv, guc->preempt_client);
i915_guc_log_info(m, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d1a5613da24c..4c8a0241d953 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -33,10 +33,11 @@
*
* GuC client:
* A i915_guc_client refers to a submission path through GuC. Currently, there
- * is only one of these (the execbuf_client) and this one is charged with all
- * submissions to the GuC. This struct is the owner of a doorbell, a process
- * descriptor and a workqueue (all of them inside a single gem object that
- * contains all required pages for these elements).
+ * are two clients. One of them (the execbuf_client) is charged with all
+ * submissions to the GuC, the other one (preempt_client) is responsible for
+ * preempting the execbuf_client. This struct is the owner of a doorbell, a
+ * process descriptor and a workqueue (all of them inside a single gem object
+ * that contains all required pages for these elements).
*
* GuC stage descriptor:
* During initialization, the driver allocates a static pool of 1024 such
@@ -83,7 +84,8 @@
static inline bool is_high_priority(struct i915_guc_client* client)
{
- return client->priority <= GUC_CLIENT_PRIORITY_HIGH;
+ return (client->priority == GUC_CLIENT_PRIORITY_KMD_HIGH ||
+ client->priority == GUC_CLIENT_PRIORITY_HIGH);
}
static int __reserve_doorbell(struct i915_guc_client *client)
@@ -196,8 +198,11 @@ static int __create_doorbell(struct i915_guc_client
*client)
doorbell->cookie = 0;
err = __guc_allocate_doorbell(client->guc, client->stage_id);
- if (err)
+ if (err) {
doorbell->db_status = GUC_DOORBELL_DISABLED;
+ DRM_ERROR("Couldn't create client %u doorbell: %d\n",
+ client->stage_id, err);
+ }
return err;
}
@@ -363,6 +368,8 @@ static void guc_stage_desc_init(struct intel_guc *guc,
memset(desc, 0, sizeof(*desc));
desc->attribute = GUC_STAGE_DESC_ATTR_ACTIVE |
GUC_STAGE_DESC_ATTR_KERNEL;
+ if (is_high_priority(client))
+ desc->attribute |= GUC_STAGE_DESC_ATTR_PREEMPT;
desc->stage_id = client->stage_id;
desc->priority = client->priority;
desc->db_id = client->doorbell_id;
@@ -763,15 +770,13 @@ static int guc_init_doorbell_hw(struct intel_guc *guc)
/* Now for every client (and not only execbuf_client) make sure their
* doorbells are known by the GuC */
- //for (client = client_list; client != NULL; client = client->next)
- {
- ret = __create_doorbell(client);
- if (ret) {
- DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
- client->stage_id, ret);
- return ret;
- }
- }
+ ret = __create_doorbell(guc->execbuf_client);
+ if (ret)
+ return ret;
+
+ ret = __create_doorbell(guc->preempt_client);
+ if (ret)
+ return ret;
/* Read back & verify all (used & unused) doorbell registers */
for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id)
@@ -895,6 +900,49 @@ static void guc_client_free(struct i915_guc_client *client)
kfree(client);
}
+static int guc_clients_create(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct i915_guc_clie
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)
== Series Details == Series: series starting with [1/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects) URL : https://patchwork.freedesktop.org/series/32693/ State : success == Summary == Series 32693v1 series starting with [1/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects) https://patchwork.freedesktop.org/api/1.0/series/32693/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 Test drv_module_reload: Subgroup basic-reload-inject: dmesg-warn -> INCOMPLETE (fi-cfl-s) fdo#103206 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fdo#103206 https://bugs.freedesktop.org/show_bug.cgi?id=103206 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:444s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:459s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:378s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:529s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:264s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:502s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:501s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:495s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:493s fi-cfl-s total:288 pass:253 dwarn:3 dfail:0 fail:0 skip:31 fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:609s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:251s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:577s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:490s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:431s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:429s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:433s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:494s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:493s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:576s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:476s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:584s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:550s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:449s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:594s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:649s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:523s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:502s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:461s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:568s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:421s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest fdb441c3ca25 drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr) bb61f887cb23 drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6203/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Save PM interrupt register offsets in device info
On Thu, 26 Oct 2017, Jani Nikula wrote:
> On Thu, 26 Oct 2017, Tvrtko Ursulin wrote:
>> On 25/10/2017 08:45, Jani Nikula wrote:
>>> On Tue, 24 Oct 2017, Tvrtko Ursulin wrote:
On 24/10/17 18:48, Jani Nikula wrote:
> On Tue, 24 Oct 2017, Chris Wilson wrote:
>> Quoting Sagar Arun Kamble (2017-10-24 11:41:13)
>>> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
>>> b/drivers/gpu/drm/i915/intel_device_info.c
>>> index 875d428..d1a4911 100644
>>> --- a/drivers/gpu/drm/i915/intel_device_info.c
>>> +++ b/drivers/gpu/drm/i915/intel_device_info.c
>>> @@ -462,4 +462,15 @@ void intel_device_info_runtime_init(struct
>>> drm_i915_private *dev_priv)
>>>info->sseu.has_subslice_pg ? "y" : "n");
>>> DRM_DEBUG_DRIVER("has EU power gating: %s\n",
>>>info->sseu.has_eu_pg ? "y" : "n");
>>> +
>>> + /* Initialize PM interrupt register offsets */
>>> + if (INTEL_GEN(dev_priv) >= 8) {
>>> + info->pm_iir_offset = GEN8_GT_IIR(2);
>>> + info->pm_imr_offset = GEN8_GT_IMR(2);
>>> + info->pm_ier_offset = GEN8_GT_IER(2);
>>> + } else {
>>> + info->pm_iir_offset = GEN6_PMIIR;
>>> + info->pm_imr_offset = GEN6_PMIMR;
>>> + info->pm_ier_offset = GEN6_PMIER;
>>> + }
>>
>> If you are going to take another pass at this, move these into the
>> static tables in i915_pci.c
>>
>> Updating GEN6_FEATURES and GEN8_FEATURES will then percolate into
>> individual platform defines.
>
> Like I wrote in reply to v1, I'm not convinced we should do this at all.
>
> What makes *these* registers so important they must be in device info?
> What makes most of i915_reg.h so unimportant they don't deserve the same
> treatment? Where do you draw the line?
>
> I'd draw the line at, no registers at device info.
I suggested to Sagar this change during review so feel responsible to
chime in.
So in general I just find the amount of times our driver asks itself
what it's running on a bit tasteless. :(
I did quick and dirty check by bumping a counter in all the
IS_this|or|that checks, all which can be known at driver probe time, and
wired it up to the PMU so I can check their frequency. The annotated
perf stat output:
root@e31:~# perf stat -a -e i915/whoami/ -I 1000
# time counts unit events
# idle system no X running
1.000298100 10 i915/whoami/
2.000750955 8 i915/whoami/
3.001104193 10 i915/whoami/
4.001333433 10 i915/whoami/
5.001703162 10 i915/whoami/
6.002122721 10 i915/whoami/
# starting X now..
7.002266228 2,203 i915/whoami/
8.002392598 4,682 i915/whoami/
9.002764398 0 i915/whoami/
10.003027119 0 i915/whoami/
11.003486048 42 i915/whoami/
# X idling..
12.003854660 0 i915/whoami/
13.004221680 0 i915/whoami/
14.004622571 0 i915/whoami/
15.004968110 0 i915/whoami/
16.005372363 0 i915/whoami/
17.005778034 0 i915/whoami/
18.005941970 0 i915/whoami/
19.006313427 0 i915/whoami/
20.006676048 0 i915/whoami/
21.007059927 0 i915/whoami/
22.007507818 0 i915/whoami/
23.007887628 0 i915/whoami/
24.008207035 0 i915/whoami/
25.008580496 0 i915/whoami/
# time counts unit events
26.008949236 0 i915/whoami/
27.009433473 0 i915/whoami/
# gfxbench trex starting up
28.009677600 2,605 i915/whoami/
29.009941972716 i915/whoami/
30.010127588 2,190 i915/whoami/
31.010249535 46 i915/whoami/
32.010383565 36 i915/whoami/
33.010527674 0 i915/whoami/
# trex running
>>>
Re: [Intel-gfx] [PATCH] drm/i915: Abandon the reset if we fail to stop the engines
On Thu, Oct 26, 2017 at 02:11:22PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2017-10-26 13:59:05) > > On Thu, Oct 26, 2017 at 01:12:12PM +0100, Chris Wilson wrote: > > > Some machines, *cough* snb *cough*, fail catastrophically if asked to > > > reset the GPU under certain conditions. > > > > Did we try skipping the gen6_rps_disable() already? > > I had thought we had taken that out a while ago... > > commit f2a91d1a6f5960c08f1ca60bd076f4dc020c50c6 > Author: Chris Wilson > Date: Wed Sep 21 14:51:06 2016 +0100 > > drm/i915: Restore current RPS state after reset > > removes the frobbing inside i915_reset() itself, but still talks about > RPS needing to be restored... Ok, that's the post-reset stuff to make > sure that the hw/sw tracking align. Hmm. Right. It looks like we do the disable+re-enable back to back after the reset. I guess at that point it should be safe, assuming the reset actually worked. > > We are not touching rc6/rps prior to hitting GDRST. Maybe we should? Based on what I remember that would be more dangerous if the engined is stuck in a bad way. So I guess these reset problems are something else then. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: Skip tests when PSR cannot be enabled
Em Qua, 2017-10-25 às 17:37 -0700, Dhinakaran Pandiyan escreveu:
> The frontbuffer_tracking PSR tests fail if PSR cannot be activated
> when
> there is sink support. But, there are several other requirements
> related to
> mode timings that have to be satisfied before PSR can be enabled. No
> reason
> to fail these tests when PSR cannot be enabled.
>
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
> ---
> tests/kms_frontbuffer_tracking.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index a068c8af..13c948de 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -1548,12 +1548,12 @@ static void teardown_fbc(void)
> {
> }
>
> -static bool psr_sink_has_support(void)
> +static bool psr_has_support(void)
> {
> char buf[256];
>
> debugfs_read("i915_edp_psr_status", buf);
> - return strstr(buf, "Sink_Support: yes\n");
> + return strstr(buf, "Enabled: yes\n");
What if PSR can be enabled but is just not enabled due to a bug?
I suppose we could print on debugfs whether source+sink support equals
yes.
> }
>
> static void setup_psr(void)
> @@ -1564,8 +1564,8 @@ static void setup_psr(void)
> return;
> }
>
> - if (!psr_sink_has_support()) {
> - igt_info("Can't test PSR: not supported by
> sink.\n");
> + if (!psr_has_support()) {
> + igt_info("Can't test PSR: not supported.\n");
> return;
> }
> psr.can_test = true;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/guc: Add a second client, to be used for preemption
From: Dave Gordon
This second client is created with priority KMD_HIGH, and marked
as preemptive. This will allow us to request preemption using GuC actions.
v2: Extract clients creation into a helper, debugfs fixups. (Michał)
Recreate doorbell on init. (Daniele)
Move clients into an array.
v3: And move clients back from an array, to get rid of the enum (Michał)
v4: Use is_high_priority, move DRM_ERROR into __create_doorbell, move
GEM_BUG_ON inside guc_clients_create (Michał)
v5: Split the BUG_ON (Michał)
Signed-off-by: Dave Gordon
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Jeff McGee
Cc: Michal Wajdeczko
Cc: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +
drivers/gpu/drm/i915/i915_guc_submission.c | 118 -
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 85 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..6e178d75bb17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2484,6 +2484,8 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
+ seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client);
+ i915_guc_client_info(m, dev_priv, guc->preempt_client);
i915_guc_log_info(m, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d1a5613da24c..31c50ad46eb7 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -33,10 +33,11 @@
*
* GuC client:
* A i915_guc_client refers to a submission path through GuC. Currently, there
- * is only one of these (the execbuf_client) and this one is charged with all
- * submissions to the GuC. This struct is the owner of a doorbell, a process
- * descriptor and a workqueue (all of them inside a single gem object that
- * contains all required pages for these elements).
+ * are two clients. One of them (the execbuf_client) is charged with all
+ * submissions to the GuC, the other one (preempt_client) is responsible for
+ * preempting the execbuf_client. This struct is the owner of a doorbell, a
+ * process descriptor and a workqueue (all of them inside a single gem object
+ * that contains all required pages for these elements).
*
* GuC stage descriptor:
* During initialization, the driver allocates a static pool of 1024 such
@@ -83,7 +84,8 @@
static inline bool is_high_priority(struct i915_guc_client* client)
{
- return client->priority <= GUC_CLIENT_PRIORITY_HIGH;
+ return (client->priority == GUC_CLIENT_PRIORITY_KMD_HIGH ||
+ client->priority == GUC_CLIENT_PRIORITY_HIGH);
}
static int __reserve_doorbell(struct i915_guc_client *client)
@@ -196,8 +198,11 @@ static int __create_doorbell(struct i915_guc_client
*client)
doorbell->cookie = 0;
err = __guc_allocate_doorbell(client->guc, client->stage_id);
- if (err)
+ if (err) {
doorbell->db_status = GUC_DOORBELL_DISABLED;
+ DRM_ERROR("Couldn't create client %u doorbell: %d\n",
+ client->stage_id, err);
+ }
return err;
}
@@ -363,6 +368,8 @@ static void guc_stage_desc_init(struct intel_guc *guc,
memset(desc, 0, sizeof(*desc));
desc->attribute = GUC_STAGE_DESC_ATTR_ACTIVE |
GUC_STAGE_DESC_ATTR_KERNEL;
+ if (is_high_priority(client))
+ desc->attribute |= GUC_STAGE_DESC_ATTR_PREEMPT;
desc->stage_id = client->stage_id;
desc->priority = client->priority;
desc->db_id = client->doorbell_id;
@@ -763,15 +770,13 @@ static int guc_init_doorbell_hw(struct intel_guc *guc)
/* Now for every client (and not only execbuf_client) make sure their
* doorbells are known by the GuC */
- //for (client = client_list; client != NULL; client = client->next)
- {
- ret = __create_doorbell(client);
- if (ret) {
- DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
- client->stage_id, ret);
- return ret;
- }
- }
+ ret = __create_doorbell(guc->execbuf_client);
+ if (ret)
+ return ret;
+
+ ret = __create_doorbell(guc->preempt_client);
+ if (ret)
+ return ret;
/* Read back & verify all (used & unused) doorbell registers */
for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id)
@@ -895,6 +900,50 @@ static void guc_client_free(struct i915_guc_client *client)
kfree(client);
}
+static int guc_clients_create(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc
[Intel-gfx] [PATCH v6] drm/i915/guc: Preemption! With GuC
Pretty similar to what we have on execlists.
We're reusing most of the GEM code, however, due to GuC quirks we need a
couple of extra bits.
Preemption is implemented as GuC action, and actions can be pretty slow.
Because of that, we're using a mutex to serialize them. Since we're
requesting preemption from the tasklet, the task of creating a workitem
and wrapping it in GuC action is delegated to a worker.
To distinguish that preemption has finished, we're using additional
piece of HWSP, and since we're not getting context switch interrupts,
we're also adding a user interrupt.
The fact that our special preempt context has completed unfortunately
doesn't mean that we're ready to submit new work. We also need to wait
for GuC to finish its own processing.
v2: Don't compile out the wait for GuC, handle workqueue flush on reset,
no need for ordered workqueue, put on a reviewer hat when looking at my own
patches (Chris)
Move struct work around in intel_guc, move user interruput outside of
conditional (Michał)
Keep ring around rather than chase though intel_context
v3: Extract WA for flushing ggtt writes to a helper (Chris)
Keep work_struct in intel_guc rather than engine (Michał)
Use ordered workqueue for inject_preempt worker to avoid GuC quirks.
v4: Drop now unused INTEL_GUC_PREEMPT_OPTION_IMMEDIATE (Daniele)
Drop stray newlines, use container_of for intel_guc in worker,
check for presence of workqueue when flushing it, rather than
enable_guc_submission modparam, reorder preempt postprocessing (Chris)
v5: Make wq NULL after destroying it
v6: Swap struct guc_preempt_work members (Michał)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jeff McGee
Cc: Joonas Lahtinen
Cc: Oscar Mateo
Cc: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c| 3 +-
drivers/gpu/drm/i915/i915_gem.c| 10 ++
drivers/gpu/drm/i915/i915_guc_submission.c | 208 +++--
drivers/gpu/drm/i915/intel_guc.h | 8 ++
drivers/gpu/drm/i915/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.h | 1 -
drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +
7 files changed, 222 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7b871802ae36..af745749509c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -373,8 +373,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value |= I915_SCHEDULER_CAP_PRIORITY;
if (HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
- i915_modparams.enable_execlists &&
- !i915_modparams.enable_guc_submission)
+ i915_modparams.enable_execlists)
value |= I915_SCHEDULER_CAP_PREEMPTION;
}
break;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d803ef5f4a7f..c2506fb3a483 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2921,6 +2921,16 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
tasklet_kill(&engine->execlists.irq_tasklet);
tasklet_disable(&engine->execlists.irq_tasklet);
+ /*
+* We're using worker to queue preemption requests from the tasklet in
+* GuC submission mode.
+* Even though tasklet was disabled, we may still have a worker queued.
+* Let's make sure that all workers scheduled before disabling the
+* tasklet are completed before continuing with the reset.
+*/
+ if (engine->i915->guc.preempt_wq)
+ flush_workqueue(engine->i915->guc.preempt_wq);
+
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 63641811de46..bf8d1e54aa5c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -565,6 +565,108 @@ static void guc_add_request(struct intel_guc *guc,
spin_unlock(&client->wq_lock);
}
+/*
+ * When we're doing submissions using regular execlists backend, writing to
+ * ELSP from CPU side is enough to make sure that writes to ringbuffer pages
+ * pinned in mappable aperture portion of GGTT are visible to command streamer.
+ * Writes done by GuC on our behalf are not guaranteeing such ordering,
+ * therefore, to ensure the flush, we're issuing a POSTING READ.
+ */
+static void flush_ggtt_writes(struct i915_vma *vma)
+{
+ struct drm_i915_private *dev_priv = to_i915(vma->obj->base.dev);
+
+ if (i915_vma_is_map_and_fenceable(vma))
+ POSTING_READ_FW(GUC_STATUS);
+}
+
+#define GUC_PREEMPT_FINISHED 0x1
+#define GUC_PREEMPT_BREADCRUMB_DWORDS 0x8
+static void inject_preempt_context(struct work_struct *work)
+{
+
[Intel-gfx] ✗ Fi.CI.BAT: warning for Preemption with GuC, fourth try (rev3)
== Series Details == Series: Preemption with GuC, fourth try (rev3) URL : https://patchwork.freedesktop.org/series/32654/ State : warning == Summary == Series 32654v3 Preemption with GuC, fourth try https://patchwork.freedesktop.org/api/1.0/series/32654/revisions/3/mbox/ Test chamelium: Subgroup dp-crc-fast: pass -> FAIL (fi-kbl-7500u) fdo#102514 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-cnl-y) Subgroup basic-no-display: pass -> DMESG-WARN (fi-cnl-y) Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-cnl-y) fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:451s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:369s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:528s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:503s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:502s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:494s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:482s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:552s fi-cnl-y total:289 pass:259 dwarn:3 dfail:0 fail:0 skip:27 time:618s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:418s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:249s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:574s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:487s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:426s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:425s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:434s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:492s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:463s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:480s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:581s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:545s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:659s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:522s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:501s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:456s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:560s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:418s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 3218d17f96a7 HAX Enable GuC Submission for CI a621438797f4 drm/i915/guc: Preemption! With GuC cac38ec21a03 drm/i915: Rename helpers used for unwinding, use macro for can_preempt d8b26d6919a9 drm/i915/guc: Keep request->priority for its lifetime 794b8ad2405a drm/i915: Add information needed to track engine preempt state fd083843a919 drm/i915: Extract "emit write" part of emit breadcrumb functions 5b871dda8364 drm/i915/guc: Split guc_wq_item_append b1bd6d916ab2 drm/i915/guc: Add a second client, to be used for preemption cb79905d0954 drm/i915/guc: Add preemption action to GuC firmware interface 18c35c003dcb drm/i915/guc: Allocate separate shared data object for GuC communication 5bda4fcf07ad drm/i915/guc: Extract GuC stage desc pool creation into a helper 87f3d391fb9f drm/i915/guc: Do not use 0 for GuC doorbell cookie == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Pat
Re: [Intel-gfx] [PATCH v5] drm/i915/guc: Add a second client, to be used for preemption
On Thu, 26 Oct 2017 15:32:31 +0200, Michał Winiarski wrote: From: Dave Gordon This second client is created with priority KMD_HIGH, and marked as preemptive. This will allow us to request preemption using GuC actions. v2: Extract clients creation into a helper, debugfs fixups. (Michał) Recreate doorbell on init. (Daniele) Move clients into an array. v3: And move clients back from an array, to get rid of the enum (Michał) v4: Use is_high_priority, move DRM_ERROR into __create_doorbell, move GEM_BUG_ON inside guc_clients_create (Michał) v5: Split the BUG_ON (Michał) Signed-off-by: Dave Gordon Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Jeff McGee Cc: Michal Wajdeczko Cc: Oscar Mateo --- Reviewed-by: Michal Wajdeczko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Include RING_MODE when dumping the engine state
Chris Wilson writes:
> Knowing the RING_MODE flags is useful for checking the state of the
> engine, such as whether the CS is idle after trying to stop the engines
> before reset.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index fedb839dff61..e676e345c453 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1726,6 +1726,11 @@ void intel_engine_dump(struct intel_engine_cs *engine,
> struct drm_printer *m)
> drm_printf(m, "\tRING_CTL: 0x%08x [%s]\n",
> I915_READ(RING_CTL(engine->mmio_base)),
> I915_READ(RING_CTL(engine->mmio_base)) & (RING_WAIT |
> RING_WAIT_SEMAPHORE) ? "waiting" : "");
> + if (INTEL_GEN(engine->i915) > 2) {
> + drm_printf(m, "\tRING_MODE: 0x%08x [%s]\n",
> +I915_READ(RING_MI_MODE(engine->mmio_base)),
> +I915_READ(RING_MI_MODE(engine->mmio_base)) &
> (MODE_IDLE) ? "idle" : "");
or use "[idle]" and just %s in printf.
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Preemption with GuC, fourth try (rev5)
== Series Details == Series: Preemption with GuC, fourth try (rev5) URL : https://patchwork.freedesktop.org/series/32654/ State : success == Summary == Series 32654v5 Preemption with GuC, fourth try https://patchwork.freedesktop.org/api/1.0/series/32654/revisions/5/mbox/ Test kms_cursor_legacy: Subgroup basic-flip-before-cursor-atomic: pass -> INCOMPLETE (fi-cnl-y) fdo#102035 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-bsw-n3050) fdo#103165 fdo#102035 https://bugs.freedesktop.org/show_bug.cgi?id=102035 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fdo#103165 https://bugs.freedesktop.org/show_bug.cgi?id=103165 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:441s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:453s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:370s fi-bsw-n3050 total:289 pass:242 dwarn:1 dfail:0 fail:0 skip:46 time:520s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:261s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:499s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:500s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:495s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:476s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:554s fi-cnl-y total:289 pass:193 dwarn:0 dfail:0 fail:0 skip:20 fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:417s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:251s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:582s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:488s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:425s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:425s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:433s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:484s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:490s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:573s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:585s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:550s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:597s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:647s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:522s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:502s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:457s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:560s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:413s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 57f4372b843b HAX Enable GuC Submission for CI bd453e53421a drm/i915/guc: Preemption! With GuC c230cfaaeec4 drm/i915: Rename helpers used for unwinding, use macro for can_preempt be74df89d1cb drm/i915/guc: Keep request->priority for its lifetime c65600f6018d drm/i915: Add information needed to track engine preempt state 05053f4249e6 drm/i915: Extract "emit write" part of emit breadcrumb functions 44056d81e278 drm/i915/guc: Split guc_wq_item_append e6230d13d5b1 drm/i915/guc: Add a second client, to be used for preemption 46cdb7035ad8 drm/i915/guc: Add preemption action to GuC firmware interface 05352d789d91 drm/i915/guc: Allocate separate shared data object for GuC communication 79c012264126 drm/i915/guc: Extract GuC stage desc pool creation into a helper a535408d82c7 drm/i915/guc: Do not use 0 for GuC doorbell cookie == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6205/ ___ Intel-gfx mailing list In
[Intel-gfx] [PATCH] drm/i915: Fallback to reserve forcewake if primary ack missing
There is a possibility on gen9 hardware to miss the forcewake ack
message. The recommended workaround is to use another free
bit and toggle it until original bit is successfully acknowledged.
The workaround is a bit misleadingly named as WaRsForcewakeAddDelayForAck.
The reason for naming is most likely that workaround was named before
the most recent recommendation evolved to use the reserve bit.
Some future gen9 revs might or might not fix the underlying issue but
the fallback to reserve bit dance can be considered as harmless:
without the ack timeout we never reach the reserve bit forcewake.
Thus as of now we adopt a blanket approach for all gen9 and leave
the bypassing the reserve bit approach for future patches if
corresponding hw revisions do appear.
Commit 83e3337204b2 ("drm/i915: Increase maximum polling time to 50ms
for forcewake request/clear ack") did increase the forcewake timeout.
If the issue was a delayed ack, future work could include finding
a suitable timeout value both for primary ack and reserve toggle
to reduce the worst case latency.
References: HSDES #1604254524
References: https://bugs.freedesktop.org/show_bug.cgi?id=102051
Cc: Chris Wilson
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 5 +-
drivers/gpu/drm/i915/intel_uncore.c | 112 +---
2 files changed, 108 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f138eae82bf0..c04c634af5ae 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7774,8 +7774,9 @@ enum {
#define FORCEWAKE_ACK_MEDIA_GEN9 _MMIO(0x0D88)
#define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0x0D84)
#define FORCEWAKE_ACK_BLITTER_GEN9_MMIO(0x130044)
-#define FORCEWAKE_KERNEL 0x1
-#define FORCEWAKE_USER 0x2
+#define FORCEWAKE_KERNEL BIT(0)
+#define FORCEWAKE_USER BIT(1)
+#define FORCEWAKE_RESERVEBIT(12)
#define FORCEWAKE_MT_ACK _MMIO(0x130040)
#define ECOBUS_MMIO(0xa180)
#defineFORCEWAKE_MT_ENABLE (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 20e3c65c0999..fc6d090244c5 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -69,17 +69,80 @@ fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
HRTIMER_MODE_REL);
}
+static inline bool
+wait_ack_clear(const struct drm_i915_private *i915,
+ const struct intel_uncore_forcewake_domain *d,
+ const u32 ack)
+{
+ return wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) & ack) == 0,
+ FORCEWAKE_ACK_TIMEOUT_MS);
+}
+
+static inline bool
+wait_ack_set(const struct drm_i915_private *i915,
+const struct intel_uncore_forcewake_domain *d,
+const u32 ack)
+{
+ return wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) & ack),
+ FORCEWAKE_ACK_TIMEOUT_MS);
+}
+
static inline void
fw_domain_wait_ack_clear(const struct drm_i915_private *i915,
const struct intel_uncore_forcewake_domain *d)
{
- if (wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) &
-FORCEWAKE_KERNEL) == 0,
- FORCEWAKE_ACK_TIMEOUT_MS))
+ if (wait_ack_clear(i915, d, FORCEWAKE_KERNEL))
DRM_ERROR("%s: timed out waiting for forcewake ack to clear.\n",
intel_uncore_forcewake_domain_to_str(d->id));
}
+enum ack_type {
+ ACK_CLEAR = 0,
+ ACK_SET
+};
+
+static bool
+fw_domain_reserve_fallback(const struct drm_i915_private *i915,
+ const struct intel_uncore_forcewake_domain *d,
+ const enum ack_type type)
+{
+ bool timeout;
+ int retry = 10;
+
+ /* Fallback to toggle another fw bit to wake up the gpu */
+ do {
+ wait_ack_clear(i915, d, FORCEWAKE_RESERVE);
+ __raw_i915_write32(i915, d->reg_set,
+ _MASKED_BIT_ENABLE(FORCEWAKE_RESERVE));
+ wait_ack_set(i915, d, FORCEWAKE_RESERVE);
+
+ if (type == ACK_CLEAR)
+ timeout = wait_ack_clear(i915, d, FORCEWAKE_KERNEL);
+ else
+ timeout = wait_ack_set(i915, d, FORCEWAKE_KERNEL);
+
+ __raw_i915_write32(i915, d->reg_set,
+ _MASKED_BIT_DISABLE(FORCEWAKE_RESERVE));
+ } while (timeout && --retry);
+
+ return timeout;
+}
+
+static inline void
+fw_domain_wait_ack_clear_reserve(const struct drm_i915_priva
[Intel-gfx] [PATCH v6] drm/i915/guc: Add a second client, to be used for preemption
From: Dave Gordon
This second client is created with priority KMD_HIGH, and marked
as preemptive. This will allow us to request preemption using GuC actions.
v2: Extract clients creation into a helper, debugfs fixups. (Michał)
Recreate doorbell on init. (Daniele)
Move clients into an array.
v3: And move clients back from an array, to get rid of the enum (Michał)
v4: Use is_high_priority, move DRM_ERROR into __create_doorbell, move
GEM_BUG_ON inside guc_clients_create (Michał)
v5: Split the BUG_ON (Michał)
v6: Cleanup after error during doorbell reinit (Michał)
Signed-off-by: Dave Gordon
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Jeff McGee
Cc: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +
drivers/gpu/drm/i915/i915_guc_submission.c | 118 -
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 86 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..6e178d75bb17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2484,6 +2484,8 @@ static int i915_guc_info(struct seq_file *m, void *data)
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
+ seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client);
+ i915_guc_client_info(m, dev_priv, guc->preempt_client);
i915_guc_log_info(m, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d1a5613da24c..b0f034f92431 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -33,10 +33,11 @@
*
* GuC client:
* A i915_guc_client refers to a submission path through GuC. Currently, there
- * is only one of these (the execbuf_client) and this one is charged with all
- * submissions to the GuC. This struct is the owner of a doorbell, a process
- * descriptor and a workqueue (all of them inside a single gem object that
- * contains all required pages for these elements).
+ * are two clients. One of them (the execbuf_client) is charged with all
+ * submissions to the GuC, the other one (preempt_client) is responsible for
+ * preempting the execbuf_client. This struct is the owner of a doorbell, a
+ * process descriptor and a workqueue (all of them inside a single gem object
+ * that contains all required pages for these elements).
*
* GuC stage descriptor:
* During initialization, the driver allocates a static pool of 1024 such
@@ -83,7 +84,8 @@
static inline bool is_high_priority(struct i915_guc_client* client)
{
- return client->priority <= GUC_CLIENT_PRIORITY_HIGH;
+ return (client->priority == GUC_CLIENT_PRIORITY_KMD_HIGH ||
+ client->priority == GUC_CLIENT_PRIORITY_HIGH);
}
static int __reserve_doorbell(struct i915_guc_client *client)
@@ -196,8 +198,11 @@ static int __create_doorbell(struct i915_guc_client
*client)
doorbell->cookie = 0;
err = __guc_allocate_doorbell(client->guc, client->stage_id);
- if (err)
+ if (err) {
doorbell->db_status = GUC_DOORBELL_DISABLED;
+ DRM_ERROR("Couldn't create client %u doorbell: %d\n",
+ client->stage_id, err);
+ }
return err;
}
@@ -363,6 +368,8 @@ static void guc_stage_desc_init(struct intel_guc *guc,
memset(desc, 0, sizeof(*desc));
desc->attribute = GUC_STAGE_DESC_ATTR_ACTIVE |
GUC_STAGE_DESC_ATTR_KERNEL;
+ if (is_high_priority(client))
+ desc->attribute |= GUC_STAGE_DESC_ATTR_PREEMPT;
desc->stage_id = client->stage_id;
desc->priority = client->priority;
desc->db_id = client->doorbell_id;
@@ -763,14 +770,14 @@ static int guc_init_doorbell_hw(struct intel_guc *guc)
/* Now for every client (and not only execbuf_client) make sure their
* doorbells are known by the GuC */
- //for (client = client_list; client != NULL; client = client->next)
- {
- ret = __create_doorbell(client);
- if (ret) {
- DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
- client->stage_id, ret);
- return ret;
- }
+ ret = __create_doorbell(guc->execbuf_client);
+ if (ret)
+ return ret;
+
+ ret = __create_doorbell(guc->preempt_client);
+ if (ret) {
+ __destroy_doorbell(guc->execbuf_client);
+ return ret;
}
/* Read back & verify all (used & unused) doorbell registers */
@@ -895,6 +902,50 @@ static void guc_client_free(struct i915_guc_client *client)
kfree(client);
}
+static int guc_clients_creat
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fallback to reserve forcewake if primary ack missing
== Series Details == Series: drm/i915: Fallback to reserve forcewake if primary ack missing URL : https://patchwork.freedesktop.org/series/32694/ State : failure == Summary == Series 32694v1 drm/i915: Fallback to reserve forcewake if primary ack missing https://patchwork.freedesktop.org/api/1.0/series/32694/revisions/1/mbox/ Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-WARN (fi-bdw-5557u) fdo#102473 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 pass -> INCOMPLETE (fi-cnl-y) fdo#102473 https://bugs.freedesktop.org/show_bug.cgi?id=102473 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:267 dwarn:1 dfail:0 fail:0 skip:21 time:443s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:454s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:368s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:517s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:495s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:493s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:484s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:548s fi-cnl-y total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:24 fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:412s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:251s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:586s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:485s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:431s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:425s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:429s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:491s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:568s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:476s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:584s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:586s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:649s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:521s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:504s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:455s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:559s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:418s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 85d6d3a5e337 drm/i915: Fallback to reserve forcewake if primary ack missing == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6206/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/edp: read edp display control registers unconditionally
Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
DP_EDP_CONFIGURATION_CAP should be set if the eDP display control
registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we
check the bit before reading the registers, and DP_EDP_DPCD_REV is the
only way to detect eDP revision.
Turns out there are (likely buggy) displays that require eDP 1.4+
features, such as supported link rates and link rate select, but do not
have the bit set. Read the display control registers
unconditionally. They are supposed to read zero anyway if they are not
supported, so there should be no harm in this.
This fixes the referenced bug by enabling the eDP version check, and
thus reading of the supported link rates. The panel in question has 0 in
DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the
supported link rates method we default to RBR which is insufficient for
the panel native mode. As a curiosity, the panel also has a bogus value
of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14
(which is 0x03).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400
Reported-and-tested-by: Nicolas P.
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aa75f55eeb61..158438bb0389 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3735,9 +3735,16 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
}
- /* Read the eDP Display control capabilities registers */
- if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
- drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
+ /*
+* Read the eDP display control registers.
+*
+* Do this independent of DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
+* DP_EDP_CONFIGURATION_CAP, because some buggy displays do not have it
+* set, but require eDP 1.4+ detection (e.g. for supported link rates
+* method). The display control registers should read zero if they're
+* not supported anyway.
+*/
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
sizeof(intel_dp->edp_dpcd))
DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int)
sizeof(intel_dp->edp_dpcd),
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/edp: clean up code and comments around eDP DPCD read
Some minor drive-by cleanups.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 158438bb0389..73b1ed8cff6b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3747,11 +3747,11 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
sizeof(intel_dp->edp_dpcd))
- DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int)
sizeof(intel_dp->edp_dpcd),
+ DRM_DEBUG_KMS("eDP DPCD: %*ph\n", (int)
sizeof(intel_dp->edp_dpcd),
intel_dp->edp_dpcd);
- /* Intermediate frequency support */
- if (intel_dp->edp_dpcd[0] >= 0x03) { /* eDp v1.4 or higher */
+ /* Read the eDP 1.4+ supported link rates. */
+ if (intel_dp->edp_dpcd[0] >= DP_EDP_14) {
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
@@ -3775,6 +3775,10 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
intel_dp->num_sink_rates = i;
}
+ /*
+* Use DP_LINK_RATE_SET if DP_SUPPORTED_LINK_RATES are available,
+* default to DP_MAX_LINK_RATE and DP_LINK_BW_SET otherwise.
+*/
if (intel_dp->num_sink_rates)
intel_dp->use_rate_select = true;
else
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix SSEU Device Status.
Since I've been looking at EU_DISABLE* in intel_device_info.c, your
patch caught my eye :)
Reading the documentation I couldn't find anything wrong.
Reviewed-by: Lionel Landwerlin
On 26/10/17 01:15, Rodrigo Vivi wrote:
CNL adds an extra register for slice/subslice information.
Although no SKU is planed with an extra slice let's already
handle this extra piece of information so we don't have the
risk in future of getting a part that might have chosen this
part of the die instead of other slices or anything like that.
Also if subslice is disabled the information of eu ack for that
is garbage, so let's skip checks for eu if subslice is disabled
as we skip the subslice if slice is disabled.
The rest is pretty much like gen9.
v2: Remove IS_CANNONLAKE from gen9 status function.
v3: Consider s_max = 6 and ss_max=4 to run over all possible
slices and subslices possible by spec. Although no real
hardware will have that many slices/subslices.
To match with sseu info init.
v4: Fix offset calculation for slices 4 and 5.
Removed Oscar's rv-b since this change also needs review.
v5: Let's consider only valid bits for SLICE*_PGCTL_ACK.
This looks like wrong in Spec, but seems to be enough
for now. Whenever Spec gets updated and fixed we come
back and properly update the masks. Also add a FIXME,
so we can revisit this later when we find some strange
info on debugfs or when we noitce spec got updated.
Cc: Oscar Mateo
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 61 +++--
drivers/gpu/drm/i915/i915_reg.h | 7 +
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..61c466ff87e0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4448,6 +4448,61 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
}
}
+static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
+struct sseu_dev_info *sseu)
+{
+ const struct intel_device_info *info = INTEL_INFO(dev_priv);
+ int s_max = 6, ss_max = 4;
+ int s, ss;
+ u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+
+ for (s = 0; s < s_max; s++) {
+ /*
+* FIXME: Valid SS Mask respects the spec and read
+* only valid bits for those registers, excluding reserverd
+* although this seems wrong becuase it would leave many
+* subslices without ACK.
+*/
+ s_reg[s] = I915_READ(GEN10_SLICE_PGCTL_ACK(s)) &
+ GEN10_PGCTL_VALID_SS_MASK(s);
+ eu_reg[2 * s] = I915_READ(GEN10_SS01_EU_PGCTL_ACK(s));
+ eu_reg[2 * s + 1] = I915_READ(GEN10_SS23_EU_PGCTL_ACK(s));
+ }
+
+ eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
+GEN9_PGCTL_SSA_EU19_ACK |
+GEN9_PGCTL_SSA_EU210_ACK |
+GEN9_PGCTL_SSA_EU311_ACK;
+ eu_mask[1] = GEN9_PGCTL_SSB_EU08_ACK |
+GEN9_PGCTL_SSB_EU19_ACK |
+GEN9_PGCTL_SSB_EU210_ACK |
+GEN9_PGCTL_SSB_EU311_ACK;
+
+ for (s = 0; s < s_max; s++) {
+ if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
+ /* skip disabled slice */
+ continue;
+
+ sseu->slice_mask |= BIT(s);
+ sseu->subslice_mask = info->sseu.subslice_mask;
+
+ for (ss = 0; ss < ss_max; ss++) {
+ unsigned int eu_cnt;
+
+ if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
+ /* skip disabled subslice */
+ continue;
+
+ eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] &
+ eu_mask[ss % 2]);
+ sseu->eu_total += eu_cnt;
+ sseu->eu_per_subslice = max_t(unsigned int,
+ sseu->eu_per_subslice,
+ eu_cnt);
+ }
+ }
+}
+
static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
@@ -4483,7 +4538,7 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
- if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv))
+ if (IS_GEN9_BC(dev_priv))
sseu->subslice_mask =
INTEL_INFO(dev_priv)->sseu.subslice_mask;
@@ -4589,8 +4644,10 @@ static int i915_sseu_status(struct seq_file *m, void *unused)
cherryview_sseu_device_status(dev_priv, &sseu);
} else if (I
Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6
On Thu, 2017-10-26 at 11:32 +0100, Chris Wilson wrote:
> It has been many years since the last confirmed sighting (and fix) of an
> RC6 related bug (usually a system hang). Remove the parameter to stop
> users from setting dangerous values, as they often set it during triage
> and end up disabling the entire runtime pm instead (the option is not a
> fine scalpel!).
>
> Furthermore, it allows users to set known dangerous values which were
> intended for testing and not for production use. For testing, we can
> always patch in the required setting without having to expose ourselves
> to random abuse.
>
> v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the
> lack of ilk support better.
> v3: Clear intel_info->rc6p if we don't support rc6 itself.
>
> Signed-off-by: Chris Wilson
> Cc: Rodrigo Vivi
> Cc: Joonas Lahtinen
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Daniel Vetter
> Acked-by: Daniel Vetter
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3193,6 +3193,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define HAS_PSR(dev_priv) ((dev_priv)->info.has_psr)
> #define HAS_RC6(dev_priv) ((dev_priv)->info.has_rc6)
> #define HAS_RC6p(dev_priv)((dev_priv)->info.has_rc6p)
> +#define HAS_RC6pp(dev_priv) (false)
Slap a comment at the end.
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -216,6 +216,9 @@ static const struct intel_device_info intel_gm45_info
> __initconst = {
> static const struct intel_device_info intel_ironlake_d_info __initconst = {
> GEN5_FEATURES,
> .platform = INTEL_IRONLAKE,
> + /* ilk does support rc6, but we do not implement [power] contexts */
> + .has_rc6 = 0,
> +
Extra newline.
> - if (IS_IVYBRIDGE(dev_priv))
> - return (INTEL_RC6_ENABLE | INTEL_RC6p_ENABLE);
> + /*
> + * We assume that we do not have any deep rc6 levels if we don't have
> + * have the previous rc6 level supporteditself, i.e. we use HAS_RC6()
"supported itself"
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fallback to reserve forcewake if primary ack missing
Quoting Mika Kuoppala (2017-10-26 15:01:44)
> There is a possibility on gen9 hardware to miss the forcewake ack
> message. The recommended workaround is to use another free
> bit and toggle it until original bit is successfully acknowledged.
>
> The workaround is a bit misleadingly named as WaRsForcewakeAddDelayForAck.
> The reason for naming is most likely that workaround was named before
> the most recent recommendation evolved to use the reserve bit.
>
> Some future gen9 revs might or might not fix the underlying issue but
> the fallback to reserve bit dance can be considered as harmless:
> without the ack timeout we never reach the reserve bit forcewake.
> Thus as of now we adopt a blanket approach for all gen9 and leave
> the bypassing the reserve bit approach for future patches if
> corresponding hw revisions do appear.
>
> Commit 83e3337204b2 ("drm/i915: Increase maximum polling time to 50ms
> for forcewake request/clear ack") did increase the forcewake timeout.
> If the issue was a delayed ack, future work could include finding
> a suitable timeout value both for primary ack and reserve toggle
> to reduce the worst case latency.
>
> References: HSDES #1604254524
> References: https://bugs.freedesktop.org/show_bug.cgi?id=102051
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: Sagar Arun Kamble
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +-
> drivers/gpu/drm/i915/intel_uncore.c | 112
> +---
> 2 files changed, 108 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f138eae82bf0..c04c634af5ae 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7774,8 +7774,9 @@ enum {
> #define FORCEWAKE_ACK_MEDIA_GEN9 _MMIO(0x0D88)
> #define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0x0D84)
> #define FORCEWAKE_ACK_BLITTER_GEN9_MMIO(0x130044)
> -#define FORCEWAKE_KERNEL 0x1
> -#define FORCEWAKE_USER 0x2
> +#define FORCEWAKE_KERNEL BIT(0)
> +#define FORCEWAKE_USER BIT(1)
> +#define FORCEWAKE_RESERVEBIT(12)
Why 12? How about 15?
FORCEWAKE_KERNEL2 or FORCEWAKE_KERNEL_FALLBACK
Reserved tends to imply future hw bits. So I think s/reserve/fallback/
works throughout the patch.
> #define FORCEWAKE_MT_ACK _MMIO(0x130040)
> #define ECOBUS_MMIO(0xa180)
> #defineFORCEWAKE_MT_ENABLE (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 20e3c65c0999..fc6d090244c5 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -69,17 +69,80 @@ fw_domain_arm_timer(struct intel_uncore_forcewake_domain
> *d)
>HRTIMER_MODE_REL);
> }
>
> +static inline bool
> +wait_ack_clear(const struct drm_i915_private *i915,
> + const struct intel_uncore_forcewake_domain *d,
> + const u32 ack)
> +{
> + return wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) & ack) ==
> 0,
> + FORCEWAKE_ACK_TIMEOUT_MS);
> +}
> +
> +static inline bool
> +wait_ack_set(const struct drm_i915_private *i915,
> +const struct intel_uncore_forcewake_domain *d,
> +const u32 ack)
> +{
> + return wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) & ack),
> + FORCEWAKE_ACK_TIMEOUT_MS);
> +}
Let's make these one function, to cut down on the wait_for() expansions.
Keeping the wait_ack_clear/wait_ack_set wrappers.
static inline int
__wait_for_ack(i915, d, ack, value)
{
return wait_for_atomic(((__raw_i915_read32(i915, d->reg_ack) & ack)) ==
value,
FORCEWAKE_ACK_TIMEOUT_MS);
}
static inline int wait_ack_clear() { return __wait_for_ack(i915, d, ack, 0));
static inline int wait_ack_set() { return __wait_for_ack(i915, d, ack, ack));
> static inline void
> fw_domain_wait_ack_clear(const struct drm_i915_private *i915,
> const struct intel_uncore_forcewake_domain *d)
> {
> - if (wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) &
> -FORCEWAKE_KERNEL) == 0,
> - FORCEWAKE_ACK_TIMEOUT_MS))
> + if (wait_ack_clear(i915, d, FORCEWAKE_KERNEL))
> DRM_ERROR("%s: timed out waiting for forcewake ack to
> clear.\n",
> intel_uncore_forcewake_domain_to_str(d->id));
> }
>
> +enum ack_type {
> + ACK_CLEAR = 0,
> + ACK_SET
> +};
> +
> +static bool
> +fw_domain_reserve_fallback(const struct drm_i915_private *i915,
> + const struct intel_uncore_forcewake_domain *d,
> +
Re: [Intel-gfx] [PATCH] drm/i915: Add -Wall -Wextra to our build, set warnings to full
On Tue, 24 Oct 2017, Chris Wilson wrote: > Recently W=1 on gcc-7.2 (-Wunused-const-variable) caught a regression > that had been lurking for 6 months, so lets try enabling the full set of > warnings for CI builds. This means more patches will be rejected early > that contain trivial and sometimes not so trivial bugs. However, our > code does not yet compile cleanly with W=1, so we have to apply a filter > to the set of warnings until we can eliminate the mistakes. It also > means that developers will have to be running the full gamut of gcc to > ensure that as warnings come and go with gcc updates, we have the CI > build prepared. > > v2: Use fine-grained -Wno overrides. Inside the makefile, we can > specify CFLAGS on a per-object level, which allows us to limit the scope > of any particular warning override. > v3: Place per-file overrides after the main enabling block. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Jani Nikula > Cc: Daniel Vetter > Cc: Tomi Sarvela > Cc: Michal Wajdeczko > Cc: Ville Syrjälä > Acked-by: Tomi Sarvela > Reviewed-by: Joonas Lahtinen > --- > Seeking more acks for making our lives harder by giving gcc free reign > in its warnings. Acked-by: Jani Nikula > -Chris > --- > drivers/gpu/drm/i915/Makefile | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 6c3b0481ef82..7750be8e27a6 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -2,7 +2,26 @@ > # Makefile for the drm device driver. This driver provides support for the > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > -subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror > +# Add a set of useful warning flags and enable -Werror for CI to prevent > +# trivial mistakes from creeping in. We have to do this piecemeal as we > reject > +# any patch that isn't warning clean, so turning on -Wall -Wextra (or W=1) we > +# need to filter out dubious warnings. Still it is our interest > +# to keep running locally with W=1 C=1 until we are completely clean. > +# > +# Note the danger in using -Wall -Wextra is that when CI updates gcc we > +# will most likely get a sudden build breakage... Hopefully we will fix > +# new warnings before CI updates! > +subdir-ccflags-y := -Wall -Wextra > +subdir-ccflags-y += $(call cc-option,-Wno-unused-parameter,) > +subdir-ccflags-y += $(call cc-option,-Wno-type-limits,) > +subdir-ccflags-y += $(call cc-option,-Wno-missing-field-initializers,) > +subdir-ccflags-y += $(call cc-option,-Wno-implicit-fallthrough,) > +subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror > + > +# Fine grained warnings disable > +CFLAGS_i915_pci.o = $(call cc-option,-Wno-override-init,) > +CFLAGS_intel_fbdev.o = $(call cc-option,-Wno-override-init,) > + > subdir-ccflags-y += \ > $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA) -- 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: warning for Preemption with GuC, fourth try (rev6)
== Series Details == Series: Preemption with GuC, fourth try (rev6) URL : https://patchwork.freedesktop.org/series/32654/ State : warning == Summary == Series 32654v6 Preemption with GuC, fourth try https://patchwork.freedesktop.org/api/1.0/series/32654/revisions/6/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-cnl-y) Subgroup basic-no-display: dmesg-warn -> INCOMPLETE (fi-cfl-s) fdo#103206 pass -> DMESG-WARN (fi-cnl-y) Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-cnl-y) fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fdo#103206 https://bugs.freedesktop.org/show_bug.cgi?id=103206 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:445s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:455s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:370s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:525s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:504s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:498s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:490s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:482s fi-cfl-s total:287 pass:253 dwarn:2 dfail:0 fail:0 skip:31 fi-cnl-y total:289 pass:259 dwarn:3 dfail:0 fail:0 skip:27 time:606s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:418s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:250s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:575s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:483s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:424s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:428s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:434s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:455s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:491s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:572s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:485s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:586s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:541s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:449s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:598s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:648s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:523s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:496s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:461s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:561s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:420s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 7172b849c490 HAX Enable GuC Submission for CI 996b8a088c11 drm/i915/guc: Preemption! With GuC 7bebd9377fe5 drm/i915: Rename helpers used for unwinding, use macro for can_preempt c358e5f30565 drm/i915/guc: Keep request->priority for its lifetime 815b33b8e308 drm/i915: Add information needed to track engine preempt state 364832f82afd drm/i915: Extract "emit write" part of emit breadcrumb functions 274c59afc863 drm/i915/guc: Split guc_wq_item_append ea7d6bdcc394 drm/i915/guc: Add a second client, to be used for preemption 2de790e9c225 drm/i915/guc: Add preemption action to GuC firmware interface 881c8236e90b drm/i915/guc: Allocate separate shared data object for GuC communication db5247f8c3a1 drm/i915/guc: Extract GuC stage desc pool creation into a helper ae0602d37052 drm/i915/guc: Do not use 0 for GuC doorbell cookie == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6207/ ___
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Include RING_MODE when dumping the engine state
== Series Details == Series: drm/i915: Include RING_MODE when dumping the engine state URL : https://patchwork.freedesktop.org/series/32691/ State : success == Summary == Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-B: dmesg-warn -> PASS (shard-hsw) fdo#102249 fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 shard-hswtotal:2539 pass:1434 dwarn:0 dfail:0 fail:8 skip:1097 time:9183s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6201/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/edp: read edp display control registers unconditionally
On Thu, Oct 26, 2017 at 05:29:31PM +0300, Jani Nikula wrote:
> Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
> DP_EDP_CONFIGURATION_CAP should be set if the eDP display control
> registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we
> check the bit before reading the registers, and DP_EDP_DPCD_REV is the
> only way to detect eDP revision.
>
> Turns out there are (likely buggy) displays that require eDP 1.4+
> features, such as supported link rates and link rate select, but do not
> have the bit set. Read the display control registers
> unconditionally. They are supposed to read zero anyway if they are not
> supported, so there should be no harm in this.
>
> This fixes the referenced bug by enabling the eDP version check, and
> thus reading of the supported link rates. The panel in question has 0 in
> DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the
> supported link rates method we default to RBR which is insufficient for
> the panel native mode. As a curiosity, the panel also has a bogus value
> of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14
> (which is 0x03).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400
> Reported-and-tested-by: Nicolas P.
> Cc: Ville Syrjälä
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula
Series is
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index aa75f55eeb61..158438bb0389 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3735,9 +3735,16 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>
> }
>
> - /* Read the eDP Display control capabilities registers */
> - if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
> DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
> - drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
> + /*
> + * Read the eDP display control registers.
> + *
> + * Do this independent of DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
> + * DP_EDP_CONFIGURATION_CAP, because some buggy displays do not have it
> + * set, but require eDP 1.4+ detection (e.g. for supported link rates
> + * method). The display control registers should read zero if they're
> + * not supported anyway.
> + */
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
>intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
>sizeof(intel_dp->edp_dpcd))
> DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int)
> sizeof(intel_dp->edp_dpcd),
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for lib/igt_debugfs: Remove support for legacy CRC api.
== Series Details == Series: lib/igt_debugfs: Remove support for legacy CRC api. URL : https://patchwork.freedesktop.org/series/32689/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-B: dmesg-warn -> PASS (shard-hsw) fdo#102249 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2539 pass:1433 dwarn:0 dfail:0 fail:9 skip:1097 time:9221s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_427/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)
== Series Details == Series: series starting with [1/2] drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects) URL : https://patchwork.freedesktop.org/series/32693/ State : warning == Summary == Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-C: pass -> DMESG-WARN (shard-hsw) fdo#102249 +1 Subgroup extended-modeset-hang-newfb-with-reset-render-B: pass -> DMESG-WARN (shard-hsw) fdo#103038 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) Test kms_cursor_legacy: Subgroup short-flip-after-cursor-atomic-transitions: pass -> SKIP (shard-hsw) fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2539 pass:1430 dwarn:2 dfail:0 fail:9 skip:1098 time:9123s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6203/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/edp: read edp display control registers unconditionally
== Series Details == Series: series starting with [1/2] drm/i915/edp: read edp display control registers unconditionally URL : https://patchwork.freedesktop.org/series/32695/ State : success == Summary == Series 32695v1 series starting with [1/2] drm/i915/edp: read edp display control registers unconditionally https://patchwork.freedesktop.org/api/1.0/series/32695/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:455s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:372s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:516s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:491s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:501s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:483s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:553s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:608s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:416s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:250s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:581s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:484s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:429s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:427s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:500s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:461s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:571s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:481s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:582s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:552s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:447s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:646s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:497s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:449s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:556s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:416s fi-skl-6600u failed to connect after reboot fi-skl-6700k failed to connect after reboot df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest fdd2aab8a5c7 drm/i915/edp: clean up code and comments around eDP DPCD read 02c64917b339 drm/i915/edp: read edp display control registers unconditionally == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6208/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Parse max HDMI TMDS clock from VBT
From: Ville Syrjälä
Starting from version 204 VBT can specify the max TMDS clock we are
allowed to use with HDMI ports. Parse that information and take it
into account when filtering modes and computing a crtc state.
Also take the opportunity to sort the platform check if ladder
from new to old.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_bios.c | 20
drivers/gpu/drm/i915/intel_hdmi.c | 30 --
3 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 366ba74b0ad2..45d32a95ce4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1698,6 +1698,8 @@ enum modeset_restore {
#define DDC_PIN_D 0x06
struct ddi_vbt_port_info {
+ int max_tmds_clock;
+
/*
* This is an index in the HDMI/DVI DDI buffer translation table.
* The special value HDMI_LEVEL_SHIFT_UNKNOWN means the VBT didn't
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index fd23023df7c1..a0df8e3fefbe 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1234,6 +1234,26 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
info->hdmi_level_shift = hdmi_level_shift;
}
+ if (bdb_version >= 204) {
+ int max_tmds_clock;
+
+ switch (child->hdmi_max_data_rate) {
+ case 1:
+ max_tmds_clock = 297000;
+ break;
+ case 2:
+ max_tmds_clock = 165000;
+ break;
+ default:
+ max_tmds_clock = 0;
+ break;
+ }
+
+ DRM_DEBUG_KMS("VBT HDMI max TMDS clock for port %c: %d kHz\n",
+ port_name(port), max_tmds_clock);
+ info->max_tmds_clock = max_tmds_clock;
+ }
+
/* Parse the I_boost config for SKL and above */
if (bdb_version >= 196 && child->iboost) {
info->dp_boost_level = translate_iboost(child->dp_iboost_level);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index aa486b8925cf..38fe24565b4d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1224,24 +1224,34 @@ static void pch_post_disable_hdmi(struct intel_encoder
*encoder,
intel_disable_hdmi(encoder, old_crtc_state, old_conn_state);
}
-static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private *dev_priv)
+static int intel_hdmi_source_max_tmds_clock(struct intel_encoder *encoder)
{
- if (IS_G4X(dev_priv))
- return 165000;
- else if (IS_GEMINILAKE(dev_priv))
- return 594000;
- else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
- return 30;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ const struct ddi_vbt_port_info *info =
+ &dev_priv->vbt.ddi_port_info[encoder->port];
+ int max_tmds_clock;
+
+ if (IS_GEMINILAKE(dev_priv))
+ max_tmds_clock = 594000;
+ else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
+ max_tmds_clock = 30;
+ else if (INTEL_GEN(dev_priv) >= 5)
+ max_tmds_clock = 225000;
else
- return 225000;
+ max_tmds_clock = 165000;
+
+ if (info->max_tmds_clock)
+ max_tmds_clock = min(max_tmds_clock, info->max_tmds_clock);
+
+ return max_tmds_clock;
}
static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
bool respect_downstream_limits,
bool force_dvi)
{
- struct drm_device *dev = intel_hdmi_to_dev(hdmi);
- int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
+ struct intel_encoder *encoder = &hdmi_to_dig_port(hdmi)->base;
+ int max_tmds_clock = intel_hdmi_source_max_tmds_clock(encoder);
if (respect_downstream_limits) {
struct intel_connector *connector = hdmi->attached_connector;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible()
From: Ville Syrjälä
Move the crtc state related 12bpc checks into hdmi_12bpc_possible()
since that one already examines other parts of the crtc state.
Note that we can drop the !force_dvi check since
crtc_state->has_hdmi_sink already accounts for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_hdmi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5132dc814788..aa486b8925cf 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1336,6 +1336,12 @@ static bool hdmi_12bpc_possible(const struct
intel_crtc_state *crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
+ if (crtc_state->pipe_bpp <= 8*3)
+ return false;
+
+ if (!crtc_state->has_hdmi_sink)
+ return false;
+
/*
* HDMI 12bpc affects the clocks, so it's only possible
* when not cloning with other encoder types.
@@ -1461,9 +1467,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
* outputs. We also need to check that the higher clock still fits
* within limits.
*/
- if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
!force_dvi &&
- hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true, force_dvi) ==
MODE_OK &&
- hdmi_12bpc_possible(pipe_config)) {
+ if (hdmi_12bpc_possible(pipe_config) &&
+ hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true, force_dvi) ==
MODE_OK) {
DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
desired_bpp = 12*3;
--
2.13.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Preemption with GuC, fourth try (rev5)
== Series Details == Series: Preemption with GuC, fourth try (rev5) URL : https://patchwork.freedesktop.org/series/32654/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-A: pass -> DMESG-WARN (shard-hsw) fdo#102249 +1 Subgroup extended-modeset-hang-newfb-with-reset-render-B: pass -> DMESG-WARN (shard-hsw) fdo#103038 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) Test kms_flip: Subgroup dpms-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) fdo#103060 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2539 pass:1430 dwarn:2 dfail:0 fail:10 skip:1097 time:9281s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6205/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears:~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson
Once-upon-a-time-Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 44 +---
drivers/gpu/drm/i915/i915_drv.h | 2 -
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 39 +--
drivers/gpu/drm/i915/intel_engine_cs.c | 12 -
drivers/gpu/drm/i915/intel_hangcheck.c | 44 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 431 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 25 +-
8 files changed, 89 insertions(+), 510 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..a0c2d28a42a4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3283,44 +3283,12 @@ static int i915_semaphore_status(struct seq_file *m,
void *unused)
return ret;
intel_runtime_pm_get(dev_priv);
- if (IS_BROADWELL(dev_priv)) {
- struct page *page;
- uint64_t *seqno;
-
- page = i915_gem_object_get_page(dev_priv->semaphore->obj, 0);
-
- seqno = (uint64_t *)kmap_atomic(page);
- for_each_engine(engine, dev_priv, id) {
- uint64_t offset;
-
- seq_printf(m, "%s\n", engine->name);
-
- seq_puts(m, " Last signal:");
- for (j = 0; j < num_rings; j++) {
- offset = id * I915_NUM_ENGINES + j;
- seq_printf(m, "0x%08llx (0x%02llx) ",
- seqno[offset], offset * 8);
- }
- seq_putc(m, '\n');
-
- seq_puts(m, " Last wait: ");
- for (j = 0; j < num_rings; j++) {
- offset = id + (j * I915_NUM_ENGINES);
- seq_printf(m, "0x%08llx (0x%02llx) ",
- seqno[offset], offset * 8);
- }
- seq_putc(m, '\n');
-
- }
- kunmap_atomic(seqno);
- } else {
- seq_puts(m, " Last signal:");
- for_each_engine(engine, dev_priv, id)
- for (j = 0; j < num_rings; j++)
- seq_printf(m, "0x%08x\n",
-
I915_READ(engine->semaphore.mbox.signal[j]));
- seq_putc(m, '\n');
- }
+ seq_puts(m, " Last signal:");
+ for_each_engine(engine, dev_priv, id)
+ for (j = 0; j < num_rings; j++)
+ seq_printf(m, "0x%08x\n",
+ I915_READ(engine->semaphore.mbox.signal[j]));
+ seq_putc(m, '\n');
intel_runtime_pm_put(dev_priv);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 75100c6e35c8..2cfa2791538d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -933,7 +933,6 @@ struct i915_gpu_state {
u64 fence[I915_MAX_NUM_FENCES];
struct intel_overlay_error_state *overlay;
struct intel_display_error_state *display;
- struct drm_i915_error_object *semaphore;
struct drm_i915_error_object *guc_lo
Re: [Intel-gfx] [PATCH] drm/i915: Remove obsolete ringbuffer emission for gen8+
Quoting Chris Wilson (2017-10-26 16:31:33) > Since removing the module parameter to force selection of ringbuffer > emission for gen8, the code is defunct. Remove it. Ah, there's meant to a patch to remove the modparam first. It's not required to test this patch, just equally pointless to keep i915.enable_execlists around. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible()
== Series Details == Series: series starting with [1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible() URL : https://patchwork.freedesktop.org/series/32698/ State : success == Summary == Series 32698v1 series starting with [1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible() https://patchwork.freedesktop.org/api/1.0/series/32698/revisions/1/mbox/ Test gem_sync: Subgroup basic-store-all: pass -> FAIL (fi-ivb-3520m) fdo#17 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:441s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:451s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:371s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:520s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:264s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:494s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:497s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:488s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:491s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:557s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:601s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:415s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:250s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:576s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:495s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:431s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:426s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:435s fi-ivb-3520m total:289 pass:259 dwarn:0 dfail:0 fail:1 skip:29 time:494s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:456s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:491s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:573s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:583s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:549s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:590s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:645s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:520s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:502s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:454s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:556s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:417s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest f78e927a1c83 drm/i915: Parse max HDMI TMDS clock from VBT 9e16e74909dc drm/i915: Clean up the mess around hdmi_12bpc_possible() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6209/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Parse max HDMI TMDS clock from VBT
Quoting Ville Syrjala (2017-10-26 16:14:05)
> From: Ville Syrjälä
>
> Starting from version 204 VBT can specify the max TMDS clock we are
> allowed to use with HDMI ports. Parse that information and take it
> into account when filtering modes and computing a crtc state.
>
> + if (bdb_version >= 204) {
> + int max_tmds_clock;
> +
> + switch (child->hdmi_max_data_rate) {
> + case 1:
> + max_tmds_clock = 297000;
> + break;
> + case 2:
> + max_tmds_clock = 165000;
> + break;
> + default:
> + max_tmds_clock = 0;
Is zero a valid value, as this will prevent us from using the output
at all?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible()
Quoting Ville Syrjala (2017-10-26 16:14:04) > From: Ville Syrjälä > > Move the crtc state related 12bpc checks into hdmi_12bpc_possible() > since that one already examines other parts of the crtc state. > > Note that we can drop the !force_dvi check since > crtc_state->has_hdmi_sink already accounts for that. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_hdmi.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 5132dc814788..aa486b8925cf 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1336,6 +1336,12 @@ static bool hdmi_12bpc_possible(const struct > intel_crtc_state *crtc_state) > if (HAS_GMCH_DISPLAY(dev_priv)) > return false; > > + if (crtc_state->pipe_bpp <= 8*3) > + return false; Ok. > + > + if (!crtc_state->has_hdmi_sink) > + return false; Ok. Now just for force_dvi... intel_hdmi_compute_config(): bool force_dvi = intel_conn_state->force_audio == HDMI_AUDIO_OFF_DVI; pipe_config->has_hdmi_sink = !force_dvi && intel_hdmi->has_hdmi_sink; and we follow on from that has_hdmi_sink, so ok. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Parse max HDMI TMDS clock from VBT
On Thu, Oct 26, 2017 at 04:44:39PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-10-26 16:14:05)
> > From: Ville Syrjälä
> >
> > Starting from version 204 VBT can specify the max TMDS clock we are
> > allowed to use with HDMI ports. Parse that information and take it
> > into account when filtering modes and computing a crtc state.
> >
> > + if (bdb_version >= 204) {
> > + int max_tmds_clock;
> > +
> > + switch (child->hdmi_max_data_rate) {
> > + case 1:
> > + max_tmds_clock = 297000;
> > + break;
> > + case 2:
> > + max_tmds_clock = 165000;
> > + break;
> > + default:
> > + max_tmds_clock = 0;
>
> Is zero a valid value, as this will prevent us from using the output
> at all?
Zero means "unlimited" or "use the platform default maximum". The code
using this will check to make sure it's non-zero before doing the min().
We use similar logic in hdmi_port_clock_limit() to handle the sink and
dongle limits.
--
Ville Syrjälä
Intel OTC
___
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: Remove obsolete ringbuffer emission for gen8+
== Series Details == Series: drm/i915: Remove obsolete ringbuffer emission for gen8+ URL : https://patchwork.freedesktop.org/series/32701/ State : failure == Summary == Series 32701v1 drm/i915: Remove obsolete ringbuffer emission for gen8+ https://patchwork.freedesktop.org/api/1.0/series/32701/revisions/1/mbox/ Test chamelium: Subgroup dp-hpd-fast: skip -> INCOMPLETE (fi-bdw-5557u) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:450s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:368s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:517s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:507s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:490s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:481s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:551s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:600s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:405s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:250s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:574s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:483s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:423s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:428s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:433s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:496s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:571s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:472s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:587s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:445s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:594s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:647s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:523s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:497s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:457s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:555s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:415s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 23ce74c902b6 drm/i915: Remove obsolete ringbuffer emission for gen8+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6210/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Preemption with GuC, fourth try (rev6)
== Series Details == Series: Preemption with GuC, fourth try (rev6) URL : https://patchwork.freedesktop.org/series/32654/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-A: pass -> DMESG-WARN (shard-hsw) fdo#102249 +1 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 shard-hswtotal:2539 pass:1433 dwarn:1 dfail:0 fail:8 skip:1097 time:9240s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6207/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Parse max HDMI TMDS clock from VBT
Quoting Ville Syrjälä (2017-10-26 16:51:23)
> On Thu, Oct 26, 2017 at 04:44:39PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2017-10-26 16:14:05)
> > > From: Ville Syrjälä
> > >
> > > Starting from version 204 VBT can specify the max TMDS clock we are
> > > allowed to use with HDMI ports. Parse that information and take it
> > > into account when filtering modes and computing a crtc state.
> > >
> > > + if (bdb_version >= 204) {
> > > + int max_tmds_clock;
> > > +
> > > + switch (child->hdmi_max_data_rate) {
> > > + case 1:
> > > + max_tmds_clock = 297000;
> > > + break;
> > > + case 2:
> > > + max_tmds_clock = 165000;
> > > + break;
> > > + default:
> > > + max_tmds_clock = 0;
> >
> > Is zero a valid value, as this will prevent us from using the output
> > at all?
>
> Zero means "unlimited" or "use the platform default maximum". The code
> using this will check to make sure it's non-zero before doing the min().
Indeed, I didn't look at the guard closely enough, just expected it to
be a if (use_vbt_flag) and not if (max_tmds_clock).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel the modeset retry work during modeset cleanup
On Thu, Oct 26, 2017 at 07:33:44AM +0100, Chris Wilson wrote:
> Quoting Manasi Navare (2017-10-26 02:20:04)
> > During modeset cleanup on driver unload we may have a pending
> > hotplug work. This needs to be cancel early during the teardown
> > so that it does not fire after we have freed the connector.
> > We do this after drm_kms_helper_poll_fini(dev) since this might
> > cause link retrain and before intel_fbdev_fini() since this tries to
> > free the connector.
> >
> > If this is not done we may see something like:
> > DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
> > [ cut here ]
> > WARNING: CPU: 4 PID: 5010 at kernel/locking/mutex-debug.c:103
> > mutex_destroy+0x4e/0x60
> > Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek
> > snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem
> > ax88179_178
> > +a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp
> > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core
> > prime_numbers i2c_hid
> > +[last unloaded: snd_hda_intel]
> > CPU: 4 PID: 5010 Comm: drv_module_relo Tainted: G U
> > 4.14.0-rc3-CI-CI_DRM_3186+ #1
> > Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S
> > UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017
> > task: 8803c827aa40 task.stack: c952
> > RIP: 0010:mutex_destroy+0x4e/0x60
> > RSP: 0018:c9523d58 EFLAGS: 00010292
> > RAX: 002a RBX: 88044fbef648 RCX:
> > RDX: 8001 RSI: 0001 RDI: 810f0cf0
> > RBP: c9523d60 R08: 0001 R09: 0001
> > R10: 0f21cb81 R11: R12: 88044f71efc8
> > R13: a02b3d20 R14: a02b3d90 R15: 880459b29308
> > FS: 7f5df4d6e8c0() GS:88045d30()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 55ec51f00a18 CR3: 000451782006 CR4: 003606e0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> > drm_fb_helper_fini+0xd9/0x130
> > intel_fbdev_destroy+0x12/0x60 [i915]
> > intel_fbdev_fini+0x28/0x30 [i915]
> > intel_modeset_cleanup+0x45/0xa0 [i915]
> > i915_driver_unload+0x92/0x180 [i915]
> > i915_pci_remove+0x19/0x30 [i915]
> > i915_driver_unload+0x92/0x180 [i915]
> > i915_pci_remove+0x19/0x30 [i915]
> > pci_device_remove+0x39/0xb0
> > device_release_driver_internal+0x15d/0x220
> > driver_detach+0x40/0x80
> > bus_remove_driver+0x58/0xd0
> > driver_unregister+0x2c/0x40
> > pci_unregister_driver+0x36/0xb0
> > i915_exit+0x1a/0x8b [i915]
> > SyS_delete_module+0x18c/0x1e0
> > entry_SYSCALL_64_fastpath+0x1c/0xb1
> > RIP: 0033:0x7f5df3286287
> > RSP: 002b:7fff8e107cc8 EFLAGS: 0246 ORIG_RAX: 00b0
> > RAX: ffda RBX: 81493a03 RCX: 7f5df3286287
> > RDX: 0001 RSI: 0800 RDI: 564c7be02e48
> > RBP: c9523f88 R08: R09: 0080
> > R10: 7f5df4d6e8c0 R11: 0246 R12:
> > R13: 7fff8e107eb0 R14: R15:
> >
> > Suggested-by: Maarten Lankhorst
> > Suggested-by: Chris Wilson
> > Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
> > training failure")
> > Cc: Chris Wilson
> > Cc: Tony Cheng
> > Cc: Harry Wentland
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Cc: Manasi Navare
> > Cc: Maarten Lankhorst
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 16
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 366ba74..f81b073 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -4114,6 +4114,7 @@ extern void intel_modeset_gem_init(struct drm_device
> > *dev);
> > extern void intel_modeset_cleanup(struct drm_device *dev);
> > extern int intel_connector_register(struct drm_connector *);
> > extern void intel_connector_unregister(struct drm_connector *);
> > +extern void intel_connector_work_fn_cleanup(struct drm_device *dev);
> > extern int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv,
> >bool state);
> > extern void intel_display_resume(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0e493a1..44158ff 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15200,6 +15200,19 @@ void intel_connector_unregister(struct
> > drm_connector *connector)
> > intel_panel_destroy_
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible()
== Series Details == Series: series starting with [1/2] drm/i915: Clean up the mess around hdmi_12bpc_possible() URL : https://patchwork.freedesktop.org/series/32698/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-C: pass -> DMESG-WARN (shard-hsw) fdo#102249 +1 Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2539 pass:1432 dwarn:1 dfail:0 fail:9 skip:1097 time:9525s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6209/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Make GuC log part of the uC error state
On Wed, 25 Oct 2017 13:11:25 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2017-10-25 11:41:12) We keep details of GuC and HuC in separate error state struct. Make GuC log part of it to group all related data together. The only significant change would appear to placement in error-state; it now comes at the end. Maybe that's ok; what do we feel is the relevance of the guc log vs the dumping of user buffers? Do we want to read the log first, or are we likely to skip to the userstate and then jump back? I would expect data in error-state to be grouped always per "source" to easy track what is available from it. Also ordering of these sources can be based on the order driver is using/creating them (ie. pciid, modparams, device flags, uc, engines, buffers... - which is different than today's) At least the consideration is worthy of comment in the changelog. Ok, I'll add small note. Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/17] Per-context and per-client engine busyness
On 26/10/17 14:05, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-10-26 14:00:28) On 26/10/2017 10:50, Lionel Landwerlin wrote: On 26/10/17 08:34, Tvrtko Ursulin wrote: On 25/10/2017 18:38, Chris Wilson wrote: Quoting Chris Wilson (2017-10-25 16:47:13) Quoting Tvrtko Ursulin (2017-10-25 16:36:15) From: Tvrtko Ursulin I've prototyped a quick demo of intel-client-top which produces output like: neverball[ 6011]: rcs0: 41.01% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% Xorg[ 5664]: rcs0: 31.16% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% xfwm4[ 5727]: rcs0: 0.00% bcs0: 0.00% vcs0: 0.00% vecs0: 0.00% +1 +2 for a graph ;) Where are those placement students when you need them! :) I won't be your student, but I could like to wire this into gputop. I was thinking gputop as well but did find the time to look at it yet. We don't even ship gputop or the perf generator in igt... Can we at least make noises towards owning that code... -Chris It would be nice to have stuff in single repo but gputop has quite a few dependencies that I'm not sure igt will want. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4] lib: Move __gem_context_create to common ioctl wrapper library.
This patch adds a context creation ioctl wrapper that returns the error
for the caller to consume. Multiple tests that implemented this already,
have been changed to use the new library function.
v2:
- Add gem_require_contexts() to check for contexts support (Chris)
v3:
- Add gem_has_contexts to check for contexts support and change
gem_require_contexts to skip if contests support is not available.
(Chris)
v4:
- Cosmetic changes and use lib function in gem_ctx_create where
possible. (Michal)
Signed-off-by: Antonio Argenziano
Cc: Chris Wilson
Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
---
benchmarks/gem_exec_ctx.c | 6 ++---
benchmarks/gem_exec_trace.c | 4 +--
lib/i915/gem_context.c | 61 +
lib/i915/gem_context.h | 3 +++
tests/gem_ctx_create.c | 13 +-
tests/gem_ctx_switch.c | 13 --
tests/gem_eio.c | 13 +-
tests/gem_exec_await.c | 14 ++-
tests/gem_exec_nop.c| 13 --
tests/gem_exec_parallel.c | 15 +++
tests/gem_exec_reuse.c | 13 --
tests/gem_exec_whisper.c| 13 --
12 files changed, 72 insertions(+), 109 deletions(-)
diff --git a/benchmarks/gem_exec_ctx.c b/benchmarks/gem_exec_ctx.c
index 0eac04b0..a1c6e5d7 100644
--- a/benchmarks/gem_exec_ctx.c
+++ b/benchmarks/gem_exec_ctx.c
@@ -64,7 +64,7 @@ static uint32_t batch(int fd)
return handle;
}
-static uint32_t __gem_context_create(int fd)
+static uint32_t __gem_context_create_local(int fd)
{
struct drm_i915_gem_context_create create;
@@ -101,7 +101,7 @@ static int loop(unsigned ring,
execbuf.flags |= LOCAL_I915_EXEC_HANDLE_LUT;
execbuf.flags |= LOCAL_I915_EXEC_NO_RELOC;
if (mode != DEFAULT) {
- execbuf.rsvd1 = __gem_context_create(fd);
+ execbuf.rsvd1 = __gem_context_create_local(fd);
if (execbuf.rsvd1 == 0)
return 77;
}
@@ -125,7 +125,7 @@ static int loop(unsigned ring,
uint32_t ctx = 0;
if (mode != DEFAULT && mode != NOP) {
- execbuf.rsvd1 = __gem_context_create(fd);
+ execbuf.rsvd1 = __gem_context_create_local(fd);
ctx = gem_context_create(fd);
}
diff --git a/benchmarks/gem_exec_trace.c b/benchmarks/gem_exec_trace.c
index 12577649..2724ee92 100644
--- a/benchmarks/gem_exec_trace.c
+++ b/benchmarks/gem_exec_trace.c
@@ -105,7 +105,7 @@ static double elapsed(const struct timespec *start, const
struct timespec *end)
return 1e3*(end->tv_sec - start->tv_sec) + 1e-6*(end->tv_nsec -
start->tv_nsec);
}
-static uint32_t __gem_context_create(int fd)
+static uint32_t __gem_context_create_local(int fd)
{
struct drm_i915_gem_context_create arg = {};
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &arg);
@@ -216,7 +216,7 @@ static double replay(const char *filename, long nop, long
range)
num_ctx = new_ctx;
}
- ctx[t->handle] = __gem_context_create(fd);
+ ctx[t->handle] = __gem_context_create_local(fd);
break;
}
case DEL_CTX:
diff --git a/lib/i915/gem_context.c b/lib/i915/gem_context.c
index 6d9edf5e..38ffe545 100644
--- a/lib/i915/gem_context.c
+++ b/lib/i915/gem_context.c
@@ -43,6 +43,52 @@
* software features improving submission model (context priority).
*/
+/**
+ * gem_has_contexts:
+ * @fd: open i915 drm file descriptor
+ *
+ * Queries whether context creation is supported or not.
+ *
+ * Returns: Context creation availability.
+ */
+bool gem_has_contexts(int fd)
+{
+ uint32_t ctx_id = 0;
+
+ __gem_context_create(fd, &ctx_id);
+ if (ctx_id)
+ gem_context_destroy(fd, ctx_id);
+
+ return ctx_id;
+}
+
+/**
+ * gem_require_contexts:
+ * @fd: open i915 drm file descriptor
+ *
+ * This helper will automatically skip the test on platforms where context
+ * support is not available.
+ */
+void gem_require_contexts(int fd)
+{
+ igt_require(gem_has_contexts(fd));
+}
+
+int __gem_context_create(int fd, uint32_t *ctx_id)
+{
+ struct drm_i915_gem_context_create create;
+ int err = 0;
+
+ memset(&create, 0, sizeof(create));
+ if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create) == 0)
+ *ctx_id = create.ctx_id;
+ else
+ err = -errno;
+
+ errno = 0;
+ return err;
+}
+
/**
* gem_context_create:
* @fd: open i915 drm file descriptor
@@ -55,18 +101,13 @@
*/
uint32_t gem_context_create(int fd)
{
- struct drm_i915_gem_context_create create;
+ uint32_t ctx_id;
+ gem_require_contexts(fd);
- memset(&create, 0, sizeof(create))
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Remove support for legacy CRC api.
On Thu, Oct 26, 2017 at 01:38:51PM +0200, Maarten Lankhorst wrote:
> In kernel v4.10 the legacy crc api has been replaced by a generic
> drm crc API. While at it, fix igt_require_pipe_crc, the file cannot be
> opened any more when the crtc is not active after kernel commit 8038e09be5a3
> ("drm/crc: Only open CRC on atomic drivers when the CRTC is active.").
> Statting the file should be enough for testing it's supported.
What's the impact of this change on devices running older kernels - such
as KBL ChromeOS on 4.4?
>
> Cc: Tomi Sarvela
> Cc: Petri Latvala
> Cc: Jani Nikula
> Signed-off-by: Maarten Lankhorst
> ---
> lib/igt_debugfs.c | 231
> +++---
> 1 file changed, 28 insertions(+), 203 deletions(-)
>
> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> index 8b33b478a9a9..63a0989e5ceb 100644
> --- a/lib/igt_debugfs.c
> +++ b/lib/igt_debugfs.c
> @@ -416,16 +416,12 @@ char *igt_crc_to_string(igt_crc_t *crc)
> #define MAX_CRC_ENTRIES 10
> #define MAX_LINE_LEN (10 + 11 * MAX_CRC_ENTRIES + 1)
>
> -/* (6 fields, 8 chars each, space separated (5) + '\n') */
> -#define LEGACY_LINE_LEN (6 * 8 + 5 + 1)
> -
> struct _igt_pipe_crc {
> int fd;
> int dir;
> int ctl_fd;
> int crc_fd;
> int flags;
> - bool is_legacy;
>
> enum pipe pipe;
> enum intel_pipe_crc_source source;
> @@ -449,130 +445,6 @@ static const char *pipe_crc_source_name(enum
> intel_pipe_crc_source source)
> return pipe_crc_sources[source];
> }
>
> -static bool igt_pipe_crc_do_start(igt_pipe_crc_t *pipe_crc)
> -{
> - char buf[64];
> -
> - /* Stop first just to make sure we don't have lingering state left. */
> - igt_pipe_crc_stop(pipe_crc);
> -
> - if (pipe_crc->is_legacy)
> - sprintf(buf, "pipe %s %s", kmstest_pipe_name(pipe_crc->pipe),
> - pipe_crc_source_name(pipe_crc->source));
> - else
> - sprintf(buf, "%s", pipe_crc_source_name(pipe_crc->source));
> -
> - igt_assert_eq(write(pipe_crc->ctl_fd, buf, strlen(buf)), strlen(buf));
> -
> - if (!pipe_crc->is_legacy) {
> - int err;
> -
> - sprintf(buf, "crtc-%d/crc/data", pipe_crc->pipe);
> - err = 0;
> -
> - pipe_crc->crc_fd = openat(pipe_crc->dir, buf, pipe_crc->flags);
> - if (pipe_crc->crc_fd < 0)
> - err = -errno;
> -
> - if (err == -EINVAL)
> - return false;
> -
> - igt_assert_eq(err, 0);
> - }
> -
> - errno = 0;
> - return true;
> -}
> -
> -static void igt_pipe_crc_pipe_off(int fd, enum pipe pipe)
> -{
> - char buf[32];
> -
> - sprintf(buf, "pipe %s none", kmstest_pipe_name(pipe));
> - igt_assert_eq(write(fd, buf, strlen(buf)), strlen(buf));
> -}
> -
> -static void igt_pipe_crc_reset(int drm_fd)
> -{
> - struct dirent *dirent;
> - const char *cmd = "none";
> - bool done = false;
> - DIR *dir;
> - int fdir;
> - int fd;
> -
> - fdir = igt_debugfs_dir(drm_fd);
> - if (fdir < 0)
> - return;
> -
> - dir = fdopendir(fdir);
> - if (!dir) {
> - close(fdir);
> - return;
> - }
> -
> - while ((dirent = readdir(dir))) {
> - char buf[PATH_MAX];
> -
> - if (strcmp(dirent->d_name, "crtc-") != 0)
> - continue;
> -
> - sprintf(buf, "%s/crc/control", dirent->d_name);
> - fd = openat(fdir, buf, O_WRONLY);
> - if (fd < 0)
> - continue;
> -
> - igt_assert_eq(write(fd, cmd, strlen(cmd)), strlen(cmd));
> - close(fd);
> -
> - done = true;
> - }
> - closedir(dir);
> -
> - if (!done) {
> - fd = openat(fdir, "i915_display_crtc_ctl", O_WRONLY);
> - if (fd != -1) {
> - igt_pipe_crc_pipe_off(fd, PIPE_A);
> - igt_pipe_crc_pipe_off(fd, PIPE_B);
> - igt_pipe_crc_pipe_off(fd, PIPE_C);
> -
> - close(fd);
> - }
> - }
> -
> - close(fdir);
> -}
> -
> -static void pipe_crc_exit_handler(int sig)
> -{
> - struct dirent *dirent;
> - char buf[PATH_MAX];
> - DIR *dir;
> - int fd;
> -
> - dir = opendir("/dev/dri");
> - if (!dir)
> - return;
> -
> - /*
> - * Try to reset CRC capture for all DRM devices, this is only needed
> - * for the legacy CRC ABI and can be completely removed once the
> - * legacy codepaths are removed.
> - */
> - while ((dirent = readdir(dir))) {
> - if (strncmp(dirent->d_name, "card", 4) != 0)
> - continue;
> -
> - sprintf(buf, "/dev/dri/%s", dirent->d_name);
> - fd = open(buf, O_WRONLY);
> -
> - igt_pipe_crc_reset(fd);
> -
> - close(fd);
> - }
> - closedir(dir);
> -}
> -
> /*
[Intel-gfx] [PATCH v6 1/3] drm/i915: Add Guc/HuC firmware details to error state
Include GuC and HuC firmware details in captured error state
to provide additional debug information. To reuse existing
uc firmware pretty printer, introduce new drm-printer variant
that works with our i915_error_state_buf output. Also update
uc firmware pretty printer to accept const input.
v2: don't rely on current caps (Chris)
dump correct fw info (Michal)
v3: simplify capture of custom paths (Chris)
v4: improve 'why' comment (Joonas)
trim output if no fw path (Michal)
group code around uc error state (Michal)
v5: use error in cleanup_uc (Michal)
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 65 +++
drivers/gpu/drm/i915/intel_uc_fw.c| 6 +++-
drivers/gpu/drm/i915/intel_uc_fw.h| 2 +-
4 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 366ba74..f19f0fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -911,6 +911,11 @@ struct i915_gpu_state {
struct intel_device_info device_info;
struct i915_params params;
+ struct i915_error_uc {
+ struct intel_uc_fw guc_fw;
+ struct intel_uc_fw huc_fw;
+ } uc;
+
/* Generic register state */
u32 eir;
u32 pgtbl_er;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 653fb69..4500fc8 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+
#include "i915_drv.h"
static const char *engine_str(int engine)
@@ -175,6 +177,21 @@ static void i915_error_puts(struct
drm_i915_error_state_buf *e,
#define err_printf(e, ...) i915_error_printf(e, __VA_ARGS__)
#define err_puts(e, s) i915_error_puts(e, s)
+static void __i915_printfn_error(struct drm_printer *p, struct va_format *vaf)
+{
+ i915_error_vprintf(p->arg, vaf->fmt, *vaf->va);
+}
+
+static inline struct drm_printer
+i915_error_printer(struct drm_i915_error_state_buf *e)
+{
+ struct drm_printer p = {
+ .printfn = __i915_printfn_error,
+ .arg = e,
+ };
+ return p;
+}
+
#ifdef CONFIG_DRM_I915_COMPRESS_ERROR
struct compress {
@@ -589,11 +606,26 @@ static void err_print_pciid(struct
drm_i915_error_state_buf *m,
pdev->subsystem_device);
}
+static void err_print_uc(struct drm_i915_error_state_buf *m,
+const struct i915_error_uc *error_uc)
+{
+ struct drm_printer p = i915_error_printer(m);
+ const struct i915_gpu_state *error =
+ container_of(error_uc, typeof(*error), uc);
+
+ if (!error->device_info.has_guc)
+ return;
+
+ intel_uc_fw_dump(&error_uc->guc_fw, &p);
+ intel_uc_fw_dump(&error_uc->huc_fw, &p);
+}
+
int i915_error_state_to_str(struct drm_i915_error_state_buf *m,
const struct i915_gpu_state *error)
{
struct drm_i915_private *dev_priv = m->i915;
struct drm_i915_error_object *obj;
+
int i, j;
if (!error) {
@@ -773,6 +805,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
err_print_capabilities(m, &error->device_info);
err_print_params(m, &error->params);
+ err_print_uc(m, &error->uc);
if (m->bytes == 0 && m->err)
return m->err;
@@ -831,6 +864,14 @@ static __always_inline void free_param(const char *type,
void *x)
kfree(*(void **)x);
}
+static void cleanup_uc_state(struct i915_gpu_state *error)
+{
+ struct i915_error_uc *error_uc = &error->uc;
+
+ kfree(error_uc->guc_fw.path);
+ kfree(error_uc->huc_fw.path);
+}
+
void __i915_gpu_state_free(struct kref *error_ref)
{
struct i915_gpu_state *error =
@@ -870,6 +911,8 @@ void __i915_gpu_state_free(struct kref *error_ref)
I915_PARAMS_FOR_EACH(FREE);
#undef FREE
+ cleanup_uc_state(error);
+
kfree(error);
}
@@ -1559,6 +1602,26 @@ static void i915_capture_pinned_buffers(struct
drm_i915_private *dev_priv,
error->pinned_bo = bo;
}
+static void capture_uc_state(struct i915_gpu_state *error)
+{
+ struct drm_i915_private *i915 = error->i915;
+ struct i915_error_uc *error_uc = &error->uc;
+
+ /* Capturing uC state won't be useful if there is no GuC */
+ if (!error->device_info.has_guc)
+ return;
+
+ error_uc->guc_fw = i915->guc.fw;
+ error_uc->huc_fw = i915->huc.fw;
+
+ /* Non-default firmware paths will be specified by the modparam.
+* As modparams are generally accesible from the userspace make
+* explicit copies of the firmware paths.
+*/
+ error_uc->guc_fw.path = kstrdup(i915->guc.
[Intel-gfx] [PATCH v6 3/3] drm/i915: Handle error-state modparams in dedicated functions
Capturing and cleanup and modparams in error state requires
some macro tricks. Move that code into separated functions
for easier maintenance.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f18f65e..ee6233b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -863,6 +863,13 @@ static __always_inline void free_param(const char *type,
void *x)
kfree(*(void **)x);
}
+static void cleanup_params(struct i915_gpu_state *error)
+{
+#define FREE(T, x, ...) free_param(#T, &error->params.x);
+ I915_PARAMS_FOR_EACH(FREE);
+#undef FREE
+}
+
static void cleanup_uc_state(struct i915_gpu_state *error)
{
struct i915_error_uc *error_uc = &error->uc;
@@ -906,10 +913,7 @@ void __i915_gpu_state_free(struct kref *error_ref)
kfree(error->overlay);
kfree(error->display);
-#define FREE(T, x, ...) free_param(#T, &error->params.x);
- I915_PARAMS_FOR_EACH(FREE);
-#undef FREE
-
+ cleanup_params(error);
cleanup_uc_state(error);
kfree(error);
@@ -1747,6 +1751,14 @@ static __always_inline void dup_param(const char *type,
void *x)
*(void **)x = kstrdup(*(void **)x, GFP_ATOMIC);
}
+static void capture_params(struct i915_gpu_state *error)
+{
+ error->params = i915_modparams;
+#define DUP(T, x, ...) dup_param(#T, &error->params.x);
+ I915_PARAMS_FOR_EACH(DUP);
+#undef DUP
+}
+
static int capture(void *data)
{
struct i915_gpu_state *error = data;
@@ -1757,11 +1769,7 @@ static int capture(void *data)
ktime_to_timeval(ktime_sub(ktime_get(),
error->i915->gt.last_init_time));
- error->params = i915_modparams;
-#define DUP(T, x, ...) dup_param(#T, &error->params.x);
- I915_PARAMS_FOR_EACH(DUP);
-#undef DUP
-
+ capture_params(error);
capture_uc_state(error);
i915_capture_gen_state(error->i915, error);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/3] drm/i915: Make GuC log part of the uC error state
We keep details of GuC and HuC in separate error state struct.
Make GuC log part of it to group all related data together.
Since we are printing uC details at the end, with this change
GuC log will be moved there too.
v2: comment on new placement of the log (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f19f0fa..45a74d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -914,6 +914,7 @@ struct i915_gpu_state {
struct i915_error_uc {
struct intel_uc_fw guc_fw;
struct intel_uc_fw huc_fw;
+ struct drm_i915_error_object *guc_log;
} uc;
/* Generic register state */
@@ -939,7 +940,6 @@ struct i915_gpu_state {
struct intel_overlay_error_state *overlay;
struct intel_display_error_state *display;
struct drm_i915_error_object *semaphore;
- struct drm_i915_error_object *guc_log;
struct drm_i915_error_engine {
int engine_id;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4500fc8..f18f65e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -618,6 +618,7 @@ static void err_print_uc(struct drm_i915_error_state_buf *m,
intel_uc_fw_dump(&error_uc->guc_fw, &p);
intel_uc_fw_dump(&error_uc->huc_fw, &p);
+ print_error_obj(m, NULL, "GuC log buffer", error_uc->guc_log);
}
int i915_error_state_to_str(struct drm_i915_error_state_buf *m,
@@ -795,8 +796,6 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
print_error_obj(m, NULL, "Semaphores", error->semaphore);
- print_error_obj(m, NULL, "GuC log buffer", error->guc_log);
-
if (error->overlay)
intel_overlay_print_error_state(m, error->overlay);
@@ -870,6 +869,7 @@ static void cleanup_uc_state(struct i915_gpu_state *error)
kfree(error_uc->guc_fw.path);
kfree(error_uc->huc_fw.path);
+ i915_error_object_free(error_uc->guc_log);
}
void __i915_gpu_state_free(struct kref *error_ref)
@@ -898,7 +898,6 @@ void __i915_gpu_state_free(struct kref *error_ref)
}
i915_error_object_free(error->semaphore);
- i915_error_object_free(error->guc_log);
for (i = 0; i < ARRAY_SIZE(error->active_bo); i++)
kfree(error->active_bo[i]);
@@ -1620,17 +1619,7 @@ static void capture_uc_state(struct i915_gpu_state
*error)
*/
error_uc->guc_fw.path = kstrdup(i915->guc.fw.path, GFP_ATOMIC);
error_uc->huc_fw.path = kstrdup(i915->huc.fw.path, GFP_ATOMIC);
-}
-
-static void i915_gem_capture_guc_log_buffer(struct drm_i915_private *dev_priv,
- struct i915_gpu_state *error)
-{
- /* Capturing log buf contents won't be useful if logging was disabled */
- if (!dev_priv->guc.log.vma || (i915_modparams.guc_log_level < 0))
- return;
-
- error->guc_log = i915_error_object_create(dev_priv,
- dev_priv->guc.log.vma);
+ error_uc->guc_log = i915_error_object_create(i915, i915->guc.log.vma);
}
/* Capture all registers which don't fit into another category. */
@@ -1781,7 +1770,6 @@ static int capture(void *data)
i915_gem_record_rings(error->i915, error);
i915_capture_active_buffers(error->i915, error);
i915_capture_pinned_buffers(error->i915, error);
- i915_gem_capture_guc_log_buffer(error->i915, error);
error->overlay = intel_overlay_capture_error_state(error->i915);
error->display = intel_display_capture_error_state(error->i915);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Lib: Move __gem_context_create to common ioctl wrapper library. (rev3)
== Series Details == Series: Lib: Move __gem_context_create to common ioctl wrapper library. (rev3) URL : https://patchwork.freedesktop.org/series/31775/ State : failure == Summary == IGT patchset tested on top of latest successful build 1fc4de1ca390adec9be8bd7cc0c36cab07465959 igt/gem_exec_latency: Wire up an interloper for preemption with latest DRM-Tip kernel build CI_DRM_3286 df3033b17405 drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest No testlist changes. Test chamelium: Subgroup dp-crc-fast: pass -> FAIL (fi-kbl-7500u) fdo#102514 Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-glk-dsi) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:441s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:458s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:373s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:522s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:263s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:495s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:498s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:506s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:484s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:555s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:620s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:252s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:578s fi-glk-dsi total:12 pass:2dwarn:0 dfail:0 fail:0 skip:9 fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:436s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:485s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:480s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:570s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:583s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:541s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:455s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:593s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:649s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:514s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:504s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:459s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:566s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:427s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_428/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Bit definition for D3 power state that keeps AUX fully powered
On Thu, 2017-10-26 at 10:59 +0300, Jani Nikula wrote: > On Thu, 10 Aug 2017, Dhinakaran Pandiyan wrote: > > DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state > > > > 101 = Set Main-Link for local Sink device and all downstream Sink > > devices to D3 (power-down mode), keep AUX block fully powered, ready to > > reply within a Response Timeout period of 300us. > > > > This state is useful in a MST dock + MST monitor configuration that > > doesn't wake up from D3 state. > > Dhinakaran, these two seem to have fallen through the cracks, please > resend. > So the "drm/dp/mst: Sideband message transaction to power up/down nodes" series I sent fixed the DPMS issues I was seeing with my setup. We'll have to evaluate whether this patch is still useful for anyone (probably https://bugs.freedesktop.org/show_bug.cgi?id=90963). > Sorry & thanks, > Jani. > > > > > > Signed-off-by: Dhinakaran Pandiyan > > --- > > include/drm/drm_dp_helper.h | 9 + > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > index b17476a..d77e0f5 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -614,10 +614,11 @@ > > #define DP_BRANCH_HW_REV0x509 > > #define DP_BRANCH_SW_REV0x50A > > > > -#define DP_SET_POWER0x600 > > -# define DP_SET_POWER_D00x1 > > -# define DP_SET_POWER_D30x2 > > -# define DP_SET_POWER_MASK 0x3 > > +#define DP_SET_POWER 0x600 > > +# define DP_SET_POWER_D0 0x1 > > +# define DP_SET_POWER_D3 0x2 > > +# define DP_SET_POWER_MASK 0x3 > > +# define DP_SET_POWER_D3_AUX_ON0x5 > > > > #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ > > # define DP_EDP_11 0x00 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/6] drm/i915 : Unifying seq_puts messages for feature support
On 25/10/17 06:31, Michal Wajdeczko wrote:
On Tue, 24 Oct 2017 19:21:20 +0200, Sujaritha Sundaresan
wrote:
Unifying the various seq_puts messages in debugfs to the simplest one for
feature support.
v2: Clarifying the commit message (Anusha)
v3: Re-factoring code as per review (Michal)
v4: Rebase
v5: Split from following patch
v6: Re-factoring code (Michal, Sagar)
Clarifying commit message (Sagar)
v7: Generalizing subject to drm/i915 (Sagar)
v8: Omitting DRRS seq_puts unification (Michal)
Suggested by: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
Cc: Anusha Srivatsa
Cc: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381..8edd029 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1641,7 +1641,7 @@ static int i915_fbc_status(struct seq_file *m,
void *unused)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
if (!HAS_FBC(dev_priv)) {
- seq_puts(m, "FBC unsupported on this chipset\n");
+ seq_puts(m, "not supported\n");
return 0;
}
@@ -1809,7 +1809,7 @@ static int i915_ring_freq_table(struct seq_file
*m, void *unused)
unsigned int max_gpu_freq, min_gpu_freq;
if (!HAS_LLC(dev_priv)) {
- seq_puts(m, "unsupported on this chipset\n");
+ seq_puts(m, "not supported\n");
return 0;
}
@@ -2361,8 +2361,10 @@ static int i915_huc_load_status_info(struct
seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_printer p;
- if (!HAS_HUC_UCODE(dev_priv))
+ if (!HAS_GUC(dev_priv)) {
Hmm, I think that in above code we should use HAS_HUC defined as:
/* HuC is inherent part of the GuC ... */
#define HAS_HUC(dev_priv) HAS_GUC(dev_priv)
to make it clear that code checks HuC sub-feature (not other part
of the GuC or GuC itself). And additionally we can use above define
to explicitly document relation between GuC and HuC.
Michal
The suggested comment feels confusing to me. HuC is a different
microcontroller and not a part of GuC. The only tie the 2 have is that
GuC needs to do the authentication. It is however true that any platform
that has a GuC also has a HuC so the suggested define itself is fine.
Daniele
+ seq_puts(m, "not supported\n");
return 0;
+ }
p = drm_seq_file_printer(m);
intel_uc_fw_dump(&dev_priv->huc.fw, &p);
@@ -2380,8 +2382,10 @@ static int i915_guc_load_status_info(struct
seq_file *m, void *data)
struct drm_printer p;
u32 tmp, i;
- if (!HAS_GUC_UCODE(dev_priv))
+ if (!HAS_GUC(dev_priv)) {
+ seq_puts(m, "not supported\n");
return 0;
+ }
p = drm_seq_file_printer(m);
intel_uc_fw_dump(&dev_priv->guc.fw, &p);
@@ -2650,7 +2654,7 @@ static int i915_edp_psr_status(struct seq_file
*m, void *data)
bool enabled = false;
if (!HAS_PSR(dev_priv)) {
- seq_puts(m, "PSR not supported\n");
+ seq_puts(m, "not supported\n");
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/3] drm/i915: Add Guc/HuC firmware details to error state
== Series Details == Series: series starting with [v6,1/3] drm/i915: Add Guc/HuC firmware details to error state URL : https://patchwork.freedesktop.org/series/32710/ State : success == Summary == Series 32710v1 series starting with [v6,1/3] drm/i915: Add Guc/HuC firmware details to error state https://patchwork.freedesktop.org/api/1.0/series/32710/revisions/1/mbox/ Test chamelium: Subgroup hdmi-hpd-fast: skip -> FAIL (fi-kbl-7500u) fdo#102672 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b-frame-sequence: skip -> PASS (fi-hsw-4770r) fdo#102332 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:443s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:453s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:372s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:527s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:265s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:502s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:510s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:499s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:484s fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:561s fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:605s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:249s fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:581s fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:496s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:430s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:427s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:431s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:497s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:1 skip:23 time:489s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:480s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:545s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:593s fi-skl-6700hqtotal:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:646s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:519s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:500s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:459s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:566s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:420s df3033b174059a59aa0c890f81de8af037abd11f drm-tip: 2017y-10m-26d-11h-03m-59s UTC integration manifest 976ff837e64e drm/i915: Handle error-state modparams in dedicated functions 4c3a25127b82 drm/i915: Make GuC log part of the uC error state 26138fd008d5 drm/i915: Add Guc/HuC firmware details to error state == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6211/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GIT PULL] gvt fix for 4.14-rc6
Hi: Here are some fixes for 4.14-rc6. Zhenyu's patch fixes the per_ctx_bb check in GVT-g since the usage of per_ctx_bb in i915 has been changed recently. Another two patches from Xiong fix the GPU hang of linxu guest when it's running large workload. Thanks, Zhi. The following changes since commit 7277f755048da562eb2489becacd38d0d05e1e06: drm/i915/perf: fix perf enable/disable ioctls with 32bits userspace (2017-10-25 08:16:13 -0700) are available in the git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2017-10-26 for you to fetch changes up to d928347d52b5a1d3cee4e4ccf45d4ae1563cfb6f: drm/i915/gvt: Adding ACTHD mmio read handler (2017-10-27 01:39:02 +0800) Xiong Zhang (2): drm/i915/gvt: Extract mmio_read_from_hw() common function drm/i915/gvt: Adding ACTHD mmio read handler Zhenyu Wang (1): drm/i915/gvt: properly check per_ctx bb valid state Zhi Wang (1): drm/i915/gvt: Refine MMIO_RING_F() drivers/gpu/drm/i915/gvt/cmd_parser.c | 3 ++ drivers/gpu/drm/i915/gvt/execlist.c | 3 +- drivers/gpu/drm/i915/gvt/handlers.c | 70 +-- drivers/gpu/drm/i915/gvt/reg.h| 3 -- drivers/gpu/drm/i915/gvt/scheduler.h | 1 + 5 files changed, 15 insertions(+), 65 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Lib: Move __gem_context_create to common ioctl wrapper library. (rev3)
== Series Details == Series: Lib: Move __gem_context_create to common ioctl wrapper library. (rev3) URL : https://patchwork.freedesktop.org/series/31775/ State : failure == Summary == Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-A: pass -> DMESG-WARN (shard-hsw) fdo#102249 +2 Test kms_flip: Subgroup plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#102504 Subgroup flip-vs-dpms-interruptible: pass -> INCOMPLETE (shard-hsw) Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-A-planes: skip -> PASS (shard-hsw) Test kms_vblank: Subgroup accuracy-idle: pass -> FAIL (shard-hsw) fdo#102583 Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (shard-hsw) fdo#102707 fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249 fdo#102504 https://bugs.freedesktop.org/show_bug.cgi?id=102504 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707 shard-hswtotal:2506 pass:1408 dwarn:3 dfail:0 fail:10 skip:1084 time:9010s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_428/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/cnl: Fix SSEU Device Status.
On Thu, Oct 26, 2017 at 02:31:16PM +, Lionel Landwerlin wrote:
> Since I've been looking at EU_DISABLE* in intel_device_info.c, your patch
> caught my eye :)
> Reading the documentation I couldn't find anything wrong.
>
> Reviewed-by: Lionel Landwerlin
Thanks. Merged to dinq.
>
> On 26/10/17 01:15, Rodrigo Vivi wrote:
> > CNL adds an extra register for slice/subslice information.
> > Although no SKU is planed with an extra slice let's already
> > handle this extra piece of information so we don't have the
> > risk in future of getting a part that might have chosen this
> > part of the die instead of other slices or anything like that.
> >
> > Also if subslice is disabled the information of eu ack for that
> > is garbage, so let's skip checks for eu if subslice is disabled
> > as we skip the subslice if slice is disabled.
> >
> > The rest is pretty much like gen9.
> >
> > v2: Remove IS_CANNONLAKE from gen9 status function.
> >
> > v3: Consider s_max = 6 and ss_max=4 to run over all possible
> > slices and subslices possible by spec. Although no real
> > hardware will have that many slices/subslices.
> > To match with sseu info init.
> > v4: Fix offset calculation for slices 4 and 5.
> > Removed Oscar's rv-b since this change also needs review.
> > v5: Let's consider only valid bits for SLICE*_PGCTL_ACK.
> > This looks like wrong in Spec, but seems to be enough
> > for now. Whenever Spec gets updated and fixed we come
> > back and properly update the masks. Also add a FIXME,
> > so we can revisit this later when we find some strange
> > info on debugfs or when we noitce spec got updated.
> >
> > Cc: Oscar Mateo
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 61
> > +++--
> > drivers/gpu/drm/i915/i915_reg.h | 7 +
> > 2 files changed, 66 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index c65e381b85f3..61c466ff87e0 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4448,6 +4448,61 @@ static void cherryview_sseu_device_status(struct
> > drm_i915_private *dev_priv,
> > }
> > }
> > +static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
> > +struct sseu_dev_info *sseu)
> > +{
> > + const struct intel_device_info *info = INTEL_INFO(dev_priv);
> > + int s_max = 6, ss_max = 4;
> > + int s, ss;
> > + u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
> > +
> > + for (s = 0; s < s_max; s++) {
> > + /*
> > +* FIXME: Valid SS Mask respects the spec and read
> > +* only valid bits for those registers, excluding reserverd
> > +* although this seems wrong becuase it would leave many
> > +* subslices without ACK.
> > +*/
> > + s_reg[s] = I915_READ(GEN10_SLICE_PGCTL_ACK(s)) &
> > + GEN10_PGCTL_VALID_SS_MASK(s);
> > + eu_reg[2 * s] = I915_READ(GEN10_SS01_EU_PGCTL_ACK(s));
> > + eu_reg[2 * s + 1] = I915_READ(GEN10_SS23_EU_PGCTL_ACK(s));
> > + }
> > +
> > + eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
> > +GEN9_PGCTL_SSA_EU19_ACK |
> > +GEN9_PGCTL_SSA_EU210_ACK |
> > +GEN9_PGCTL_SSA_EU311_ACK;
> > + eu_mask[1] = GEN9_PGCTL_SSB_EU08_ACK |
> > +GEN9_PGCTL_SSB_EU19_ACK |
> > +GEN9_PGCTL_SSB_EU210_ACK |
> > +GEN9_PGCTL_SSB_EU311_ACK;
> > +
> > + for (s = 0; s < s_max; s++) {
> > + if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
> > + /* skip disabled slice */
> > + continue;
> > +
> > + sseu->slice_mask |= BIT(s);
> > + sseu->subslice_mask = info->sseu.subslice_mask;
> > +
> > + for (ss = 0; ss < ss_max; ss++) {
> > + unsigned int eu_cnt;
> > +
> > + if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
> > + /* skip disabled subslice */
> > + continue;
> > +
> > + eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] &
> > + eu_mask[ss % 2]);
> > + sseu->eu_total += eu_cnt;
> > + sseu->eu_per_subslice = max_t(unsigned int,
> > + sseu->eu_per_subslice,
> > + eu_cnt);
> > + }
> > + }
> > +}
> > +
> > static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
> > struct sseu_dev_info *sseu)
> > {
> > @@ -4483,7 +4538,7 @@ static void gen9_sseu_device_status(struct
> > drm_i915_private *dev_priv,
> > sseu->slice_mask |= BIT(s);
> > - if (IS_GEN9_BC(dev_priv) || IS_CANNON
Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Add a second client, to be used for preemption
On 26/10/17 07:17, Michał Winiarski wrote:
@@ -763,14 +770,14 @@ static int guc_init_doorbell_hw(struct intel_guc *guc)
/* Now for every client (and not only execbuf_client) make sure their
* doorbells are known by the GuC */
- //for (client = client_list; client != NULL; client = client->next)
- {
- ret = __create_doorbell(client);
- if (ret) {
- DRM_ERROR("Couldn't recreate client %u doorbell: %d\n",
- client->stage_id, ret);
- return ret;
- }
+ ret = __create_doorbell(guc->execbuf_client);
+ if (ret)
+ return ret;
+
+ ret = __create_doorbell(guc->preempt_client);
+ if (ret) {
+ __destroy_doorbell(guc->execbuf_client);
+ return ret;
}
I'm pretty sure there's an old client left behind after this, e.g.:
static int guc_init_doorbell_hw(struct intel_guc *guc)
{
- struct i915_guc_client *client = guc->execbuf_client;
...
-Michel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/selftests: Add a GuC doorbells selftest
Try to create as many clients as it is currently possible (currently
limited to max number of doorbells) and exercise the doorbell
alloc/dealloc code.
Since our usage mode require very few clients/doorbells, this code has
been exercised very lightly and it's good to have a simple test for it.
As reference, this test already helped identify the bug fixed by
commit 7f1ea2ac3017 ("drm/i915/guc: Fix doorbell id selection").
v2: Extend number of clients; check for client allocation failure when
number of doorbells is exceeded; validate client properties; reuse
guc_init_doorbell_hw (Chris).
Signed-off-by: Michel Thierry
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Michal Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 15 +-
.../gpu/drm/i915/selftests/i915_live_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/intel_guc.c | 186 +
3 files changed, 199 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/intel_guc.c
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 13d383cdc4c9..e643f47c8697 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -725,10 +725,15 @@ static int __reset_doorbell(struct i915_guc_client*
client, u16 db_id)
* client. Also, tell GuC about all the doorbells in use by all clients.
* We do this because the KMD, the GuC and the doorbell HW can easily go out of
* sync (e.g. we can reset the GuC, but not the doorbel HW).
+ *
+ * The optional test_client is a hook to use this function with multiple
+ * clients in the guc selftest.
*/
-static int guc_init_doorbell_hw(struct intel_guc *guc)
+static int guc_init_doorbell_hw(struct intel_guc *guc,
+ struct i915_guc_client *test_client)
{
- struct i915_guc_client *client = guc->execbuf_client;
+ struct i915_guc_client *client = !test_client ? guc->execbuf_client :
+ test_client;
bool recreate_first_client = false;
u16 db_id;
int ret;
@@ -1244,7 +1249,7 @@ int i915_guc_submission_enable(struct drm_i915_private
*dev_priv)
guc_reset_wq(client);
- err = guc_init_doorbell_hw(guc);
+ err = guc_init_doorbell_hw(guc, NULL);
if (err)
goto err_execbuf_client;
@@ -1280,3 +1285,7 @@ void i915_guc_submission_disable(struct drm_i915_private
*dev_priv)
guc_client_free(guc->execbuf_client);
guc->execbuf_client = NULL;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftests/intel_guc.c"
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
index 54a73534b37e..1b750e92dd08 100644
--- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
@@ -19,3 +19,4 @@ selftest(evict, i915_gem_evict_live_selftests)
selftest(hugepages, i915_gem_huge_page_live_selftests)
selftest(contexts, i915_gem_context_live_selftests)
selftest(hangcheck, intel_hangcheck_live_selftests)
+selftest(guc, intel_guc_live_selftest)
diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c
b/drivers/gpu/drm/i915/selftests/intel_guc.c
new file mode 100644
index ..86e0be919d7f
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "../i915_selftest.h"
+
+/* max doorbell number + negative test for each client type */
+#define ATTEMPTS (GUC_NUM_DOORBELLS + GUC_CLIENT_PRIORITY_NUM)
+
+struct i915_guc_client *clients[ATTEMPTS];
+
+static bool available_dbs(struct intel_guc *guc, u32 priority)
+{
+ unsigned long offset;
+ unsigne
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Add a GuC doorbells selftest
On 26/10/17 11:51, Michel Thierry wrote:
Try to create as many clients as it is currently possible (currently
limited to max number of doorbells) and exercise the doorbell
alloc/dealloc code.
Since our usage mode require very few clients/doorbells, this code has
been exercised very lightly and it's good to have a simple test for it.
As reference, this test already helped identify the bug fixed by
commit 7f1ea2ac3017 ("drm/i915/guc: Fix doorbell id selection").
v2: Extend number of clients; check for client allocation failure when
number of doorbells is exceeded; validate client properties; reuse
guc_init_doorbell_hw (Chris).
This will conflict with Michal's patch ("Add a second client, to be used
for preemption") but I want to get feedback about reusing
guc_init_doorbell_hw in the selftest.
Thanks,
Signed-off-by: Michel Thierry
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Michal Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 15 +-
.../gpu/drm/i915/selftests/i915_live_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/intel_guc.c | 186 +
3 files changed, 199 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/intel_guc.c
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 13d383cdc4c9..e643f47c8697 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -725,10 +725,15 @@ static int __reset_doorbell(struct i915_guc_client*
client, u16 db_id)
* client. Also, tell GuC about all the doorbells in use by all clients.
* We do this because the KMD, the GuC and the doorbell HW can easily go out
of
* sync (e.g. we can reset the GuC, but not the doorbel HW).
+ *
+ * The optional test_client is a hook to use this function with multiple
+ * clients in the guc selftest.
*/
-static int guc_init_doorbell_hw(struct intel_guc *guc)
+static int guc_init_doorbell_hw(struct intel_guc *guc,
+ struct i915_guc_client *test_client)
{
- struct i915_guc_client *client = guc->execbuf_client;
+ struct i915_guc_client *client = !test_client ? guc->execbuf_client :
+ test_client;
bool recreate_first_client = false;
u16 db_id;
int ret;
@@ -1244,7 +1249,7 @@ int i915_guc_submission_enable(struct drm_i915_private
*dev_priv)
guc_reset_wq(client);
- err = guc_init_doorbell_hw(guc);
+ err = guc_init_doorbell_hw(guc, NULL);
if (err)
goto err_execbuf_client;
@@ -1280,3 +1285,7 @@ void i915_guc_submission_disable(struct drm_i915_private
*dev_priv)
guc_client_free(guc->execbuf_client);
guc->execbuf_client = NULL;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftests/intel_guc.c"
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
index 54a73534b37e..1b750e92dd08 100644
--- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
@@ -19,3 +19,4 @@ selftest(evict, i915_gem_evict_live_selftests)
selftest(hugepages, i915_gem_huge_page_live_selftests)
selftest(contexts, i915_gem_context_live_selftests)
selftest(hangcheck, intel_hangcheck_live_selftests)
+selftest(guc, intel_guc_live_selftest)
diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c
b/drivers/gpu/drm/i915/selftests/intel_guc.c
new file mode 100644
index ..86e0be919d7f
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/intel_guc.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "../i915_selftest.h"
+
+/* max doorbell number + negative test
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Add a GuC doorbells selftest (rev2)
== Series Details == Series: drm/i915/selftests: Add a GuC doorbells selftest (rev2) URL : https://patchwork.freedesktop.org/series/32655/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/gpu/drm/i915/i915_guc_submission.o In file included from ./include/linux/kernel.h:13:0, from ./include/linux/list.h:8, from ./include/linux/smp.h:11, from ./include/linux/tracepoint.h:17, from ./include/trace/events/dma_fence.h:7, from drivers/gpu/drm/i915/i915_guc_submission.c:26: drivers/gpu/drm/i915/selftests/intel_guc.c: In function ‘igt_guc_doorbells’: drivers/gpu/drm/i915/selftests/intel_guc.c:129:21: error: ‘struct i915_guc_client’ has no member named ‘id’ clients[i]->id, GUC_NUM_DOORBELLS); ^ ./include/linux/printk.h:301:33: note: in definition of macro ‘pr_err’ printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) ^~~ scripts/Makefile.build:313: recipe for target 'drivers/gpu/drm/i915/i915_guc_submission.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_guc_submission.o] Error 1 scripts/Makefile.build:572: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:572: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:572: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1023: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
