[Intel-gfx] [PULL] gvt-next-fixes
Hi, Here's more queued gvt fixes for 5.7. Please see details below. Thanks -- The following changes since commit a61ac1e75105a077ec1efd6923ae3c619f862304: drm/i915/gvt: Wean gvt off using dev_priv (2020-03-06 10:08:10 +0800) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2020-03-31 for you to fetch changes up to eb0ff8074e0baecba2cd0c7813f6cfa99bafc430: drm/i915/gvt: Fix klocwork issues about data size (2020-03-27 15:37:58 +0800) gvt-next-fixes-2020-03-31 - Fix non-privilege access warning (Tina) - Fix display port type (Tina) - BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan) - Bypass length check of LRI (Yan) - Fix one klocwork warning (Tina) Tina Zhang (3): drm/i915/gvt: Add some regs to force-to-nonpriv whitelist drm/i915/gvt: Fix display port type issue drm/i915/gvt: Fix klocwork issues about data size Yan Zhao (2): drm/i915/gvt: add support to command SWTESS_BASE_ADDRESS drm/i915/gvt: do not check len & max_len for lri drivers/gpu/drm/i915/gvt/cmd_parser.c | 16 drivers/gpu/drm/i915/gvt/display.c| 6 +++--- drivers/gpu/drm/i915/gvt/handlers.c | 8 ++-- drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++-- 4 files changed, 15 insertions(+), 19 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
On 31/03/2020 08:22, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Signed-off-by: Ashutosh Dixit
I forgot to mention this needs to be Cc: stable.
Still one nit below which should make the remaining function a bit simpler.
Thanks for your time.
-Lionel
---
drivers/gpu/drm/i915/i915_perf.c | 62 +++-
1 file changed, 13 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c74ebac50015..9c21f28f89a7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2914,49 +2914,6 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
gen8_update_reg_state_unlocked(ce, stream);
}
-/**
- * i915_perf_read_locked - &i915_perf_stream_ops->read with error normalisation
- * @stream: An i915 perf stream
- * @file: An i915 perf stream file
- * @buf: destination buffer given by userspace
- * @count: the number of bytes userspace wants to read
- * @ppos: (inout) file seek position (unused)
- *
- * Besides wrapping &i915_perf_stream_ops->read this provides a common place to
- * ensure that if we've successfully copied any data then reporting that takes
- * precedence over any internal error status, so the data isn't lost.
- *
- * For example ret will be -ENOSPC whenever there is more buffered data than
- * can be copied to userspace, but that's only interesting if we weren't able
- * to copy some data because it implies the userspace buffer is too small to
- * receive a single record (and we never split records).
- *
- * Another case with ret == -EFAULT is more of a grey area since it would seem
- * like bad form for userspace to ask us to overrun its buffer, but the user
- * knows best:
- *
- * http://yarchive.net/comp/linux/partial_reads_writes.html
- *
- * Returns: The number of bytes copied or a negative error code on failure.
- */
-static ssize_t i915_perf_read_locked(struct i915_perf_stream *stream,
-struct file *file,
-char __user *buf,
-size_t count,
-loff_t *ppos)
-{
- /* Note we keep the offset (aka bytes read) separate from any
-* error status so that the final check for whether we return
-* the bytes read with a higher precedence than any error (see
-* comment below) doesn't need to be handled/duplicated in
-* stream->ops->read() implementations.
-*/
- size_t offset = 0;
- int ret = stream->ops->read(stream, buf, count, &offset);
-
- return offset ?: (ret ?: -EAGAIN);
-}
-
/**
* i915_perf_read - handles read() FOP for i915 perf stream FDs
* @file: An i915 perf stream file
@@ -2982,7 +2939,8 @@ static ssize_t i915_perf_read(struct file *file,
{
struct i915_perf_stream *stream = file->private_data;
struct i915_perf *perf = stream->perf;
- ssize_t ret;
+ size_t offset = 0;
+ int __ret;
/* To ensure it's handled consistently we simply treat all reads of a
* disabled stream as an error. In particular it might otherwise lead
@@ -2992,6 +2950,8 @@ static ssize_t i915_perf_read(struct file *file,
return -EIO;
if (!(file->f_flags & O_NONBLOCK)) {
+ ssize_t ret;
+
/* There's the small chance of false positives from
* stream->ops->wait_unlocked.
*
@@ -3005,13 +2965,13 @@ static ssize_t i915_perf_read(struct file *file,
return ret;
mutex_lock(&perf->lock);
- ret = i915_perf_read_locked(stream, file,
- buf, count, ppos);
+ __ret = stream->ops->read(stream, buf, count, &offset);
I think you can keep using ret and just change the loop to while (ret >=
0) (which means no failure).
You will get -ENOSPC when the whole buffer is filled or some other error
which should trigger stream closure.
Finally you can 0 if nothing was written but there was nothing to read
and that keeps the read going.
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: check to see if the FPU is available before using it
== Series Details == Series: drm/i915: check to see if the FPU is available before using it URL : https://patchwork.freedesktop.org/series/75249/ State : success == Summary == CI Bug Log - changes from CI_DRM_8217_full -> Patchwork_17134_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17134_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@extended-parallel-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +10 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-iclb2/igt@gem_b...@extended-parallel-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-iclb5/igt@gem_b...@extended-parallel-vcs1.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-iclb3/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-iclb3/igt@gem_exec_sched...@preempt-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-iclb4/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_workarounds@suspend-resume: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-kbl7/igt@gem_workarou...@suspend-resume.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-kbl2/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][11] -> [TIMEOUT][12] ([i915#1526]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-snb5/igt@i915_pm_rc6_reside...@rc6-idle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_pm_rps@min-max-config-loaded: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#39]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-glk9/igt@i915_pm_...@min-max-config-loaded.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-glk6/igt@i915_pm_...@min-max-config-loaded.html * igt@i915_selftest@live@requests: - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#1531]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-tglb6/igt@i915_selftest@l...@requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-tglb2/igt@i915_selftest@l...@requests.html * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#52] / [i915#54]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-glk3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-glk9/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-apl7/igt@kms_fbcon_...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#221]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-skl2/igt@kms_f...@flip-vs-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-skl4/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8217/shard-apl6/igt@kms_f...@flip-vs-suspend-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17134/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][25] -> [FAIL][26] ([fdo#108145] / [i915#265]) [25]: https://intel-gfx-ci.01.org/tre
Re: [Intel-gfx] [PATCH v3 0/5] Introduce drm scaling filter property
On Mon, 30 Mar 2020 19:30:27 + Simon Ser wrote: > Hi, > > On Monday, March 30, 2020 8:38 PM, Pankaj Bharadiya > wrote: > > > Userspace patch series link: https://github.com/lrusak/xbmc/pull/24 > > This pull request is against a fork, not the official Kodi repository. > Are there any plans to upstream the change so that users can benefit > from it? Is there a reason why this pull request hasn't been opened > against the official repo? That is an excellent observation. Merge requests against forks do not count: https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#open-source-userspace-requirements Thanks, pq pgpWS4lILaW3r.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Double check breadcrumb before crying foul
Chris Wilson writes:
> process_csb: :00:02.0 bcs0: cs-irq head=4, tail=5
> process_csb: :00:02.0 bcs0: csb[5]: status=0x8002:0x6020
> trace_ports: :00:02.0 bcs0: preempted { ff84:45154! prio 2 }
> trace_ports: :00:02.0 bcs0: promote { ff84:45155* prio 2 }
> trace_ports: :00:02.0 bcs0: submit { ff84:45156 prio 2 }
>
> process_csb: :00:02.0 bcs0: cs-irq head=5, tail=6
> process_csb: :00:02.0 bcs0: csb[6]: status=0x0018:0x6020
> trace_ports: :00:02.0 bcs0: completed { ff84:45155* prio 2 }
> process_csb: :00:02.0 bcs0: ring:{start:0x00178000, head:0928,
> tail:0928, ctl:, mode:0200}
> process_csb: :00:02.0 bcs0: rq:{start:00178000, head:08b0, tail:08f0,
> seqno:ff84:45155, hwsp:45156},
> process_csb: :00:02.0 bcs0: ctx:{start:00178000, head:e000928,
> tail:0928},
> process_csb: GEM_BUG_ON("context completed before request")
>
> In this sequence, we can see that although we have submitted the next
> request [ff84:45156] to HW (via ELSP[]) it has not yet reported the
> lite-restore. Instead, we see the completion event of the currently
> active request [ff85:45155] but at the time of processing that event,
> the breadcrumb has not yet been written. Though by the time we do print
> out the debug info, the seqno write of ff85:45156 has landed!
I see it.
But I have now a more generic confusion about the sequence:
why would the same context preempt itself?
> trace_ports: :00:02.0 bcs0: preempted { ff84:45154! prio 2 }
> trace_ports: :00:02.0 bcs0: promote { ff84:45155* prio 2 }
>
> Therefore there is a serialisation problem between the seqno writes and
> CS events, not just between the CS buffer and its head/tail pointers as
> previously observed on Icelake.
>
> This is not a huge problem, as we don't strictly rely on the breadcrumb
> to determine HW activity, but it may indicate that interrupt delivery is
> before the seqno write, aka bringing back the plague of missed
> interrupts from yesteryear. However, there is no indication of this
> wider problem, so let's just flush the seqno read before reporting an
> error. If it persists after the fresh read we can worry again.
Well you are preempting part of my concerns.
Still you will have a serialision point now only with debug builds.
So I assume the rest of the request completion flow is ambivalent of
intr seqno coherency and we can cope with this is only for debug...
Being in generic read hwsp path would be expensive and thus overkill?
Could we lift the flushing to the non show_debug path to be always
part of process_csb cycle?
-Mika
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 29 ++---
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 3d5f3f7677bb..afeca7eb1e3a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2418,8 +2418,6 @@ static void process_csb(struct intel_engine_cs *engine)
> if (promote) {
> struct i915_request * const *old = execlists->active;
>
> - GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
> -
> ring_set_paused(engine, 0);
>
> /* Point active to the new ELSP; prevent overwriting */
> @@ -2432,6 +2430,7 @@ static void process_csb(struct intel_engine_cs *engine)
> execlists_schedule_out(*old++);
>
> /* switch pending to inflight */
> + GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
> memcpy(execlists->inflight,
> execlists->pending,
> execlists_num_ports(execlists) *
> @@ -2453,13 +2452,26 @@ static void process_csb(struct intel_engine_cs
> *engine)
>* user interrupt and CSB is processed.
>*/
> if (GEM_SHOW_DEBUG() &&
> - !i915_request_completed(*execlists->active) &&
> - !reset_in_progress(execlists)) {
> - struct i915_request *rq __maybe_unused =
> - *execlists->active;
> + !i915_request_completed(*execlists->active)) {
> + struct i915_request *rq = *execlists->active;
> const u32 *regs __maybe_unused =
> rq->context->lrc_reg_state;
>
> + /*
> + * Flush the breadcrumb before crying foul.
> + *
> + * Since we have hit this on icl and seen the
> + * breadcrumb advance as we print out t
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Double check breadcrumb before crying foul
Quoting Mika Kuoppala (2020-03-31 08:50:54)
> Chris Wilson writes:
>
> > process_csb: :00:02.0 bcs0: cs-irq head=4, tail=5
> > process_csb: :00:02.0 bcs0: csb[5]: status=0x8002:0x6020
> > trace_ports: :00:02.0 bcs0: preempted { ff84:45154! prio 2 }
> > trace_ports: :00:02.0 bcs0: promote { ff84:45155* prio 2 }
> > trace_ports: :00:02.0 bcs0: submit { ff84:45156 prio 2 }
> >
> > process_csb: :00:02.0 bcs0: cs-irq head=5, tail=6
> > process_csb: :00:02.0 bcs0: csb[6]: status=0x0018:0x6020
> > trace_ports: :00:02.0 bcs0: completed { ff84:45155* prio 2 }
> > process_csb: :00:02.0 bcs0: ring:{start:0x00178000, head:0928,
> > tail:0928, ctl:, mode:0200}
> > process_csb: :00:02.0 bcs0: rq:{start:00178000, head:08b0, tail:08f0,
> > seqno:ff84:45155, hwsp:45156},
> > process_csb: :00:02.0 bcs0: ctx:{start:00178000, head:e000928,
> > tail:0928},
> > process_csb: GEM_BUG_ON("context completed before request")
> >
> > In this sequence, we can see that although we have submitted the next
> > request [ff84:45156] to HW (via ELSP[]) it has not yet reported the
> > lite-restore. Instead, we see the completion event of the currently
> > active request [ff85:45155] but at the time of processing that event,
> > the breadcrumb has not yet been written. Though by the time we do print
> > out the debug info, the seqno write of ff85:45156 has landed!
>
> I see it.
>
> But I have now a more generic confusion about the sequence:
> why would the same context preempt itself?
lite-restore continuations.
>
> > trace_ports: :00:02.0 bcs0: preempted { ff84:45154! prio 2 }
> > trace_ports: :00:02.0 bcs0: promote { ff84:45155* prio 2 }
>
> >
> > Therefore there is a serialisation problem between the seqno writes and
> > CS events, not just between the CS buffer and its head/tail pointers as
> > previously observed on Icelake.
> >
> > This is not a huge problem, as we don't strictly rely on the breadcrumb
> > to determine HW activity, but it may indicate that interrupt delivery is
> > before the seqno write, aka bringing back the plague of missed
> > interrupts from yesteryear. However, there is no indication of this
> > wider problem, so let's just flush the seqno read before reporting an
> > error. If it persists after the fresh read we can worry again.
>
> Well you are preempting part of my concerns.
>
> Still you will have a serialision point now only with debug builds.
We only check in debug.
> So I assume the rest of the request completion flow is ambivalent of
> intr seqno coherency and we can cope with this is only for debug...
Right.
> Being in generic read hwsp path would be expensive and thus overkill?
Very expensive. There's no evidence that the GPU is that broken that it
returns garbage in a *cached* CPU read.
> Could we lift the flushing to the non show_debug path to be always
> part of process_csb cycle?
No. What would be the point? The breadcrumb is not part of the CS flow.
The debug is our sanitycheck that the two events are ordered, but that
is not a strict requirement of the code. If it fails this test, the
presumption is that either the GPU is very dead (e.g. the GO problem,
RING_HEAD/TAIL issues, a variety of other means of killing the gpu) and
the problem will remain, or that we have a programming error, which
again will not resolve itself as we print the debug.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: do AUD_FREQ_CNTRL state save on all gen9+ platforms (rev2)
== Series Details == Series: drm/i915: do AUD_FREQ_CNTRL state save on all gen9+ platforms (rev2) URL : https://patchwork.freedesktop.org/series/74664/ State : success == Summary == CI Bug Log - changes from CI_DRM_8218_full -> Patchwork_17136_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17136_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112146]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-iclb8/igt@gem_exec_as...@concurrent-writes-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-iclb7/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-iclb6/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_wait@busy-vcs1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112080]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-iclb4/igt@gem_w...@busy-vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-iclb7/igt@gem_w...@busy-vcs1.html * igt@i915_pm_rps@min-max-config-loaded: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#39]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-glk4/igt@i915_pm_...@min-max-config-loaded.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-glk9/igt@i915_pm_...@min-max-config-loaded.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-kbl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-kbl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#221]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-skl1/igt@kms_f...@flip-vs-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-skl5/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-apl6/igt@kms_frontbuffer_track...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-apl1/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8218/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17136/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_cursor
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Double check breadcrumb before crying foul
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-03-31 08:50:54)
>> Chris Wilson writes:
>>
>> > process_csb: :00:02.0 bcs0: cs-irq head=4, tail=5
>> > process_csb: :00:02.0 bcs0: csb[5]: status=0x8002:0x6020
>> > trace_ports: :00:02.0 bcs0: preempted { ff84:45154! prio 2 }
>> > trace_ports: :00:02.0 bcs0: promote { ff84:45155* prio 2 }
>> > trace_ports: :00:02.0 bcs0: submit { ff84:45156 prio 2 }
>> >
>> > process_csb: :00:02.0 bcs0: cs-irq head=5, tail=6
>> > process_csb: :00:02.0 bcs0: csb[6]: status=0x0018:0x6020
>> > trace_ports: :00:02.0 bcs0: completed { ff84:45155* prio 2 }
>> > process_csb: :00:02.0 bcs0: ring:{start:0x00178000, head:0928,
>> > tail:0928, ctl:, mode:0200}
>> > process_csb: :00:02.0 bcs0: rq:{start:00178000, head:08b0,
>> > tail:08f0, seqno:ff84:45155, hwsp:45156},
>> > process_csb: :00:02.0 bcs0: ctx:{start:00178000, head:e000928,
>> > tail:0928},
>> > process_csb: GEM_BUG_ON("context completed before request")
>> >
>> > In this sequence, we can see that although we have submitted the next
>> > request [ff84:45156] to HW (via ELSP[]) it has not yet reported the
>> > lite-restore. Instead, we see the completion event of the currently
>> > active request [ff85:45155] but at the time of processing that event,
>> > the breadcrumb has not yet been written. Though by the time we do print
>> > out the debug info, the seqno write of ff85:45156 has landed!
>>
>> I see it.
>>
>> But I have now a more generic confusion about the sequence:
>> why would the same context preempt itself?
>
> lite-restore continuations.
>
>>
>> > trace_ports: :00:02.0 bcs0: preempted { ff84:45154! prio 2 }
>> > trace_ports: :00:02.0 bcs0: promote { ff84:45155* prio 2 }
>>
>> >
>> > Therefore there is a serialisation problem between the seqno writes and
>> > CS events, not just between the CS buffer and its head/tail pointers as
>> > previously observed on Icelake.
>> >
>> > This is not a huge problem, as we don't strictly rely on the breadcrumb
>> > to determine HW activity, but it may indicate that interrupt delivery is
>> > before the seqno write, aka bringing back the plague of missed
>> > interrupts from yesteryear. However, there is no indication of this
>> > wider problem, so let's just flush the seqno read before reporting an
>> > error. If it persists after the fresh read we can worry again.
>>
>> Well you are preempting part of my concerns.
>>
>> Still you will have a serialision point now only with debug builds.
>
> We only check in debug.
>
>> So I assume the rest of the request completion flow is ambivalent of
>> intr seqno coherency and we can cope with this is only for debug...
>
> Right.
>
>> Being in generic read hwsp path would be expensive and thus overkill?
>
> Very expensive. There's no evidence that the GPU is that broken that it
> returns garbage in a *cached* CPU read.
>
>> Could we lift the flushing to the non show_debug path to be always
>> part of process_csb cycle?
>
> No. What would be the point? The breadcrumb is not part of the CS flow.
> The debug is our sanitycheck that the two events are ordered, but that
> is not a strict requirement of the code. If it fails this test, the
> presumption is that either the GPU is very dead (e.g. the GO problem,
> RING_HEAD/TAIL issues, a variety of other means of killing the gpu) and
> the problem will remain, or that we have a programming error, which
> again will not resolve itself as we print the debug.
Agreed that there is no point if it is for forcing a fresh
read only for debug. Concern was that it affects the
validity for other reads.
But you amended that on the commit message, preemptively.
So,
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/execlists: Peek at the next submission for error interrupts
If we receive the error interrupt before the CS interrupt, we may find
ourselves without an active request to reset, skipping the GPU reset.
All because the attempt to reset was too early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 9e18c0896a83..97ed8275659a 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2790,6 +2790,45 @@ static struct execlists_capture *capture_regs(struct
intel_engine_cs *engine)
return NULL;
}
+static struct i915_request *
+active_context(struct intel_engine_cs *engine, u32 ccid)
+{
+ const struct intel_engine_execlists * const el = &engine->execlists;
+ struct i915_request * const *port, *rq;
+
+ /*
+* Use the most recent result from process_csb(), but just in case
+* we trigger an error (via interrupt) before the first CS event has
+* been written, peek at the next submission.
+*/
+
+ for (port = el->active; (rq = *port); port++) {
+ if (upper_32_bits(rq->context->lrc_desc) == ccid) {
+ ENGINE_TRACE(engine,
+"ccid found at active:%zd\n",
+port - el->active);
+ return rq;
+ }
+ }
+
+ for (port = el->pending; (rq = *port); port++) {
+ if (upper_32_bits(rq->context->lrc_desc) == ccid) {
+ ENGINE_TRACE(engine,
+"ccid found at pending:%zd\n",
+port - el->pending);
+ return rq;
+ }
+ }
+
+ ENGINE_TRACE(engine, "ccid:%x not found\n", ccid);
+ return NULL;
+}
+
+static u32 active_ccid(struct intel_engine_cs *engine)
+{
+ return ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI);
+}
+
static bool execlists_capture(struct intel_engine_cs *engine)
{
struct execlists_capture *cap;
@@ -2807,7 +2846,7 @@ static bool execlists_capture(struct intel_engine_cs
*engine)
return true;
spin_lock_irq(&engine->active.lock);
- cap->rq = execlists_active(&engine->execlists);
+ cap->rq = active_context(engine, active_ccid(engine));
if (cap->rq) {
cap->rq = active_request(cap->rq->context->timeline, cap->rq);
cap->rq = i915_request_get_rcu(cap->rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/execlists: Pause CS flow before reset
Since we may be attempting to reset an active engine, we try to freeze it in place before resetting -- to be on the safe side. We can go one step further if we are using the CS flow semaphore to prevent the context switching into the next. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 9fff4e02cee6..9e18c0896a83 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -3669,6 +3669,7 @@ static void execlists_reset_prepare(struct intel_engine_cs *engine) * * FIXME: Wa for more modern gens needs to be validated */ + ring_set_paused(engine, 1); intel_engine_stop_cs(engine); } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/selftests: Tidy up an error message for live_error_interrupt
Since we don't wait for the error interrupt to reset, restart and then
complete the guilty request, clean up the error messages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index d3e163c93e22..b929e52a8f5a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -649,9 +649,9 @@ static int live_error_interrupt(void *arg)
error_repr(p->error[i]));
if (!i915_request_started(client[i])) {
- pr_debug("%s: %s request not stated!\n",
-engine->name,
-error_repr(p->error[i]));
+ pr_err("%s: %s request not started!\n",
+ engine->name,
+ error_repr(p->error[i]));
err = -ETIME;
goto out;
}
@@ -659,9 +659,10 @@ static int live_error_interrupt(void *arg)
/* Kick the tasklet to process the error */
intel_engine_flush_submission(engine);
if (client[i]->fence.error != p->error[i]) {
- pr_err("%s: %s request completed with
wrong error code: %d\n",
+ pr_err("%s: %s request (%s) with wrong
error code: %d\n",
engine->name,
error_repr(p->error[i]),
+
i915_request_completed(client[i]) ? "completed" : "running",
client[i]->fence.error);
err = -EINVAL;
goto out;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/execlists: Record the active CCID from before reset
If we cannot trust the reset will flush out the CS event queue such that
process_csb() reports an accurate view of HW, we will need to search the
active and pending contexts to determine which was actually running at
the time we issued the reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 80cdde712842..4804587442e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -166,6 +166,11 @@ struct intel_engine_execlists {
*/
u32 error_interrupt;
+ /**
+* @reset_ccid: Active CCID [EXECLISTS_STATUS_HI] at the time of reset
+*/
+ u32 reset_ccid;
+
/**
* @no_priolist: priority lists disabled
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 97ed8275659a..744737e57d1d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3710,6 +3710,8 @@ static void execlists_reset_prepare(struct
intel_engine_cs *engine)
*/
ring_set_paused(engine, 1);
intel_engine_stop_cs(engine);
+
+ engine->execlists.reset_ccid = active_ccid(engine);
}
static void reset_csb_pointers(struct intel_engine_cs *engine)
@@ -3784,7 +3786,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
* its request, it was still running at the time of the
* reset and will have been clobbered.
*/
- rq = execlists_active(execlists);
+ rq = active_context(engine, engine->execlists.reset_ccid);
if (!rq)
goto unwind;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for tests/kms_plane_alpha_blend: Correct typo in the name and comments of a subtest
== Series Details ==
Series: tests/kms_plane_alpha_blend: Correct typo in the name and comments of a
subtest
URL : https://patchwork.freedesktop.org/series/75273/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8219_full -> IGTPW_4376_full
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in IGTPW_4376_full:
### IGT changes ###
Possible regressions
* {igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb} (NEW):
- shard-glk: NOTRUN -> [FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-glk2/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
- shard-apl: NOTRUN -> [FAIL][2] +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-apl6/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
* {igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb} (NEW):
- shard-kbl: NOTRUN -> [FAIL][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-kbl7/igt@kms_plane_alpha_bl...@pipe-c-alpha-transparent-fb.html
New tests
-
New tests have been introduced between CI_DRM_8219_full and IGTPW_4376_full:
### New IGT tests (4) ###
* igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
- Statuses : 3 fail(s) 2 pass(s) 2 skip(s)
- Exec time: [0.0, 1.58] s
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- Statuses : 3 fail(s) 2 pass(s) 2 skip(s)
- Exec time: [0.0, 2.62] s
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
- Statuses : 2 fail(s) 2 pass(s) 2 skip(s)
- Exec time: [0.0, 2.67] s
* igt@kms_plane_alpha_blend@pipe-d-alpha-transparent-fb:
- Statuses : 1 pass(s) 6 skip(s)
- Exec time: [0.0, 2.16] s
Known issues
Here are the changes found in IGTPW_4376_full that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#112080]) +10 similar
issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-iclb6/igt@gem_b...@busy-vcs1.html
* igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109276] / [i915#677]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd1.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#109276]) +10 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-iclb5/igt@gem_exec_sched...@independent-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#677]) +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#112146]) +5 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#1527])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk8/igt@i915_pm_rc6_reside...@rc6-idle.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-glk2/igt@i915_pm_rc6_reside...@rc6-idle.html
* igt@i915_selftest@live@requests:
- shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([i915#1531])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-tglb5/igt@i915_selftest@l...@requests.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-tglb2/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +2
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl3/igt@i915_susp...@fence-restore-untiled.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4376/shard-kbl1/igt@i915_s
[Intel-gfx] ✓ Fi.CI.IGT: success for lib/igt_fb: change comments with fd description
== Series Details == Series: lib/igt_fb: change comments with fd description URL : https://patchwork.freedesktop.org/series/75274/ State : success == Summary == CI Bug Log - changes from CI_DRM_8219_full -> IGTPW_4377_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/index.html Known issues Here are the changes found in IGTPW_4377_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl7/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-apl4/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@implicit-write-read-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@implicit-write-read-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-iclb1/igt@gem_exec_sched...@implicit-write-read-bsd.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +9 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-iclb7/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-vebox: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([i915#1193]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl7/igt@gem_exec_sched...@pi-shared-iova-vebox.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-apl2/igt@gem_exec_sched...@pi-shared-iova-vebox.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#54] / [i915#93] / [i915#95]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-128x128-offscreen.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-128x128-offscreen.html * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-untiled: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#52] / [i915#54]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk9/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-glk8/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-untiled.html * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: - shard-kbl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#177] / [i915#52] / [i915#54] / [i915#93] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-kbl1/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html - shard-apl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#52] / [i915#54] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl2/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-apl7/igt@kms_draw_...@draw-method-xrgb-mmap-wc-untiled.html * igt@kms_fbcon_fbt@fbc: - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#64]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl4/igt@kms_fbcon_...@fbc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-kbl7/igt@kms_fbcon_...@fbc.html - shard-apl: [PASS][23] -> [FAIL][24] ([i915#1525]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl6/igt@kms_fbcon_...@fbc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4377/shard-apl6/igt@kms_fbcon_...@fbc.html * igt@kms_flip@2x-plain-flip-ts-check: - shard
[Intel-gfx] [PATCH] drm/i915/gt: Include the execlists CCID of each port in the engine dump
Since we print out EXECLISTS_STATUS in the dump, also print out the CCID
of each context so we can cross check between the two.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 105 --
1 file changed, 56 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index dff0bbe9e1a6..b01af08eaaf7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1221,6 +1221,49 @@ static void print_request(struct drm_printer *m,
name);
}
+static struct intel_timeline *get_timeline(struct i915_request *rq)
+{
+ struct intel_timeline *tl;
+
+ /*
+* Even though we are holding the engine->active.lock here, there
+* is no control over the submission queue per-se and we are
+* inspecting the active state at a random point in time, with an
+* unknown queue. Play safe and make sure the timeline remains valid.
+* (Only being used for pretty printing, one extra kref shouldn't
+* cause a camel stampede!)
+*/
+ rcu_read_lock();
+ tl = rcu_dereference(rq->timeline);
+ if (!kref_get_unless_zero(&tl->kref))
+ tl = NULL;
+ rcu_read_unlock();
+
+ return tl;
+}
+
+static int print_ring(char *buf, int sz, struct i915_request *rq)
+{
+ int len = 0;
+
+ if (!i915_request_signaled(rq)) {
+ struct intel_timeline *tl = get_timeline(rq);
+
+ len = scnprintf(buf, sz,
+ "ring:{start:%08x, hwsp:%08x, seqno:%08x,
runtime:%llums}, ",
+ i915_ggtt_offset(rq->ring->vma),
+ tl ? tl->hwsp_offset : 0,
+ hwsp_seqno(rq),
+
DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
+ 1000 * 1000));
+
+ if (tl)
+ intel_timeline_put(tl);
+ }
+
+ return len;
+}
+
static void hexdump(struct drm_printer *m, const void *buf, size_t len)
{
const size_t rowsize = 8 * sizeof(u32);
@@ -1250,27 +1293,6 @@ static void hexdump(struct drm_printer *m, const void
*buf, size_t len)
}
}
-static struct intel_timeline *get_timeline(struct i915_request *rq)
-{
- struct intel_timeline *tl;
-
- /*
-* Even though we are holding the engine->active.lock here, there
-* is no control over the submission queue per-se and we are
-* inspecting the active state at a random point in time, with an
-* unknown queue. Play safe and make sure the timeline remains valid.
-* (Only being used for pretty printing, one extra kref shouldn't
-* cause a camel stampede!)
-*/
- rcu_read_lock();
- tl = rcu_dereference(rq->timeline);
- if (!kref_get_unless_zero(&tl->kref))
- tl = NULL;
- rcu_read_unlock();
-
- return tl;
-}
-
static const char *repr_timer(const struct timer_list *t)
{
if (!READ_ONCE(t->expires))
@@ -1383,39 +1405,24 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
int len;
len = scnprintf(hdr, sizeof(hdr),
- "\t\tActive[%d]: ",
- (int)(port - execlists->active));
- if (!i915_request_signaled(rq)) {
- struct intel_timeline *tl = get_timeline(rq);
-
- len += scnprintf(hdr + len, sizeof(hdr) - len,
-"ring:{start:%08x, hwsp:%08x,
seqno:%08x, runtime:%llums}, ",
-
i915_ggtt_offset(rq->ring->vma),
-tl ? tl->hwsp_offset : 0,
-hwsp_seqno(rq),
-
DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
- 1000 *
1000));
-
- if (tl)
- intel_timeline_put(tl);
- }
+ "\t\tActive[%d]: ccid:%08x, ",
+ (int)(port - execlists->active),
+ upper_32_bits(rq->context->lrc_desc));
+ len += print_ring(hdr + len, sizeof(hdr) - len, rq);
scnprintf(hdr + len, sizeof(hdr) - len, "rq: ");
print_request(m, rq, hdr);
}
for (port = execlists->pending; (rq = *port); port++) {
- struct intel_timeline *tl = get_
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_alpha_blend: Correct typo in the name and comments of a subtest
On Mon, Mar 30, 2020 at 06:55:32PM -0300, Melissa Wen wrote: > Typo found in word transparent. > Correct the word transparant, replacing the last letter -a- with -e- > (transpar-a-nt to transpar-e-nt). > > Signed-off-by: Melissa Wen Reviewed-by: Petri Latvala Martin, test rename, ack when cibuglog side is ready to merge this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_fb: change comments with fd description
On Mon, Mar 30, 2020 at 06:56:36PM -0300, Melissa Wen wrote: > Generalize description of fd since it is not restricted to i915 driver fd > > Signed-off-by: Melissa Wen Reviewed-by: Petri Latvala Please send future IGT patches to igt-...@lists.freedesktop.org please. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode
== Series Details == Series: drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode URL : https://patchwork.freedesktop.org/series/75253/ State : success == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17137_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17137_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb5/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#46]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl10/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][15] -> [FAIL][16] ([i915#46]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#648] / [i915#69]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb6/igt@kms_psr@psr2_sprite_render.html * igt@kms_setmode@basic: -
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: Update CP as per the kernel internal state (rev3)
== Series Details == Series: drm/i915/hdcp: Update CP as per the kernel internal state (rev3) URL : https://patchwork.freedesktop.org/series/72251/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17139_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17139_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17139_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17139_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - shard-tglb: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-tglb5/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-tglb5/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17139_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@implicit-write-read-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-write-read-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-iclb6/igt@gem_exec_sched...@implicit-write-read-bsd1.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-iclb1/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-iclb6/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][11] -> [TIMEOUT][12] ([i915#1526]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-snb4/igt@i915_pm_rc6_reside...@rc6-idle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_selftest@live@execlists: - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#656]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl4/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-apl3/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17139/shard
[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Add request throughput measurement to perf
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c | 590 +-
2 files changed, 590 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
index 3bf7f53e9924..d8da142985eb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
@@ -16,5 +16,6 @@
* Tests are executed in order by igt/i915_selftest
*/
selftest(engine_cs, intel_engine_cs_perf_selftests)
+selftest(request, i915_request_perf_selftests)
selftest(blt, i915_gem_object_blt_perf_selftests)
selftest(region, intel_memory_region_perf_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 1dab0360f76a..3cf0599cec4b 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include "gem/i915_gem_pm.h"
#include "gem/selftests/mock_context.h"
@@ -1239,7 +1240,7 @@ static int live_parallel_engines(void *arg)
struct igt_live_test t;
unsigned int idx;
- snprintf(name, sizeof(name), "%ps", fn);
+ snprintf(name, sizeof(name), "%ps", *fn);
err = igt_live_test_begin(&t, i915, __func__, name);
if (err)
break;
@@ -1476,3 +1477,590 @@ int i915_request_live_selftests(struct drm_i915_private
*i915)
return i915_subtests(tests, i915);
}
+
+static int switch_to_kernel_sync(struct intel_context *ce, int err)
+{
+ struct i915_request *rq;
+ struct dma_fence *fence;
+
+ rq = intel_engine_create_kernel_request(ce->engine);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ fence = i915_active_fence_get(&ce->timeline->last_request);
+ if (fence) {
+ i915_request_await_dma_fence(rq, fence);
+ dma_fence_put(fence);
+ }
+
+ rq = i915_request_get(rq);
+ i915_request_add(rq);
+ if (i915_request_wait(rq, 0, HZ / 2) < 0 && !err)
+ err = -ETIME;
+ i915_request_put(rq);
+
+ while (!err && !intel_engine_is_idle(ce->engine))
+ intel_engine_flush_submission(ce->engine);
+
+ return err;
+}
+
+struct perf_stats {
+ struct intel_engine_cs *engine;
+ unsigned long count;
+ ktime_t time;
+ ktime_t busy;
+ u64 runtime;
+};
+
+struct perf_series {
+ struct drm_i915_private *i915;
+ unsigned int nengines;
+ struct intel_context *ce[];
+};
+
+static int s_sync0(void *arg)
+{
+ struct perf_series *ps = arg;
+ IGT_TIMEOUT(end_time);
+ unsigned int idx = 0;
+ int err = 0;
+
+ GEM_BUG_ON(!ps->nengines);
+ do {
+ struct i915_request *rq;
+
+ rq = i915_request_create(ps->ce[idx]);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ break;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ break;
+
+ if (++idx == ps->nengines)
+ idx = 0;
+ } while (!__igt_timeout(end_time, NULL));
+
+ return err;
+}
+
+static int s_sync1(void *arg)
+{
+ struct perf_series *ps = arg;
+ struct i915_request *prev = NULL;
+ IGT_TIMEOUT(end_time);
+ unsigned int idx = 0;
+ int err = 0;
+
+ GEM_BUG_ON(!ps->nengines);
+ do {
+ struct i915_request *rq;
+
+ rq = i915_request_create(ps->ce[idx]);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ break;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (prev && i915_request_wait(prev, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(prev);
+ prev = rq;
+ if (err)
+ break;
+
+ if (++idx == ps->nengines)
+ idx = 0;
+ } while (!__igt_timeout(end_time, NULL));
+ i915_request_put(prev);
+
+ return err;
+}
+
+static int s_many(void *arg)
+{
+ struct perf_series *ps = arg;
+ IGT_TIMEOUT(end_time);
+ unsigned int idx = 0;
+
+ GEM_BUG_ON(!ps->nengines);
+ do {
+
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 40 +---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
6 files changed, 67 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index dff0bbe9e1a6..6ac8d0022deb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1291,6 +1291,12 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
if (engine->id == RENDER_CLASS && IS_GEN_RANGE(dev_priv, 4, 7))
drm_printf(m, "\tCCID: 0x%08x\n", ENGINE_READ(engine, CCID));
+ if (HAS_EXECLISTS(dev_priv)) {
+ drm_printf(m, "\tEL_STAT_HI: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_HI));
+ drm_printf(m, "\tEL_STAT_LO: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_LO));
+ }
drm_printf(m, "\tRING_START: 0x%08x\n",
ENGINE_READ(engine, RING_START));
drm_printf(m, "\tRING_HEAD: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 80cdde712842..ac283ab5d89c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -156,6 +156,15 @@ struct intel_engine_execlists {
*/
struct i915_priolist default_priolist;
+ /**
+* @yield: CCID at the time of the last semaphore-wait interrupt.
+*
+* Instead of leaving a semaphore busy-spinning on an engine, we would
+* like to switch to another ready context, i.e. yielding the semaphore
+* timeslice.
+*/
+ u32 yield;
+
/**
* @error_interrupt: CS Master EIR
*
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f0e7fd95165a..875bd0392ffc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -39,6 +39,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
}
}
+ if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
+ WRITE_ONCE(engine->execlists.yield,
+ ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI));
+ if (del_timer(&engine->execlists.timer))
+ tasklet = true;
+ }
+
if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
tasklet = true;
@@ -228,7 +235,8 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
const u32 dmask = irqs << 16 | irqs;
const u32 smask = irqs << 16;
@@ -366,7 +374,8 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
const u32 gt_interrupts[] = {
irqs << GEN8_RCS_IRQ_SHIFT | irqs << GEN8_BCS_IRQ_SHIFT,
irqs << GEN8_VCS0_IRQ_SHIFT | irqs << G
[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce drm scaling filter property (rev4)
== Series Details == Series: Introduce drm scaling filter property (rev4) URL : https://patchwork.freedesktop.org/series/73883/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17140_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17140_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17140_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17140_full: ### IGT changes ### Possible regressions * igt@gem_ctx_ringsize@idle@bcs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl1/igt@gem_ctx_ringsize@i...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-skl9/igt@gem_ctx_ringsize@i...@bcs0.html Known issues Here are the changes found in Patchwork_17140_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@pi-shared-iova-render: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1193]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb8/igt@gem_exec_sched...@pi-shared-iova-render.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +12 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb1/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb8/igt@i915_pm...@dc6-psr.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb2/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#300]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl3/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17140/shard-skl2/igt@kms_setm...@basic.html * igt@perf_pmu@busy-check-all-vcs1: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#112080]) +9 simil
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/todo: Add todo to make i915 WARN* calls drm device specific (rev2)
== Series Details == Series: drm/todo: Add todo to make i915 WARN* calls drm device specific (rev2) URL : https://patchwork.freedesktop.org/series/75265/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17141_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17141_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17141_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17141_full: ### IGT changes ### Possible regressions * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-snb4/igt@i915_pm_rc6_reside...@rc6-idle.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-snb1/igt@i915_pm_rc6_reside...@rc6-idle.html Known issues Here are the changes found in Patchwork_17141_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-iclb5/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-iclb6/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb2/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-iclb6/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#1527]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk8/igt@i915_pm_rc6_reside...@rc6-idle.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-glk2/igt@i915_pm_rc6_reside...@rc6-idle.html - shard-hsw: [PASS][15] -> [TIMEOUT][16] ([i915#1526]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-idle.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-hsw4/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl4/igt@i915_susp...@debugfs-reader.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-kbl4/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl7/igt@kms_cursor_...@pipe-b-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-apl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#72]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17141/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_fbcon_fbt@fbc-suspend: -
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Check for bonding support before exercising
Don't bother trying and failing to test bonding if the kernel doesn't
even support it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
tests/i915/gem_exec_balancer.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index da8aff6de..9930e394d 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1936,6 +1936,22 @@ static bool has_load_balancer(int i915)
return err == 0;
}
+static bool has_bonding(int i915)
+{
+ I915_DEFINE_CONTEXT_ENGINES_BOND(bonds, 0) = {
+ .base.name = I915_CONTEXT_ENGINES_EXT_BOND,
+ };
+ struct i915_engine_class_instance ci = {};
+ uint32_t ctx;
+ int err;
+
+ ctx = gem_context_create(i915);
+ err = __set_load_balancer(i915, ctx, &ci, 1, &bonds);
+ gem_context_destroy(i915, ctx);
+
+ return err == 0;
+}
+
igt_main
{
int i915 = -1;
@@ -1992,11 +2008,18 @@ igt_main
igt_subtest("smoke")
smoketest(i915, 20);
- igt_subtest("bonded-imm")
- bonded(i915, 0);
+ igt_subtest_group {
+ igt_fixture igt_require(has_bonding(i915));
+
+ igt_subtest("bonded-imm")
+ bonded(i915, 0);
+
+ igt_subtest("bonded-cork")
+ bonded(i915, CORK);
- igt_subtest("bonded-cork")
- bonded(i915, CORK);
+ igt_subtest("bonded-early")
+ bonded_early(i915);
+ }
igt_subtest("bonded-slice")
bonded_slice(i915);
@@ -2007,9 +2030,6 @@ igt_main
igt_subtest("bonded-semaphore")
bonded_semaphore(i915);
- igt_subtest("bonded-early")
- bonded_early(i915);
-
igt_fixture {
igt_stop_hang_detector();
}
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915/dp: Return the right vswing tables
== Series Details == Series: series starting with [v2,1/3] drm/i915/dp: Return the right vswing tables URL : https://patchwork.freedesktop.org/series/75268/ State : success == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17142_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17142_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-iclb6/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-iclb4/igt@gem_exec_sched...@wide-bsd.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#1527]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk8/igt@i915_pm_rc6_reside...@rc6-idle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-glk9/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#72]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-glk: [PASS][15] -> [INCOMPLETE][16] ([i915#58] / [k.org#198133]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@2x-plain-flip-ts-check: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#34]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk7/igt@kms_f...@2x-plain-flip-ts-check.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-glk2/igt@kms_f...@2x-plain-flip-ts-check.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render: - shard-tglb: [PASS][19] -> [SKIP][20] ([i915#668]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-render.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl1/igt@kms_...@bpc-switch-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-kbl7/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#69]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17142/shard-skl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-a-c
[Intel-gfx] [PATCH 19/23] drm/i915: Use ww pinning for intel_context_create_request()
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5c7acddf9651..f70135685552 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -450,15 +450,25 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce)
{
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
int err;
- err = intel_context_pin(ce);
- if (unlikely(err))
- return ERR_PTR(err);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = intel_context_pin_ww(ce, &ww);
+ if (!err) {
+ rq = i915_request_create(ce);
+ intel_context_unpin(ce);
+ } else if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ } else {
+ rq = ERR_PTR(err);
+ }
- rq = i915_request_create(ce);
- intel_context_unpin(ce);
+ i915_gem_ww_ctx_fini(&ww);
if (IS_ERR(rq))
return rq;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/23] Revert "drm/i915/gem: Split eb_vma into its own allocation"
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 131 --
1 file changed, 58 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bd8364197da1..55b06d7a1329 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -40,11 +40,6 @@ struct eb_vma {
u32 handle;
};
-struct eb_vma_array {
- struct kref kref;
- struct eb_vma vma[];
-};
-
enum {
FORCE_CPU_RELOC = 1,
FORCE_GTT_RELOC,
@@ -57,6 +52,7 @@ enum {
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
+#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
@@ -287,7 +283,6 @@ struct i915_execbuffer {
*/
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
- struct eb_vma_array *array;
};
static int eb_parse(struct i915_execbuffer *eb);
@@ -299,62 +294,8 @@ static inline bool eb_use_cmdparser(const struct
i915_execbuffer *eb)
eb->args->batch_len);
}
-static struct eb_vma_array *eb_vma_array_create(unsigned int count)
-{
- struct eb_vma_array *arr;
-
- arr = kvmalloc(struct_size(arr, vma, count), GFP_KERNEL | __GFP_NOWARN);
- if (!arr)
- return NULL;
-
- kref_init(&arr->kref);
- arr->vma[0].vma = NULL;
-
- return arr;
-}
-
-static inline void eb_unreserve_vma(struct eb_vma *ev)
-{
- struct i915_vma *vma = ev->vma;
-
- if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- if (ev->flags & __EXEC_OBJECT_HAS_PIN)
- __i915_vma_unpin(vma);
-
- ev->flags &= ~(__EXEC_OBJECT_HAS_PIN |
- __EXEC_OBJECT_HAS_FENCE);
-}
-
-static void eb_vma_array_destroy(struct kref *kref)
-{
- struct eb_vma_array *arr = container_of(kref, typeof(*arr), kref);
- struct eb_vma *ev = arr->vma;
-
- while (ev->vma) {
- eb_unreserve_vma(ev);
- i915_vma_put(ev->vma);
- ev++;
- }
-
- kvfree(arr);
-}
-
-static void eb_vma_array_put(struct eb_vma_array *arr)
-{
- kref_put(&arr->kref, eb_vma_array_destroy);
-}
-
static int eb_create(struct i915_execbuffer *eb)
{
- /* Allocate an extra slot for use by the command parser + sentinel */
- eb->array = eb_vma_array_create(eb->buffer_count + 2);
- if (!eb->array)
- return -ENOMEM;
-
- eb->vma = eb->array->vma;
-
if (!(eb->args->flags & I915_EXEC_HANDLE_LUT)) {
unsigned int size = 1 + ilog2(eb->buffer_count);
@@ -388,10 +329,8 @@ static int eb_create(struct i915_execbuffer *eb)
break;
} while (--size);
- if (unlikely(!size)) {
- eb_vma_array_put(eb->array);
+ if (unlikely(!size))
return -ENOMEM;
- }
eb->lut_size = size;
} else {
@@ -465,6 +404,26 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
+static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
+{
+ GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
+
+ if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(vma);
+
+ __i915_vma_unpin(vma);
+}
+
+static inline void
+eb_unreserve_vma(struct eb_vma *ev)
+{
+ if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
+ return;
+
+ __eb_unreserve_vma(ev->vma, ev->flags);
+ ev->flags &= ~__EXEC_OBJECT_RESERVED;
+}
+
static int
eb_validate_vma(struct i915_execbuffer *eb,
struct drm_i915_gem_exec_object2 *entry,
@@ -926,13 +885,31 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned
long handle)
}
}
+static void eb_release_vmas(const struct i915_execbuffer *eb)
+{
+ const unsigned int count = eb->buffer_count;
+ unsigned int i;
+
+ for (i = 0; i < count; i++) {
+ struct eb_vma *ev = &eb->vma[i];
+ struct i915_vma *vma = ev->vma;
+
+ if (!vma)
+ break;
+
+ eb->vma[i].vma = NULL;
+
+ if (ev->flags & __EXEC_OBJECT_HAS_PIN)
+ __eb_unreserve_vma(vma, ev->flags);
+
+ i915_vma_put(vma);
+ }
+}
+
static v
[Intel-gfx] [PATCH 09/23] drm/i915: Add ww context handling to context_barrier_task
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ac2b88ca00ce..062848951095 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1097,6 +1097,7 @@ I915_SELFTEST_DECLARE(static intel_engine_mask_t
context_barrier_inject_fault);
static int context_barrier_task(struct i915_gem_context *ctx,
intel_engine_mask_t engines,
bool (*skip)(struct intel_context *ce, void
*data),
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
int (*emit)(struct i915_request *rq, void
*data),
void (*task)(void *data),
void *data)
@@ -1104,6 +1105,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
struct i915_gem_engines *e;
+ struct i915_gem_ww_ctx ww;
struct intel_context *ce;
int err = 0;
@@ -1141,10 +1143,21 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (skip && skip(ce, data))
continue;
- rq = intel_context_create_request(ce);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ if (pin)
+ err = pin(ce, &ww, data);
+ if (err)
+ goto err_unpin;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- break;
+ goto err_unpin;
}
err = 0;
@@ -1154,6 +1167,16 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
err = i915_active_add_request(&cb->base, rq);
i915_request_add(rq);
+err_unpin:
+ intel_context_unpin(ce);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
if (err)
break;
}
@@ -1209,6 +1232,17 @@ static void set_ppgtt_barrier(void *data)
i915_vm_close(old);
}
+static int pin_ppgtt_update(struct intel_context *ce, struct i915_gem_ww_ctx
*ww, void *data)
+{
+ struct i915_address_space *vm = ce->vm;
+
+ if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
+ /* ppGTT is not part of the legacy context image */
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+
+ return 0;
+}
+
static int emit_ppgtt_update(struct i915_request *rq, void *data)
{
struct i915_address_space *vm = rq->context->vm;
@@ -1265,20 +1299,10 @@ static int emit_ppgtt_update(struct i915_request *rq,
void *data)
static bool skip_ppgtt_update(struct intel_context *ce, void *data)
{
- if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
- return true;
-
if (HAS_LOGICAL_RING_CONTEXTS(ce->engine->i915))
- return false;
-
- if (!atomic_read(&ce->pin_count))
- return true;
-
- /* ppGTT is not part of the legacy context image */
- if (gen6_ppgtt_pin(i915_vm_to_ppgtt(ce->vm)))
- return true;
-
- return false;
+ return !ce->state;
+ else
+ return !atomic_read(&ce->pin_count);
}
static int set_ppgtt(struct drm_i915_file_private *file_priv,
@@ -1329,6 +1353,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
*/
err = context_barrier_task(ctx, ALL_ENGINES,
skip_ppgtt_update,
+ pin_ppgtt_update,
emit_ppgtt_update,
set_ppgtt_barrier,
old);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 42edbd0f3c14..78356031ec61 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1903,8 +1903,8 @@ static int mock_context_barrier(void *arg)
return -ENOMEM;
counter = 0;
- err = context_barrier_task(ctx, 0,
-
[Intel-gfx] [PATCH 17/23] drm/i915: Dirty hack to fix selftests locking inversion
Some i915 selftests still use i915_vma_lock() as inner lock, and intel_context_create_request() intel_timeline->mutex as outer lock. Fortunately for selftests this is not an issue, they should be fixed but we can move ahead and cleanify lockdep now. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 113d0bda1bcf..5c7acddf9651 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -460,6 +460,18 @@ struct i915_request *intel_context_create_request(struct intel_context *ce) rq = i915_request_create(ce); intel_context_unpin(ce); + if (IS_ERR(rq)) + return rq; + + /* +* timeline->mutex should be the inner lock, but is used as outer lock. +* Hack around this to shut up lockdep in selftests.. +*/ + lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie); + mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_); + mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, _RET_IP_); + rq->cookie = lockdep_pin_lock(&ce->timeline->mutex); + return rq; } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/23] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v2.
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/gpu/drm/i915/selftests/i915_request.c | 18 +---
3 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 99f8466a108a..d93b7d9ad174 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -199,25 +199,25 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
i915_gem_object_lock(ctx->obj, NULL);
err = i915_gem_object_set_to_gtt_domain(ctx->obj, true);
- i915_gem_object_unlock(ctx->obj);
if (err)
- return err;
+ goto out_unlock;
vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_unlock;
+ }
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto out_unpin;
}
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
- i915_request_add(rq);
- i915_vma_unpin(vma);
- return PTR_ERR(cs);
+ err = PTR_ERR(cs);
+ goto out_rq;
}
if (INTEL_GEN(ctx->engine->i915) >= 8) {
@@ -238,14 +238,16 @@ static int gpu_set(struct context *ctx, unsigned long
offset, u32 v)
}
intel_ring_advance(rq, cs);
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- i915_vma_unpin(vma);
+out_rq:
i915_request_add(rq);
+out_unpin:
+ i915_vma_unpin(vma);
+out_unlock:
+ i915_gem_object_unlock(ctx->obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index a67d9e59fe12..d4aaf603a78f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -528,31 +528,42 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(obj, &ww);
+ if (!err)
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
if (err)
- return err;
+ goto err;
rq = intel_engine_create_kernel_request(engine);
if (IS_ERR(rq)) {
- i915_vma_unpin(vma);
- return PTR_ERR(rq);
+ err = PTR_ERR(rq);
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq,
EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
i915_request_add(rq);
+err_unpin:
i915_vma_unpin(vma);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
if (err)
return err;
}
@@ -1000,6 +1011,7 @@ static int __igt_mmap_gpu(struct drm_i915_private *i915,
for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
vma = i915_vma_instance(obj, engine->kernel_context->vm, NULL);
if (IS_ERR(vma)) {
@@ -1007,9 +1019,13 @@ static int __igt_mmap_gpu(struct drm_i915_private *i915,
goto out_unmap;
}
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ i915_gem
[Intel-gfx] [PATCH 01/23] Revert "drm/i915/gem: Drop relocation slowpath"
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 239 +-
1 file changed, 235 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cda35e6dfc44..9d3b6a43b825 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1503,7 +1503,9 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
struct eb_vma *ev)
* we would try to acquire the struct mutex again. Obviously
* this is bad and so lockdep complains vehemently.
*/
- copied = __copy_from_user(r, urelocs, count * sizeof(r[0]));
+ pagefault_disable();
+ copied = __copy_from_user_inatomic(r, urelocs, count *
sizeof(r[0]));
+ pagefault_enable();
if (unlikely(copied)) {
remain = -EFAULT;
goto out;
@@ -1553,6 +1555,236 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
struct eb_vma *ev)
return remain;
}
+static int
+eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
+{
+ const struct drm_i915_gem_exec_object2 *entry = ev->exec;
+ struct drm_i915_gem_relocation_entry *relocs =
+ u64_to_ptr(typeof(*relocs), entry->relocs_ptr);
+ unsigned int i;
+ int err;
+
+ for (i = 0; i < entry->relocation_count; i++) {
+ u64 offset = eb_relocate_entry(eb, ev, &relocs[i]);
+
+ if ((s64)offset < 0) {
+ err = (int)offset;
+ goto err;
+ }
+ }
+ err = 0;
+err:
+ reloc_cache_reset(&eb->reloc_cache);
+ return err;
+}
+
+static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+{
+ const char __user *addr, *end;
+ unsigned long size;
+ char __maybe_unused c;
+
+ size = entry->relocation_count;
+ if (size == 0)
+ return 0;
+
+ if (size > N_RELOC(ULONG_MAX))
+ return -EINVAL;
+
+ addr = u64_to_user_ptr(entry->relocs_ptr);
+ size *= sizeof(struct drm_i915_gem_relocation_entry);
+ if (!access_ok(addr, size))
+ return -EFAULT;
+
+ end = addr + size;
+ for (; addr < end; addr += PAGE_SIZE) {
+ int err = __get_user(c, addr);
+ if (err)
+ return err;
+ }
+ return __get_user(c, end - 1);
+}
+
+static int eb_copy_relocations(const struct i915_execbuffer *eb)
+{
+ struct drm_i915_gem_relocation_entry *relocs;
+ const unsigned int count = eb->buffer_count;
+ unsigned int i;
+ int err;
+
+ for (i = 0; i < count; i++) {
+ const unsigned int nreloc = eb->exec[i].relocation_count;
+ struct drm_i915_gem_relocation_entry __user *urelocs;
+ unsigned long size;
+ unsigned long copied;
+
+ if (nreloc == 0)
+ continue;
+
+ err = check_relocations(&eb->exec[i]);
+ if (err)
+ goto err;
+
+ urelocs = u64_to_user_ptr(eb->exec[i].relocs_ptr);
+ size = nreloc * sizeof(*relocs);
+
+ relocs = kvmalloc_array(size, 1, GFP_KERNEL);
+ if (!relocs) {
+ err = -ENOMEM;
+ goto err;
+ }
+
+ /* copy_from_user is limited to < 4GiB */
+ copied = 0;
+ do {
+ unsigned int len =
+ min_t(u64, BIT_ULL(31), size - copied);
+
+ if (__copy_from_user((char *)relocs + copied,
+(char __user *)urelocs + copied,
+len))
+ goto end;
+
+ copied += len;
+ } while (copied < size);
+
+ /*
+* As we do not update the known relocation offsets after
+* relocating (due to the complexities in lock handling),
+* we need to mark them as invalid now so that we force the
+* relocation processing next time. Just in case the target
+* object is evicted and then rebound into its old
+* presumed_offset before the next execbuffer - if that
+* happened we would make the mistake of assuming that the
+* relocations were valid.
+*/
+ if (!user_access_begin
[Intel-gfx] [PATCH 13/23] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass ww at a point where we could still handle -EDEADLK safely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 125 ++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 4 +-
drivers/gpu/drm/i915/gt/intel_context.c | 65 +
drivers/gpu/drm/i915/gt/intel_context.h | 13 ++
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ring.h | 3 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 15 +--
drivers/gpu/drm/i915/gt/intel_timeline.c | 12 +-
drivers/gpu/drm/i915/gt/intel_timeline.h | 3 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 13 +-
drivers/gpu/drm/i915/i915_gem.c | 11 +-
drivers/gpu/drm/i915/i915_vma.c | 13 +-
drivers/gpu/drm/i915/i915_vma.h | 13 +-
24 files changed, 207 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2e2e5ce82dc2..a429e90956f5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3441,7 +3441,7 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(vma))
goto err_obj;
- if (i915_ggtt_pin(vma, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
+ if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
goto err_obj;
if (i915_gem_object_is_tiled(obj) &&
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 062848951095..f5b01e70eb61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1145,7 +1145,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
i915_gem_ww_ctx_init(&ww, true);
retry:
- err = intel_context_pin(ce);
+ err = intel_context_pin_ww(ce, &ww);
if (err)
goto err;
@@ -1238,7 +1238,7 @@ static int pin_ppgtt_update(struct intel_context *ce,
struct i915_gem_ww_ctx *ww
if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
/* ppGTT is not part of the legacy context image */
- return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm), ww);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 05f6e1a94977..0a2121429913 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -394,7 +394,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
+ if (unlikely(i915_vma_pin_ww(vma, &eb->ww, 0, 0, pin_flags)))
return false;
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
@@ -535,7 +535,7 @@ static inline int use_cpu_reloc(const struct reloc_cache
*cache,
obj->cache_level != I915_CACHE_NONE);
}
-static int eb_reserve_vma(const struct i915_execbuffer *eb,
+static int eb_reserve_vma(struct i915_execbuffer *eb,
struct eb_vma *ev,
u64 pin_flags)
{
@@ -569,7 +569,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
return err;
}
- err = i915_vma_pin(vma,
+ err = i915_vma_pin_ww(vma, &eb->ww,
entry->pad_to_size, entry->alignment,
pin_flags);
if (err)
@@ -1060,9 +1060,10 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
}
static void *reloc_iomap(struct drm_i915_gem_object *obj,
-struct reloc_cache *cache,
+struct i915_execbuffer *eb,
unsigned long page)
{
+ struct reloc_cache *cache = &eb-
[Intel-gfx] [PATCH 11/23] drm/i915: Pin engine before pinning all objects, v3.
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take the fastpath, if not we will take the slowpath and wait for
the throttle request while unlocked.
The engine has to be pinned as first step, otherwise gpu relocations
won't work.
Changes since v1:
- Only need to get a throttled request in the fastpath, no need for
a global flag any more.
- Always free the waited request correctly.
Changes since v2:
- Use intel_engine_pm_get()/put() to keeep engine pool alive during
EDEADLK handling.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 174 --
1 file changed, 118 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 74146623b8ae..05f6e1a94977 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -16,6 +16,7 @@
#include "gem/i915_gem_ioctls.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pool.h"
+#include "gt/intel_engine_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_ring.h"
@@ -55,7 +56,8 @@ enum {
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
-#define __EXEC_INTERNAL_FLAGS (~0u << 31)
+#define __EXEC_ENGINE_PINNED BIT(30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 30)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -288,6 +290,9 @@ struct i915_execbuffer {
};
static int eb_parse(struct i915_execbuffer *eb);
+static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
+ bool throttle);
+static void eb_unpin_engine(struct i915_execbuffer *eb);
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
@@ -896,7 +901,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long
handle)
}
}
-static void eb_release_vmas(const struct i915_execbuffer *eb, bool final)
+static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
{
const unsigned int count = eb->buffer_count;
unsigned int i;
@@ -913,6 +918,8 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb, bool final)
if (final)
i915_vma_put(vma);
}
+
+ eb_unpin_engine(eb);
}
static void eb_destroy(const struct i915_execbuffer *eb)
@@ -1713,7 +1720,8 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb,
+ struct i915_request *rq)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1729,6 +1737,21 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
eb_release_vmas(eb, false);
i915_gem_ww_ctx_fini(&eb->ww);
+ if (rq) {
+ /* nonblocking is always false */
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0) {
+ i915_request_put(rq);
+ rq = NULL;
+
+ err = -EINTR;
+ goto err_relock;
+ }
+
+ i915_request_put(rq);
+ rq = NULL;
+ }
+
/*
* We take 3 passes through the slowpatch.
*
@@ -1752,14 +1775,25 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
err = 0;
}
- flush_workqueue(eb->i915->mm.userptr_wq);
+ if (!err)
+ flush_workqueue(eb->i915->mm.userptr_wq);
+err_relock:
i915_gem_ww_ctx_init(&eb->ww, true);
if (err)
goto out;
/* reacquire the objects */
repeat_validate:
+ rq = eb_pin_engine(eb, false);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err;
+ }
+
+ /* We didn't throttle, should be NULL */
+ GEM_WARN_ON(rq);
+
err = eb_validate_vmas(eb);
if (err)
goto err;
@@ -1823,14 +1857,47 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
}
}
+ if (rq)
+ i915_request_put(rq);
+
return err;
}
static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
+ struct i915_request *rq = NULL;
+ bool throttle = true;
retry:
+ rq = eb_pin_engine(eb, throttle);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+
[Intel-gfx] [PATCH 02/23] perf/core: Only copy-to-user after completely unlocking all locks.
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circular locking dependency detected
<4> [604.892536] 5.6.0-rc7-CI-Patchwork_17096+ #1 Tainted: G U
<4> [604.892537] --
<4> [604.892538] kms_frontbuffer/2595 is trying to acquire lock:
<4> [604.892540] 8264a558 (rcu_state.barrier_mutex){+.+.}, at:
rcu_barrier+0x23/0x190
<4> [604.892547]
but task is already holding lock:
<4> [604.892547] 888484716050 (reservation_ww_class_mutex){+.+.}, at:
i915_gem_object_pin_to_display_plane+0x89/0x270 [i915]
<4> [604.892592]
which lock already depends on the new lock.
<4> [604.892593]
the existing dependency chain (in reverse order) is:
<4> [604.892594]
-> #6 (reservation_ww_class_mutex){+.+.}:
<4> [604.892597]__ww_mutex_lock.constprop.15+0xc3/0x1090
<4> [604.892598]ww_mutex_lock+0x39/0x70
<4> [604.892600]dma_resv_lockdep+0x10e/0x1f5
<4> [604.892602]do_one_initcall+0x58/0x300
<4> [604.892604]kernel_init_freeable+0x17b/0x1dc
<4> [604.892605]kernel_init+0x5/0x100
<4> [604.892606]ret_from_fork+0x24/0x50
<4> [604.892607]
-> #5 (reservation_ww_class_acquire){+.+.}:
<4> [604.892609]dma_resv_lockdep+0xec/0x1f5
<4> [604.892610]do_one_initcall+0x58/0x300
<4> [604.892610]kernel_init_freeable+0x17b/0x1dc
<4> [604.892611]kernel_init+0x5/0x100
<4> [604.892612]ret_from_fork+0x24/0x50
<4> [604.892613]
-> #4 (&mm->mmap_sem#2){}:
<4> [604.892615]__might_fault+0x63/0x90
<4> [604.892617]_copy_to_user+0x1e/0x80
<4> [604.892619]perf_read+0x200/0x2b0
<4> [604.892621]vfs_read+0x96/0x160
<4> [604.892622]ksys_read+0x9f/0xe0
<4> [604.892623]do_syscall_64+0x4f/0x220
<4> [604.892624]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [604.892625]
-> #3 (&cpuctx_mutex){+.+.}:
<4> [604.892626]__mutex_lock+0x9a/0x9c0
<4> [604.892627]perf_event_init_cpu+0xa4/0x140
<4> [604.892629]perf_event_init+0x19d/0x1cd
<4> [604.892630]start_kernel+0x362/0x4e4
<4> [604.892631]secondary_startup_64+0xa4/0xb0
<4> [604.892631]
-> #2 (pmus_lock){+.+.}:
<4> [604.892633]__mutex_lock+0x9a/0x9c0
<4> [604.892633]perf_event_init_cpu+0x6b/0x140
<4> [604.892635]cpuhp_invoke_callback+0x9b/0x9d0
<4> [604.892636]_cpu_up+0xa2/0x140
<4> [604.892637]do_cpu_up+0x61/0xa0
<4> [604.892639]smp_init+0x57/0x96
<4> [604.892639]kernel_init_freeable+0x87/0x1dc
<4> [604.892640]kernel_init+0x5/0x100
<4> [604.892642]ret_from_fork+0x24/0x50
<4> [604.892642]
-> #1 (cpu_hotplug_lock.rw_sem){}:
<4> [604.892643]cpus_read_lock+0x34/0xd0
<4> [604.892644]rcu_barrier+0xaa/0x190
<4> [604.892645]kernel_init+0x21/0x100
<4> [604.892647]ret_from_fork+0x24/0x50
<4> [604.892647]
-> #0 (rcu_state.barrier_mutex){+.+.}:
<4> [604.892649]__lock_acquire+0x1328/0x15d0
<4> [604.892650]lock_acquire+0xa7/0x1c0
<4> [604.892651]__mutex_lock+0x9a/0x9c0
<4> [604.892652]rcu_barrier+0x23/0x190
<4> [604.892680]i915_gem_object_unbind+0x29d/0x3f0 [i915]
<4> [604.892707]i915_gem_object_pin_to_display_plane+0x141/0x270 [i915]
<4> [604.892737]intel_pin_and_fence_fb_obj+0xec/0x1f0 [i915]
<4> [604.892767]intel_plane_pin_fb+0x3f/0xd0 [i915]
<4> [604.892797]intel_prepare_plane_fb+0x13b/0x5c0 [i915]
<4> [604.892798]drm_atomic_helper_prepare_planes+0x85/0x110
<4> [604.892827]intel_atomic_commit+0xda/0x390 [i915]
<4> [604.892828]drm_atomic_helper_set_config+0x57/0xa0
<4> [604.892830]drm_mode_setcrtc+0x1c4/0x720
<4> [604.892830]drm_ioctl_kernel+0xb0/0xf0
<4> [604.892831]drm_ioctl+0x2e1/0x390
<4> [604.892833]ksys_ioctl+0x7b/0x90
<4> [604.892835]__x64_sys_ioctl+0x11/0x20
<4> [604.892835]do_syscall_64+0x4f/0x220
<4> [604.892836]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [604.892837]
Signed-off-by: Maarten Lankhorst
---
kernel/events/core.c | 59 +++-
1 file changed, 31 insertions(+), 28 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 085d9263d595..8b95a6512e31 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4926,20 +4926,20 @@ static int __perf_read_group_add(struct perf_event
*leader,
}
static int perf_read_group(struct perf_event *event,
- u64 read_format, char __user *buf)
+ u64 read_format, char __user *buf,
+ u64 **values)
{
struct perf_event *leader = event->group_leader, *child;
struc
[Intel-gfx] [PATCH 18/23] drm/i915/selftests: Fix locking inversion in lrc selftest.
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index d3e163c93e22..f89349b93ede 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -4298,6 +4298,7 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
{
struct intel_context *ce;
struct i915_request *rq;
+ struct i915_gem_ww_ctx ww;
enum {
RING_START_IDX = 0,
RING_TAIL_IDX,
@@ -4312,7 +4313,11 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
if (IS_ERR(ce))
return PTR_ERR(ce);
- err = intel_context_pin(ce);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(scratch->obj, &ww);
+ if (!err)
+ err = intel_context_pin_ww(ce, &ww);
if (err)
goto err_put;
@@ -4341,11 +4346,9 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
*cs++ = i915_ggtt_offset(scratch) + RING_TAIL_IDX * sizeof(u32);
*cs++ = 0;
- i915_vma_lock(scratch);
err = i915_request_await_object(rq, scratch->obj, true);
if (!err)
err = i915_vma_move_to_active(scratch, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(scratch);
i915_request_get(rq);
i915_request_add(rq);
@@ -4382,6 +4385,12 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
err_unpin:
intel_context_unpin(ce);
err_put:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
intel_context_put(ce);
return err;
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/23] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us to take pin refcounts correctly
all the time.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 233 +++---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 ++-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 1 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 13 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 13 +-
6 files changed, 191 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e4aece20bc80..bc0ed268ccb8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -93,79 +93,6 @@ static void intel_context_active_release(struct
intel_context *ce)
i915_active_release(&ce->active);
}
-int __intel_context_do_pin(struct intel_context *ce)
-{
- int err;
-
- if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
- err = intel_context_alloc_state(ce);
- if (err)
- return err;
- }
-
- err = i915_active_acquire(&ce->active);
- if (err)
- return err;
-
- if (mutex_lock_interruptible(&ce->pin_mutex)) {
- err = -EINTR;
- goto out_release;
- }
-
- if (unlikely(intel_context_is_closed(ce))) {
- err = -ENOENT;
- goto out_unlock;
- }
-
- if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
- err = intel_context_active_acquire(ce);
- if (unlikely(err))
- goto out_unlock;
-
- err = ce->ops->pin(ce);
- if (unlikely(err))
- goto err_active;
-
- CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
-ce->ring->head, ce->ring->tail);
-
- smp_mb__before_atomic(); /* flush pin before it is visible */
- atomic_inc(&ce->pin_count);
- }
-
- GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
- GEM_BUG_ON(i915_active_is_idle(&ce->active));
- goto out_unlock;
-
-err_active:
- intel_context_active_release(ce);
-out_unlock:
- mutex_unlock(&ce->pin_mutex);
-out_release:
- i915_active_release(&ce->active);
- return err;
-}
-
-void intel_context_unpin(struct intel_context *ce)
-{
- if (!atomic_dec_and_test(&ce->pin_count))
- return;
-
- CE_TRACE(ce, "unpin\n");
- ce->ops->unpin(ce);
-
- /*
-* Once released, we may asynchronously drop the active reference.
-* As that may be the only reference keeping the context alive,
-* take an extra now so that it is not freed before we finish
-* dereferencing it.
-*/
- intel_context_get(ce);
- intel_context_active_release(ce);
- intel_context_put(ce);
-}
-
static int __context_pin_state(struct i915_vma *vma)
{
unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
@@ -225,6 +152,138 @@ static void __ring_retire(struct intel_ring *ring)
i915_active_release(&ring->vma->active);
}
+static int intel_context_pre_pin(struct intel_context *ce)
+{
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ err = __ring_active(ce->ring);
+ if (err)
+ return err;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+ return err;
+}
+
+static void intel_context_post_unpin(struct intel_context *ce)
+{
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+}
+
+int __intel_context_do_pin(struct intel_context *ce)
+{
+ bool handoff = false;
+ void *vaddr;
+ int err = 0;
+
+ if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
+ err = intel_context_alloc_state(ce);
+ if (err)
+ return err;
+ }
+
+ /*
+* We always pin the context/ring/timeline here, to ensure a pin
+* refcount for __intel_context_active(), which prevent a lock
+* inversion of ce->pin_mutex vs dma_resv_lock().
+*/
+ err = intel_context_pre_pin
[Intel-gfx] [PATCH 03/23] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_ctx and obj order in locking functions (Jonas Lahtinen)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 10 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +++---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../i915/gem/selftests/i915_gem_coherency.c | 10 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 4 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
.../drm/i915/gem/selftests/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 52 +--
drivers/gpu/drm/i915/i915_gem.h | 11
drivers/gpu/drm/i915/selftests/i915_gem.c | 41 +++
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 2 +-
26 files changed, 175 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e09a11b1e509..2e2e5ce82dc2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2303,7 +2303,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
{
- i915_gem_object_lock(vma->obj);
+ i915_gem_object_lock(vma->obj, NULL);
if (flags & PLANE_HAS_FENCE)
i915_vma_unpin_fence(vma);
i915_gem_object_unpin_from_display_plane(vma);
@@ -17047,7 +17047,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
if (!intel_fb->frontbuffer)
return -ENOMEM;
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
tiling = i915_gem_object_get_tiling(obj);
stride = i915_gem_object_get_stride(obj);
i915_gem_object_unlock(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 0598e5382a1d..5d94a77f9bdd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -287,7 +287,7 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
err = i915_sw_fence_await_reservation(&work->wait,
obj->base.resv, NULL,
true, I915_FENCE_TIMEOUT,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 50e7580f9337..ac2b88ca00ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -113,7 +113,7 @@ static void lut_close(struct i915_gem_context *ctx)
continue;
rcu_read_unlock();
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
list_for_each_entry(lut, &obj->lut_list, obj_link) {
if (lut->ctx != ctx)
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a793739d..cfadccfc2990 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -128,7 +128,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
if (err)
return err;
- err = i915_gem_object_lock_interruptible(obj);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
goto out;
@@ -149,7 +149,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direct
if (err)
[Intel-gfx] [PATCH 05/23] drm/i915: Parse command buffer earlier in eb_relocate(slow)
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get called from execbuf
relocation fast and slowpath.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 68 ++-
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 361ce7ee30de..bd8364197da1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -290,6 +290,8 @@ struct i915_execbuffer {
struct eb_vma_array *array;
};
+static int eb_parse(struct i915_execbuffer *eb);
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -855,6 +857,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
+ struct drm_i915_private *i915 = eb->i915;
unsigned int batch = eb_batch_index(eb);
unsigned int i;
int err = 0;
@@ -868,18 +871,37 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
vma = eb_lookup_vma(eb, eb->exec[i].handle);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
- break;
+ goto err;
}
err = eb_validate_vma(eb, &eb->exec[i], vma);
if (unlikely(err)) {
i915_vma_put(vma);
- break;
+ goto err;
}
eb_add_vma(eb, i, batch, vma);
}
+ if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+ drm_dbg(&i915->drm,
+ "Attempting to use self-modifying batch buffer\n");
+ return -EINVAL;
+ }
+
+ if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+ drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
+ return -EINVAL;
+ }
+
+ if (eb->batch_len == 0)
+ eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
+ return 0;
+
+err:
eb->vma[i].vma = NULL;
return err;
}
@@ -1711,7 +1733,7 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
{
bool have_copy = false;
struct eb_vma *ev;
@@ -1762,6 +1784,11 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
}
}
+ /* as last step, parse the command buffer */
+ err = eb_parse(eb);
+ if (err)
+ goto err;
+
/*
* Leave the user relocations as are, this is the painfully slow path,
* and we want to avoid the complication of dropping the lock whilst
@@ -1794,7 +1821,7 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
return err;
}
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
@@ -1814,11 +1841,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
list_for_each_entry(ev, &eb->relocs, reloc_link) {
if (eb_relocate_vma(eb, ev))
- return eb_relocate_slow(eb);
+ return eb_relocate_parse_slow(eb);
}
}
- return 0;
+ return eb_parse(eb);
}
static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2749,7 +2776,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
- err = eb_relocate(&eb);
+ err = eb_relocate_parse(&eb);
if (err) {
/*
* If the user expects the execobject.offset and
@@ -2762,33 +2789,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
- if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
- drm_dbg(&i915->drm,
- "Attempting to use self-modifying batch buffer\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
- drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
- err = -EINVAL;
-
[Intel-gfx] [PATCH 14/23] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/put() calls to fix use-after-free when using
intel_engine_get_pool().
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 80 +++--
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 156 +++---
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 3 +
3 files changed, 165 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 5d94a77f9bdd..10df576e785f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -157,6 +157,7 @@ static void clear_pages_worker(struct work_struct *work)
struct clear_pages_work *w = container_of(work, typeof(*w), work);
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
struct i915_vma *batch;
int err = w->dma.error;
@@ -172,17 +173,20 @@ static void clear_pages_worker(struct work_struct *work)
obj->read_domains = I915_GEM_GPU_DOMAINS;
obj->write_domain = 0;
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
- if (unlikely(err))
+ i915_gem_ww_ctx_init(&ww, false);
+ intel_engine_pm_get(w->ce->engine);
+retry:
+ err = intel_context_pin_ww(w->ce, &ww);
+ if (err)
goto out_signal;
- batch = intel_emit_vma_fill_blt(w->ce, vma, w->value);
+ batch = intel_emit_vma_fill_blt(w->ce, vma, &ww, w->value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
- goto out_unpin;
+ goto out_ctx;
}
- rq = intel_context_create_request(w->ce);
+ rq = i915_request_create(w->ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto out_batch;
@@ -224,9 +228,19 @@ static void clear_pages_worker(struct work_struct *work)
i915_request_add(rq);
out_batch:
intel_emit_vma_release(w->ce, batch);
-out_unpin:
- i915_vma_unpin(vma);
+out_ctx:
+ intel_context_unpin(w->ce);
out_signal:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ i915_vma_unpin(w->sleeve->vma);
+ intel_engine_pm_put(w->ce->engine);
+
if (unlikely(err)) {
dma_fence_set_error(&w->dma, err);
dma_fence_signal(&w->dma);
@@ -234,6 +248,45 @@ static void clear_pages_worker(struct work_struct *work)
}
}
+static int pin_wait_clear_pages_work(struct clear_pages_work *w,
+struct intel_context *ce)
+{
+ struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err)
+ goto out;
+
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
+ if (unlikely(err))
+ goto out;
+
+ err = i915_sw_fence_await_reservation(&w->wait,
+ vma->obj->base.resv, NULL,
+ true, I915_FENCE_TIMEOUT,
+ I915_FENCE_GFP);
+ if (err)
+ goto err_unpin_vma;
+
+ dma_resv_add_excl_fence(vma->obj->base.resv, &w->dma);
+
+err_unpin_vma:
+ if (err)
+ i915_vma_unpin(vma);
+out:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+ return err;
+}
+
static int __i915_sw_fence_call
clear_pages_work_notify(struct i915_sw_fence *fence,
enum i915_sw_fence_notify state)
@@ -287,18 +340,9 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
- i915_gem_object_lock(obj, NULL);
- err = i915_sw_fence_await_reservation(&work->wait,
- obj->base.resv, NULL,
- true, I915_FENCE_TIMEOUT,
- I915_FENCE_GFP);
- if (err < 0) {
+ err = pin_wait_clear_pages_work(work, ce);
+ if (err < 0)
dma_fence_set_error(&work->dma, err);
- } else {
- dma_resv_add_e
[Intel-gfx] [PATCH 04/23] drm/i915: Remove locking from i915_gem_object_prepare_read/write
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 20 ++-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 -
.../gpu/drm/i915/gem/selftests/huge_pages.c | 5 -
.../i915/gem/selftests/i915_gem_coherency.c | 14 +
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 5 -
drivers/gpu/drm/i915/gvt/cmd_parser.c | 9 -
drivers/gpu/drm/i915/i915_gem.c | 20 +--
9 files changed, 70 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index f4602faa8db9..e9d3b587f562 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -581,19 +581,17 @@ int i915_gem_object_prepare_read(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -621,8 +619,6 @@ int i915_gem_object_prepare_read(struct drm_i915_gem_object
*obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
@@ -635,20 +631,18 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_ALL,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -685,7 +679,5 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e9fec5da9f69..361ce7ee30de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -983,11 +983,14 @@ static void reloc_cache_reset(struct reloc_cache *cache)
vaddr = unmask_page(cache->vaddr);
if (cache->vaddr & KMAP) {
+ struct drm_i915_gem_object *obj =
+ (struct drm_i915_gem_object *)cache->node.mm;
if (cache->vaddr & CLFLUSH_AFTER)
mb();
kunmap_atomic(vaddr);
- i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
+ i915_gem_object_finish_access(obj);
+ i915_gem_object_unlock(obj);
} else {
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
@@ -1022,10 +1025,16 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
- err = i915_gem_object_prepare_write(obj, &flushes);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
return ERR_PTR(err);
+ err = i915_gem_object_prepare_write(obj, &flushes);
+ if (err) {
+ i915_gem_object_unlock(obj);
+ return ERR_PTR(err);
+ }
+
BUILD_BUG_ON(KMAP & CLFLUSH_FLAGS);
BUILD_BUG_ON((KMAP | CLFLUSH_FLAGS) & PAGE_MASK);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 5103067269b0..11b8e2735
[Intel-gfx] [PATCH 16/23] drm/i915: Convert i915_perf to ww locking as well
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_perf.c | 57 +++-
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 28e3d76fa2e6..b4de6a3469bc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1195,24 +1195,39 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
struct i915_gem_engines_iter it;
struct i915_gem_context *ctx = stream->ctx;
struct intel_context *ce;
- int err;
+ struct i915_gem_ww_ctx ww;
+ int err = -ENODEV;
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
if (ce->engine != stream->engine) /* first match! */
continue;
- /*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*/
- err = intel_context_pin(ce);
- if (err == 0) {
- stream->pinned_ctx = ce;
- break;
- }
+ err = 0;
+ break;
}
i915_gem_context_unlock_engines(ctx);
+ if (err)
+ return ERR_PTR(err);
+
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*/
+ err = intel_context_pin_ww(ce, &ww);
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ if (err)
+ return ERR_PTR(err);
+
+ stream->pinned_ctx = ce;
return stream->pinned_ctx;
}
@@ -1927,15 +1942,22 @@ emit_oa_config(struct i915_perf_stream *stream,
{
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = get_oa_vma(stream, oa_config);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err)
+ goto err;
+
+ err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
- goto err_vma_put;
+ goto err;
intel_engine_pm_get(ce->engine);
rq = i915_request_create(ce);
@@ -1957,11 +1979,9 @@ emit_oa_config(struct i915_perf_stream *stream,
goto err_add_request;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, 0);
if (!err)
err = i915_vma_move_to_active(vma, rq, 0);
- i915_vma_unlock(vma);
if (err)
goto err_add_request;
@@ -1975,7 +1995,14 @@ emit_oa_config(struct i915_perf_stream *stream,
i915_request_add(rq);
err_vma_unpin:
i915_vma_unpin(vma);
-err_vma_put:
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+
+ i915_gem_ww_ctx_fini(&ww);
i915_vma_put(vma);
return err;
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/23] drm/i915: Add ww locking to vm_fault_gtt
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -283,37 +283,46 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
struct intel_runtime_pm *rpm = &i915->runtime_pm;
struct i915_ggtt *ggtt = &i915->ggtt;
bool write = area->vm_flags & VM_WRITE;
+ struct i915_gem_ww_ctx ww;
intel_wakeref_t wakeref;
struct i915_vma *vma;
pgoff_t page_offset;
int srcu;
int ret;
- /* Sanity check that we allow writing into this object */
- if (i915_gem_object_is_readonly(obj) && write)
- return VM_FAULT_SIGBUS;
-
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
trace_i915_gem_object_fault(obj, page_offset, true, write);
- ret = i915_gem_object_pin_pages(obj);
+ wakeref = intel_runtime_pm_get(rpm);
+
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
if (ret)
- goto err;
+ goto err_rpm;
- wakeref = intel_runtime_pm_get(rpm);
+ /* Sanity check that we allow writing into this object */
+ if (i915_gem_object_is_readonly(obj) && write) {
+ ret = -EFAULT;
+ goto err_rpm;
+ }
- ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+ ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err_rpm;
+ ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+ if (ret)
+ goto err_pages;
+
/* Now pin it into the GTT as needed */
- vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
- PIN_MAPPABLE |
- PIN_NONBLOCK /* NOWARN */ |
- PIN_NOEVICT);
- if (IS_ERR(vma)) {
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, NULL, 0, 0,
+ PIN_MAPPABLE |
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
@@ -328,11 +337,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
* all hope that the hardware is able to track future writes.
*/
- vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
- if (IS_ERR(vma)) {
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0, 0, flags);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
- vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0,
0, flags);
}
/* The entire mappable GGTT is pinned? Unexpected! */
@@ -389,10 +398,16 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
__i915_vma_unpin(vma);
err_reset:
intel_gt_reset_unlock(ggtt->vm.gt, srcu);
+err_pages:
+ i915_gem_object_unpin_pages(obj);
err_rpm:
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff(&ww);
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
intel_runtime_pm_put(rpm, wakeref);
- i915_gem_object_unpin_pages(obj);
-err:
return i915_error_to_vmf_fault(ret);
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/23] drm/i915: Ensure we hold the pin mutex
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index c39d73142950..df42ba06711a 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -207,7 +207,7 @@ int intel_renderstate_init(struct intel_renderstate *so,
if (err)
goto err_context;
- err = i915_vma_pin(so->vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ err = i915_vma_pin_ww(so->vma, &so->ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
goto err_context;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e3d82be503dc..e22f287ba382 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -892,6 +892,8 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
#ifdef CONFIG_PROVE_LOCKING
if (debug_locks && lockdep_is_held(&vma->vm->i915->drm.struct_mutex))
WARN_ON(!ww);
+ if (debug_locks && ww && vma->resv)
+ assert_vma_held(vma);
#endif
BUILD_BUG_ON(PIN_GLOBAL != I915_VMA_GLOBAL_BIND);
@@ -1032,8 +1034,13 @@ int i915_ggtt_pin(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
GEM_BUG_ON(!i915_vma_is_ggtt(vma));
+ WARN_ON(!ww && vma->resv && dma_resv_held(vma->resv));
+
do {
- err = i915_vma_pin_ww(vma, ww, 0, align, flags | PIN_GLOBAL);
+ if (ww)
+ err = i915_vma_pin_ww(vma, ww, 0, align, flags |
PIN_GLOBAL);
+ else
+ err = i915_vma_pin(vma, 0, align, flags | PIN_GLOBAL);
if (err != -ENOSPC) {
if (!err) {
err = i915_vma_wait_for_bind(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index da577729931f..b730f86e54f4 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -242,6 +242,7 @@ i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
static inline int __must_check
i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
{
+ WARN_ON_ONCE(vma->resv && dma_resv_held(vma->resv));
return i915_vma_pin_ww(vma, NULL, size, alignment, flags);
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/23] drm/i915: Use ww locking in intel_renderstate.
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_gt.c | 21 +++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 71 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.h | 9 ++-
3 files changed, 65 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6eae4c791007..c11e89472ad8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -406,21 +406,20 @@ static int __engines_record_defaults(struct intel_gt *gt)
/* We must be able to switch to something! */
GEM_BUG_ON(!engine->kernel_context);
- err = intel_renderstate_init(&so, engine);
- if (err)
- goto out;
-
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
err = PTR_ERR(ce);
goto out;
}
- rq = intel_context_create_request(ce);
+ err = intel_renderstate_init(&so, ce);
+ if (err)
+ goto err;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- intel_context_put(ce);
- goto out;
+ goto err_fini;
}
err = intel_engine_emit_ctx_wa(rq);
@@ -434,9 +433,13 @@ static int __engines_record_defaults(struct intel_gt *gt)
err_rq:
requests[id] = i915_request_get(rq);
i915_request_add(rq);
- intel_renderstate_fini(&so);
- if (err)
+err_fini:
+ intel_renderstate_fini(&so, ce);
+err:
+ if (err) {
+ intel_context_put(ce);
goto out;
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index ca533d98d14d..c65554c431f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "intel_renderstate.h"
+#include "gt/intel_context.h"
#include "intel_ring.h"
static const struct intel_renderstate_rodata *
@@ -74,10 +75,9 @@ static int render_state_setup(struct intel_renderstate *so,
u32 *d;
int ret;
- i915_gem_object_lock(so->vma->obj, NULL);
ret = i915_gem_object_prepare_write(so->vma->obj, &needs_clflush);
if (ret)
- goto out_unlock;
+ return ret;
d = kmap_atomic(i915_gem_object_get_dirty_page(so->vma->obj, 0));
@@ -158,8 +158,6 @@ static int render_state_setup(struct intel_renderstate *so,
ret = 0;
out:
i915_gem_object_finish_access(so->vma->obj);
-out_unlock:
- i915_gem_object_unlock(so->vma->obj);
return ret;
err:
@@ -171,33 +169,47 @@ static int render_state_setup(struct intel_renderstate
*so,
#undef OUT_BATCH
int intel_renderstate_init(struct intel_renderstate *so,
- struct intel_engine_cs *engine)
+ struct intel_context *ce)
{
- struct drm_i915_gem_object *obj;
+ struct intel_engine_cs *engine = ce->engine;
+ struct drm_i915_gem_object *obj = NULL;
int err;
memset(so, 0, sizeof(*so));
so->rodata = render_state_get_rodata(engine);
- if (!so->rodata)
- return 0;
+ if (so->rodata) {
+ if (so->rodata->batch_items * 4 > PAGE_SIZE)
+ return -EINVAL;
+
+ obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
+ if (IS_ERR(so->vma)) {
+ err = PTR_ERR(so->vma);
+ goto err_obj;
+ }
+ }
- if (so->rodata->batch_items * 4 > PAGE_SIZE)
- return -EINVAL;
+ i915_gem_ww_ctx_init(&so->ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err_fini;
- obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ /* return early if there's nothing to setup */
+ if (!err && !so->rodata)
+ return 0;
- so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
- if (
[Intel-gfx] [PATCH 07/23] drm/i915: Use per object locking in execbuf, v7.
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This finally allows us to do parallel submission, but because not
all of the pinning code uses the ww ctx yet, we cannot completely
drop struct_mutex yet.
Changes since v1:
- Keep struct_mutex for now. :(
Changes since v2:
- Make sure we always lock the ww context in slowpath.
Changes since v3:
- Don't call __eb_unreserve_vma in eb_move_to_gpu now; this can be
done on normal unlock path.
- Unconditionally release vmas and context.
Changes since v4:
- Rebased on top of struct_mutex reduction.
Changes since v5:
- Remove training wheels.
Changes since v6:
- Fix accidentally broken -ENOSPC handling.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 273 ++
1 file changed, 148 insertions(+), 125 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 55b06d7a1329..a337f3054ce3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -249,6 +249,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
+ struct i915_gem_ww_ctx ww;
+
/**
* Track the most recently used object for relocations, as we
* frequently have to perform multiple relocations within the same
@@ -404,24 +406,18 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
-static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
-{
- GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
-
- if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- __i915_vma_unpin(vma);
-}
-
static inline void
eb_unreserve_vma(struct eb_vma *ev)
{
if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
return;
- __eb_unreserve_vma(ev->vma, ev->flags);
ev->flags &= ~__EXEC_OBJECT_RESERVED;
+
+ if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(ev->vma);
+
+ __i915_vma_unpin(ev->vma);
}
static int
@@ -515,16 +511,6 @@ eb_add_vma(struct i915_execbuffer *eb,
eb->batch = ev;
}
-
- if (eb_pin_vma(eb, entry, ev)) {
- if (entry->offset != vma->node.start) {
- entry->offset = vma->node.start | UPDATE;
- eb->args->flags |= __EXEC_HAS_RELOC;
- }
- } else {
- eb_unreserve_vma(ev);
- list_add_tail(&ev->bind_link, &eb->unbound);
- }
}
static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -628,10 +614,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
* This avoid unnecessary unbinding of later objects in order to make
* room for the earlier objects *unless* we need to defragment.
*/
-
- if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
- return -EINTR;
-
pass = 0;
do {
list_for_each_entry(ev, &eb->unbound, bind_link) {
@@ -639,8 +621,8 @@ static int eb_reserve(struct i915_execbuffer *eb)
if (err)
break;
}
- if (!(err == -ENOSPC || err == -EAGAIN))
- break;
+ if (err != -ENOSPC)
+ return err;
/* Resort *all* the objects into priority order */
INIT_LIST_HEAD(&eb->unbound);
@@ -670,13 +652,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
}
list_splice_tail(&last, &eb->unbound);
- if (err == -EAGAIN) {
- mutex_unlock(&eb->i915->drm.struct_mutex);
- flush_workqueue(eb->i915->mm.userptr_wq);
- mutex_lock(&eb->i915->drm.struct_mutex);
- continue;
- }
-
switch (pass++) {
case 0:
break;
@@ -687,20 +662,15 @@ static int eb_reserve(struct i915_execbuffer *eb)
err = i915_gem_evict_vm(eb->context->vm);
mutex_unlock(&eb->context->vm->mutex);
if (err)
- goto unlock;
+ return err;
break;
default:
- err = -ENOSPC;
- goto unlock;
+ return -ENOSPC;
}
pin_flags = PIN_USER;
} while (1);
-
-unlock:
- mutex_unlock(&eb-
[Intel-gfx] [PATCH 10/23] drm/i915: Nuke arguments to eb_pin_engine
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index a337f3054ce3..74146623b8ae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2412,11 +2412,10 @@ static void eb_unpin_engine(struct i915_execbuffer *eb)
}
static unsigned int
-eb_select_legacy_ring(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_select_legacy_ring(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
+ struct drm_i915_gem_execbuffer2 *args = eb->args;
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
if (user_ring_id != I915_EXEC_BSD &&
@@ -2431,7 +2430,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
- bsd_idx = gen8_dispatch_bsd_engine(i915, file);
+ bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -2456,18 +2455,16 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
}
static int
-eb_pin_engine(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_pin_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce;
unsigned int idx;
int err;
if (i915_gem_context_user_engines(eb->gem_context))
- idx = args->flags & I915_EXEC_RING_MASK;
+ idx = eb->args->flags & I915_EXEC_RING_MASK;
else
- idx = eb_select_legacy_ring(eb, file, args);
+ idx = eb_select_legacy_ring(eb);
ce = i915_gem_context_get_engine(eb->gem_context, idx);
if (IS_ERR(ce))
@@ -2765,7 +2762,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_destroy;
- err = eb_pin_engine(&eb, file, args);
+ err = eb_pin_engine(&eb);
if (unlikely(err))
goto err_context;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/23] drm/i915: Kill last user of intel_context_create_request outside of selftests
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index e96cc7fa0936..d866f5903554 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1744,6 +1744,7 @@ static int engine_wa_list_verify(struct intel_context *ce,
const struct i915_wa *wa;
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
unsigned int i;
u32 *results;
int err;
@@ -1756,29 +1757,34 @@ static int engine_wa_list_verify(struct intel_context
*ce,
return PTR_ERR(vma);
intel_engine_pm_get(ce->engine);
- rq = intel_context_create_request(ce);
- intel_engine_pm_put(ce->engine);
+ i915_gem_ww_ctx_init(&ww, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, &ww);
+ if (err == 0)
+ err = intel_context_pin_ww(ce, &ww);
+ if (err)
+ goto err_pm;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_vma;
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- if (err) {
- i915_request_add(rq);
- goto err_vma;
- }
-
- err = wa_list_srm(rq, wal, vma);
- if (err)
- goto err_vma;
+ if (err == 0)
+ err = wa_list_srm(rq, wal, vma);
i915_request_get(rq);
+ if (err)
+ i915_request_set_error_once(rq, err);
i915_request_add(rq);
+
+ if (err)
+ goto err_rq;
+
if (i915_request_wait(rq, 0, HZ / 5) < 0) {
err = -ETIME;
goto err_rq;
@@ -1803,7 +1809,16 @@ static int engine_wa_list_verify(struct intel_context
*ce,
err_rq:
i915_request_put(rq);
-err_vma:
+err_unpin:
+ intel_context_unpin(ce);
+err_pm:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+ intel_engine_pm_put(ce->engine);
i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/23] drm/i915: Add ww locking to pin_to_display_plane
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index e9d3b587f562..def8254b5fc2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -37,6 +37,12 @@ void i915_gem_object_flush_if_display(struct
drm_i915_gem_object *obj)
i915_gem_object_unlock(obj);
}
+void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj)
+{
+ if (i915_gem_object_is_framebuffer(obj))
+ __i915_gem_object_flush_for_display(obj);
+}
+
/**
* Moves a single object to the WC read, and possibly write domain.
* @obj: object to act on
@@ -197,18 +203,12 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
if (ret)
return ret;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
-
/* Always invalidate stale cachelines */
if (obj->cache_level != cache_level) {
i915_gem_object_set_cache_coherency(obj, cache_level);
obj->cache_dirty = true;
}
- i915_gem_object_unlock(obj);
-
/* The cache-level will be applied when each vma is rebound. */
return i915_gem_object_unbind(obj,
I915_GEM_OBJECT_UNBIND_ACTIVE |
@@ -255,6 +255,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_gem_caching *args = data;
struct drm_i915_gem_object *obj;
enum i915_cache_level level;
+ struct i915_gem_ww_ctx ww;
int ret = 0;
switch (args->caching) {
@@ -293,7 +294,18 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev,
void *data,
goto out;
}
- ret = i915_gem_object_set_cache_level(obj, level);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
+ if (!ret)
+ ret = i915_gem_object_set_cache_level(obj, level);
+
+ if (ret == -EDEADLK) {
+ ret = i915_gem_ww_ctx_backoff(&ww);
+ if (!ret)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
out:
i915_gem_object_put(obj);
@@ -313,6 +325,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
unsigned int flags)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_gem_ww_ctx ww;
struct i915_vma *vma;
int ret;
@@ -320,6 +333,11 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ ret = i915_gem_object_lock(obj, &ww);
+ if (ret)
+ goto err;
/*
* The display engine is not coherent with the LLC cache on gen6. As
* a result, we make sure that the pinning that is about to occur is
@@ -334,7 +352,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
HAS_WT(i915) ?
I915_CACHE_WT : I915_CACHE_NONE);
if (ret)
- return ERR_PTR(ret);
+ goto err;
/*
* As the user may map the buffer once pinned in the display plane
@@ -347,18 +365,31 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
vma = ERR_PTR(-ENOSPC);
if ((flags & PIN_MAPPABLE) == 0 &&
(!view || view->type == I915_GGTT_VIEW_NORMAL))
- vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
- flags |
- PIN_MAPPABLE |
- PIN_NONBLOCK);
- if (IS_ERR(vma))
- vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
- if (IS_ERR(vma))
- return vma;
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0, alignment,
+ flags | PIN_MAPPABLE |
+ PIN_NONBLOCK);
+ if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK))
+ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0,
+ alignment, flags);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto err;
+ }
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
- i915_gem_object_flush_if_display(obj);
+ i915_gem_object_flush_if_display_loc
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_alpha_blend: Correct typo in the name and comments of a subtest
On 2020-03-31 12:43, Petri Latvala wrote: > On Mon, Mar 30, 2020 at 06:55:32PM -0300, Melissa Wen wrote: >> Typo found in word transparent. >> Correct the word transparant, replacing the last letter -a- with -e- >> (transpar-a-nt to transpar-e-nt). >> >> Signed-off-by: Melissa Wen > > > Reviewed-by: Petri Latvala > > Martin, test rename, ack when cibuglog side is ready to merge this. > ACK, thanks for the patch Melissa! Martin pEpkey.asc Description: pEpkey.asc ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/psr: Implement WA 1110
== Series Details == Series: series starting with [1/3] drm/i915/psr: Implement WA 1110 URL : https://patchwork.freedesktop.org/series/75277/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17145_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17145_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17145_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17145_full: ### IGT changes ### Possible regressions * igt@i915_pm_rc6_residency@rc6-idle: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl8/igt@i915_pm_rc6_reside...@rc6-idle.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-apl8/igt@i915_pm_rc6_reside...@rc6-idle.html Known issues Here are the changes found in Patchwork_17145_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-iclb6/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@implicit-write-read-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-write-read-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-iclb7/igt@gem_exec_sched...@implicit-write-read-bsd1.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +13 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_selftest@live@execlists: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#1430] / [i915#58] / [i915#656] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk7/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-glk3/igt@i915_selftest@l...@execlists.html - shard-apl: [PASS][15] -> [INCOMPLETE][16] ([i915#656]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl4/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-apl7/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#300]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#133]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk8/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17145/shard-glk9/igt@kms_cursor_leg...@2x-nonblocking-
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/selftests: Tidy up an error message for live_error_interrupt
== Series Details == Series: series starting with [1/4] drm/i915/selftests: Tidy up an error message for live_error_interrupt URL : https://patchwork.freedesktop.org/series/75296/ State : success == Summary == CI Bug Log - changes from CI_DRM_8222 -> Patchwork_17149 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/index.html Known issues Here are the changes found in Patchwork_17149 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@requests: - fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1505]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/fi-icl-guc/igt@i915_selftest@l...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/fi-icl-guc/igt@i915_selftest@l...@requests.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [INCOMPLETE][3] ([i915#189]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/fi-icl-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/fi-icl-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-bxt-dsi: [INCOMPLETE][5] ([i915#656]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html - fi-cml-u2: [INCOMPLETE][7] ([i915#283] / [i915#656]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/fi-cml-u2/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/fi-cml-u2/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_contexts: - fi-bwr-2160:[INCOMPLETE][9] ([i915#1170] / [i915#489]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/fi-bwr-2160/igt@i915_selftest@live@gt_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/fi-bwr-2160/igt@i915_selftest@live@gt_contexts.html * igt@i915_selftest@live@hangcheck: - fi-icl-y: [INCOMPLETE][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [i915#1170]: https://gitlab.freedesktop.org/drm/intel/issues/1170 [i915#1505]: https://gitlab.freedesktop.org/drm/intel/issues/1505 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#283]: https://gitlab.freedesktop.org/drm/intel/issues/283 [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (46 -> 43) -- Additional (3): fi-hsw-4770 fi-kbl-7560u fi-snb-2520m Missing(6): fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-byt-n2820 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8222 -> Patchwork_17149 CI-20190529: 20190529 CI_DRM_8222: 6970d295e51e3b03d7ee3f781522398402d3a35d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5546: f074c26aea9681e52a5128e0da45e809dbacbea4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17149: 77b975ee8c8b9510f5fdd30dc71fdc5941faa9dc @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 77b975ee8c8b drm/i915/execlists: Record the active CCID from before reset 4effc0d425da drm/i915/execlists: Peek at the next submission for error interrupts b670e9191fe5 drm/i915/execlists: Pause CS flow before reset 008d17b47d33 drm/i915/selftests: Tidy up an error message for live_error_interrupt == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Double check breadcrumb before crying foul (rev2)
== Series Details == Series: drm/i915/execlists: Double check breadcrumb before crying foul (rev2) URL : https://patchwork.freedesktop.org/series/75278/ State : success == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17146_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17146_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-iclb6/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +14 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +7 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl7/igt@gem_exec_susp...@basic-s3.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-kbl3/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-hsw: [PASS][13] -> [TIMEOUT][14] ([i915#1526]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-idle.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_selftest@live@execlists: - shard-apl: [PASS][15] -> [INCOMPLETE][16] ([i915#656]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl4/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-apl6/igt@i915_selftest@l...@execlists.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl7/igt@i915_susp...@debugfs-reader.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-apl4/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy: - shard-skl: [PASS][19] -> [FAIL][20] ([IGT#5]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#34]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk5/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-glk1/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17146/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +2 similar issues
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Peek at the next submission for error interrupts
== Series Details == Series: drm/i915/execlists: Peek at the next submission for error interrupts URL : https://patchwork.freedesktop.org/series/75279/ State : success == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17147_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17147_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +10 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-iclb5/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#1528]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl2/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +12 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@i915_selftest@live@execlists: - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([i915#656]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl4/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-apl7/igt@i915_selftest@l...@execlists.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl7/igt@i915_susp...@debugfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-apl4/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#72]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_frontbuffer_tracking@fbc-2p-pri-indfb-multidraw: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#118] / [i915#160] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk9/igt@kms_frontbuffer_track...@fbc-2p-pri-indfb-multidraw.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-glk5/igt@kms_frontbuffer_track...@fbc-2p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl7/igt@kms_frontbuffer_track...@fbc-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-apl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17147/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * ig
[Intel-gfx] [PATCH] drm/i915/perf: Enable application triggered OA reports
Gen12 brought an important redesign of the OA unit, splitting it in 2 with a per context part (OAR) and a global part (OAG). OAR deals with per context counters and implements the MI_REPORT_PERF_COUNT command. OAG deals with global counters and the OA buffer. Unfortunately some of the counters available in OAG are not available in OAR, for instance counters that would report global caches utilization. Since applications making use of this want to access those additional OAG counters we can enable them to generate a report from their command buffer into the OA buffer. This is somewhat equivalent to having them doing their own MI_REPORT_PERF_COUNT. The application then parse the OA buffer as they were doing previously, only looking for a begin/end OA report with the appropriate reason field in the OA buffer instead of using MI_REPORT_PERF_COUNT generated reports for begin/end. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 ++ drivers/gpu/drm/i915/i915_perf.c| 10 +++--- drivers/gpu/drm/i915/i915_reg.h | 2 ++ 3 files changed, 27 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index e96cc7fa0936..552eadaa6f9a 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1127,6 +1127,10 @@ static void gen9_whitelist_build(struct i915_wa_list *w) /* WaSendPushConstantsFromMMIO:skl,bxt */ whitelist_reg(w, COMMON_SLICE_CHICKEN2); + + /* Allow userspace trigger OA report generation in OA buffer. */ + whitelist_reg(w, OAREPORTTRIG2); + whitelist_reg(w, OAREPORTTRIG6); } static void skl_whitelist_build(struct intel_engine_cs *engine) @@ -1208,6 +1212,10 @@ static void cnl_whitelist_build(struct intel_engine_cs *engine) /* WaEnablePreemptionGranularityControlByUMD:cnl */ whitelist_reg(w, GEN8_CS_CHICKEN1); + + /* Allow userspace trigger OA report generation in OA buffer. */ + whitelist_reg(w, OAREPORTTRIG2); + whitelist_reg(w, OAREPORTTRIG6); } static void icl_whitelist_build(struct intel_engine_cs *engine) @@ -1237,6 +1245,12 @@ static void icl_whitelist_build(struct intel_engine_cs *engine) whitelist_reg_ext(w, PS_INVOCATION_COUNT, RING_FORCE_TO_NONPRIV_ACCESS_RD | RING_FORCE_TO_NONPRIV_RANGE_4); + + /* +* Allow userspace trigger OA report generation in OA buffer. +*/ + whitelist_reg(w, OAREPORTTRIG2); + whitelist_reg(w, OAREPORTTRIG6); break; case VIDEO_DECODE_CLASS: @@ -1281,6 +1295,10 @@ static void tgl_whitelist_build(struct intel_engine_cs *engine) /* Wa_1806527549:tgl */ whitelist_reg(w, HIZ_CHICKEN); + + /* Allow userspace trigger OA report generation in OA buffer. */ + whitelist_reg(w, GEN12_OAG_OAREPORTTRIG2); + whitelist_reg(w, GEN12_OAG_OAREPORTTRIG6); break; default: break; diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 28e3d76fa2e6..ae935b1b1ae3 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -1450,7 +1450,8 @@ static void gen8_init_oa_buffer(struct i915_perf_stream *stream) * bit." */ intel_uncore_write(uncore, GEN8_OABUFFER, gtt_offset | - OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT); + OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT | + GEN8_OABUFFER_EDGE_TRIGGER); intel_uncore_write(uncore, GEN8_OATAILPTR, gtt_offset & GEN8_OATAILPTR_MASK); /* Mark that we need updated tail pointers to read from... */ @@ -1503,7 +1504,8 @@ static void gen12_init_oa_buffer(struct i915_perf_stream *stream) * bit." */ intel_uncore_write(uncore, GEN12_OAG_OABUFFER, gtt_offset | - OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT); + OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT | + GEN12_OAG_OABUFFER_EDGE_TRIGGER); intel_uncore_write(uncore, GEN12_OAG_OATAILPTR, gtt_offset & GEN12_OAG_OATAILPTR_MASK); @@ -4481,8 +4483,10 @@ int i915_perf_ioctl_version(void) * * 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the *interval for the hrtimer used to check for OA data. +* +* 6. Add edge trigger report generation support. */ - return 5; + return 6; } #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 17484345cb80..813ae77ffeb7 100644 --- a/d
[Intel-gfx] [PATCH v3 0/3] i915 lpsp support for lpsp igt
This is resend of v3 to get CI results with igt v4 lpsp platform agnostic support. https://patchwork.freedesktop.org/series/74647/ Test-with: 20200331103330.31211-2-anshuman.gu...@intel.com Anshuman Gupta (3): drm/i915: Power well id for ICL PG3 drm/i915: Add i915_lpsp_info debugfs drm/i915: Add connector dbgfs for all connectors .../gpu/drm/i915/display/intel_connector.c| 3 + .../drm/i915/display/intel_display_debugfs.c | 124 ++ .../drm/i915/display/intel_display_power.c| 6 +- .../drm/i915/display/intel_display_power.h| 4 +- drivers/gpu/drm/i915/display/intel_dp.c | 3 - drivers/gpu/drm/i915/display/intel_hdmi.c | 3 - 6 files changed, 133 insertions(+), 10 deletions(-) -- 2.26.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/3] drm/i915: Power well id for ICL PG3
Gen11 onwards PG3 is contains functions for pipe B,
external displays, and VGA. It make sense to add
a power well id with name ICL_DISP_PW_3 rather then
TGL_DISP_PW_3, Also PG3 power well id requires to
know if lpsp is enabled.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display_power.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 433e5a81dd4d..3672c00be94a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -943,7 +943,7 @@ static void assert_can_enable_dc5(struct drm_i915_private
*dev_priv)
/* Power wells at this level and above must be disabled for DC5 entry */
if (INTEL_GEN(dev_priv) >= 12)
- high_pg = TGL_DISP_PW_3;
+ high_pg = ICL_DISP_PW_3;
else
high_pg = SKL_DISP_PW_2;
@@ -3571,7 +3571,7 @@ static const struct i915_power_well_desc
icl_power_wells[] = {
.name = "power well 3",
.domains = ICL_PW_3_POWER_DOMAINS,
.ops = &hsw_power_well_ops,
- .id = DISP_PW_ID_NONE,
+ .id = ICL_DISP_PW_3,
{
.hsw.regs = &hsw_power_well_regs,
.hsw.idx = ICL_PW_CTL_IDX_PW_3,
@@ -3949,7 +3949,7 @@ static const struct i915_power_well_desc
tgl_power_wells[] = {
.name = "power well 3",
.domains = TGL_PW_3_POWER_DOMAINS,
.ops = &hsw_power_well_ops,
- .id = TGL_DISP_PW_3,
+ .id = ICL_DISP_PW_3,
{
.hsw.regs = &hsw_power_well_regs,
.hsw.idx = ICL_PW_CTL_IDX_PW_3,
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index da64a5edae7a..56cbae6327b7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -100,7 +100,7 @@ enum i915_power_well_id {
SKL_DISP_PW_MISC_IO,
SKL_DISP_PW_1,
SKL_DISP_PW_2,
- TGL_DISP_PW_3,
+ ICL_DISP_PW_3,
SKL_DISP_DC_OFF,
};
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/3] drm/i915: Add i915_lpsp_info debugfs
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.
v2:
- CI fixup.
v3:
- register i915_lpsp_info only for supported connector. [Jani]
- use intel_display_power_well_is_enabled() instead of looking
inside power_well count. [Jani]
- fixes the lpsp capable conditional logic. [Jani]
- combined the lpsp capable and enable info. [Jani]
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_debugfs.c | 124 ++
.../drm/i915/display/intel_display_power.h| 2 +
2 files changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 424f4e52f783..b185c4617468 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -9,6 +9,7 @@
#include "i915_debugfs.h"
#include "intel_csr.h"
#include "intel_display_debugfs.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_fbc.h"
@@ -611,6 +612,98 @@ static void intel_hdcp_info(struct seq_file *m,
seq_puts(m, "\n");
}
+#define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP capable\n") : seq_puts(m,
"LPSP incapable\n"))
+#define LPSP_ENABLE(COND) (COND ? seq_puts(m, "LPSP enabled\n") : seq_puts(m,
"LPSP disabled\n"))
+
+/* LVDS also an embedded panel but we are not interested in it */
+static bool intel_have_embedded_panel(struct drm_connector *connector)
+{
+ return connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP;
+}
+
+static bool intel_have_gen9_lpsp_panel(struct drm_connector *connector)
+{
+ return intel_have_embedded_panel(connector) ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort;
+}
+
+static bool intel_have_lpsp_supported_panel(struct drm_connector *connector)
+{
+ return intel_have_gen9_lpsp_panel(connector) ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIB;
+}
+
+static bool
+intel_lpsp_power_well_enabled(struct drm_i915_private *dev_priv,
+ enum i915_power_well_id power_well_id)
+{
+ intel_wakeref_t wakeref;
+ bool is_enabled;
+
+ wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
+ is_enabled = intel_display_power_well_is_enabled(dev_priv,
+power_well_id);
+ intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
+
+ return is_enabled;
+}
+
+static void
+intel_lpsp_gen12_helper(struct seq_file *m, struct drm_connector *connector)
+{
+ struct intel_encoder *encoder =
+ intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ bool lpsp_capable = false;
+
+ if (IS_TIGERLAKE(dev_priv))
+ lpsp_capable = encoder->port <= PORT_C;
+
+ LPSP_CAPABLE(lpsp_capable);
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv, ICL_DISP_PW_3));
+}
+
+static void
+intel_lpsp_gen11_helper(struct seq_file *m, struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ LPSP_CAPABLE(intel_have_embedded_panel(connector));
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv, ICL_DISP_PW_3));
+}
+
+static void
+intel_lpsp_gen9_helper(struct seq_file *m, struct drm_connector *connector)
+{
+ struct intel_encoder *encoder =
+ intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ LPSP_CAPABLE(encoder->port == PORT_A &&
+intel_have_gen9_lpsp_panel(connector));
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv, SKL_DISP_PW_2));
+}
+
+static void
+intel_lpsp_legacy_gen_helper(struct seq_file *m,
+struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* Apart from HASWELL/BROADWELL other legacy platform doesn't
+* support lpsp.
+*/
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+ LPSP_CAPABLE(connector->connector_type ==
DRM_MODE_CONNECTOR_eDP);
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv,
HSW_DISP_PW_GLOBAL));
+ } else {
+ seq_puts(m, "LPSP not supported\n");
+ }
+}
+
static void intel_dp_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
@@ -1987,6 +2080,33 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
[Intel-gfx] [PATCH v3 3/3] drm/i915: Add connector dbgfs for all connectors
Add connector debugfs attributes for each intel
connector which is getting register.
v2:
- adding connector debugfs for each connector in
intel_connector_register() to fix CI failure for legacy connectors.
Reviewed-by: Jani Nikula
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_connector.c | 3 +++
drivers/gpu/drm/i915/display/intel_dp.c| 3 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ---
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 98ec2ea86c7c..406e96785c76 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -33,6 +33,7 @@
#include "i915_drv.h"
#include "intel_connector.h"
+#include "intel_display_debugfs.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
@@ -123,6 +124,8 @@ int intel_connector_register(struct drm_connector
*connector)
goto err_backlight;
}
+ intel_connector_debugfs_add(connector);
+
return 0;
err_backlight:
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2e715e6d7bb4..43751b573d60 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -48,7 +48,6 @@
#include "intel_audio.h"
#include "intel_connector.h"
#include "intel_ddi.h"
-#include "intel_display_debugfs.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_dp_link_training.h"
@@ -6206,8 +6205,6 @@ intel_dp_connector_register(struct drm_connector
*connector)
if (ret)
return ret;
- intel_connector_debugfs_add(connector);
-
DRM_DEBUG_KMS("registering %s bus for %s\n",
intel_dp->aux.name, connector->kdev->kobj.name);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0076abc63851..1f28153babbf 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -44,7 +44,6 @@
#include "intel_audio.h"
#include "intel_connector.h"
#include "intel_ddi.h"
-#include "intel_display_debugfs.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_dpio_phy.h"
@@ -2860,8 +2859,6 @@ intel_hdmi_connector_register(struct drm_connector
*connector)
if (ret)
return ret;
- intel_connector_debugfs_add(connector);
-
intel_hdmi_create_i2c_symlink(connector);
return ret;
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++--
include/uapi/drm/i915_drm.h | 21
2 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 112bb5bd6665..a6d82329c178 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3696,7 +3696,8 @@ static int read_properties_unlocked(struct i915_perf
*perf,
struct perf_open_properties *props)
{
u64 __user *uprop = uprops;
- u32 i;
+ u32 __user *uctx_handles = NULL;
+ u32 i, n_uctx_handles = 0;
int err;
memset(props, 0, sizeof(struct perf_open_properties));
@@ -3747,7 +3748,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
switch ((enum drm_i915_perf_property_id)id) {
case DRM_I915_PERF_PROP_CTX_HANDLE:
- if (props->n_ctx_handles > 0) {
+ if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
DRM_DEBUG("Context handle specified multiple
times\n");
err = -EINVAL;
goto error;
@@ -3859,6 +3860,38 @@ static int read_properties_unlocked(struct i915_perf
*perf,
}
props->poll_oa_period = value;
break;
+ case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY:
+ /* HSW can only filter in HW and only on a single
+* context.
+*/
+ if (IS_HASWELL(perf->i915)) {
+ DRM_DEBUG("Multi context filter not supported
on HSW\n");
+ err = -ENODEV;
+ goto error;
+ }
+ uctx_handles = u64_to_user_ptr(value);
+ break;
+ case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH:
+ if (IS_HASWELL(perf->i915)) {
+ DRM_DEBUG("Multi context filter not supported
on HSW\n");
+ err = -ENODEV;
+ goto error;
+ }
+ if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
+ DRM_DEBUG("Context handle specified multiple
times\n");
+ err = -EINVAL;
+ goto error;
+ }
+ props->ctx_handles =
+ kmalloc_array(value,
+ sizeof(*props->ctx_handles),
+ GFP_KERNEL);
+ if (!props->ctx_handles) {
+ err = -ENOMEM;
+ goto error;
+ }
+ n_uctx_handles = value;
+ break;
case DRM_I915_PERF_PROP_MAX:
MISSING_CASE(id);
err = -EINVAL;
@@ -3868,6 +3901,21 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ if (n_uctx_handles > 0 && props->n_ctx_handles > 0) {
+ DRM_DEBUG("Context handle specified multiple times\n");
+ err = -EINVAL;
+ goto error;
+ }
+
+ for (i = 0; i < n_uctx_handles; i++) {
+ err = get_user(props->ctx_handles[i], uctx_handles);
+ if (err)
+ goto error;
+
+ uctx_handles++;
+ props->n_ctx_handles++;
+ }
+
return 0;
error:
@@ -4653,8 +4701,12 @@ int i915_perf_ioctl_version(void)
*interval for the hrtimer used to check for OA data.
*
* 6. Add edge trigger report generation support.
+*
+* 7: Add DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY &
+*DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH to allow an
+*application monitor/pin multiple contexts.
*/
- return 6;
+ return 7;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..d2ec2eb98aed 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1993,6 +1993,27 @@ enum drm_i915_perf_property_id {
*/
DRM_I915_PERF_PROP_POLL_OA_PERIOD,
+ /**
+* Specifies an array of u32 GEM context handles to filter reports
+* with.
+*
+* Usin
[Intel-gfx] [PATCH v2 2/3] drm/i915/perf: prepare driver to receive multiple ctx handles
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 584 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 23 +-
2 files changed, 362 insertions(+), 245 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8b28afb0526e..112bb5bd6665 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
*/
#include
+#include
#include
#include
@@ -329,7 +330,8 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
* @single_context: Whether a single or all gpu contexts should be monitored
* @hold_preemption: Whether the preemption is disabled for the filtered
* context
- * @ctx_handle: A gem ctx handle for use with @single_context
+ * @n_ctx_handles: Length of @ctx_handles
+ * @ctx_handles: An array of gem context handles
* @metrics_set: An ID for an OA unit metric set advertised via sysfs
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
@@ -349,9 +351,10 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
struct perf_open_properties {
u32 sample_flags;
- u64 single_context:1;
u64 hold_preemption:1;
- u64 ctx_handle;
+
+ u32 n_ctx_handles;
+ u32 *ctx_handles;
/* OA sampling state */
int metrics_set;
@@ -625,6 +628,21 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return 0;
}
+static int ctx_id_equal(const void *key, const void *elem)
+{
+ return *((int *) elem) - *((int *) key);
+}
+
+static inline bool ctx_id_match(struct i915_perf_stream *stream,
+ u32 masked_ctx_id)
+{
+ return bsearch(&masked_ctx_id,
+ stream->ctx_ids,
+ stream->n_ctxs,
+ sizeof(*stream->ctx_ids),
+ ctx_id_equal) != NULL;
+}
+
/**
* Copies all buffered OA reports into userspace read() buffer.
* @stream: An i915-perf stream opened for OA metrics
@@ -736,7 +754,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
continue;
}
- ctx_id = report32[2] & stream->specific_ctx_id_mask;
+ ctx_id = report32[2] & stream->ctx_id_mask;
/*
* Squash whatever is in the CTX_ID field if it's marked as
@@ -781,26 +799,33 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* switches since it's not-uncommon for periodic samples to
* identify a switch before any 'context switch' report.
*/
- if (!stream->perf->exclusive_stream->ctx ||
- stream->specific_ctx_id == ctx_id ||
- stream->oa_buffer.last_ctx_id == stream->specific_ctx_id ||
- reason & OAREPORT_REASON_CTX_SWITCH) {
-
- /*
-* While filtering for a single context we avoid
-* leaking the IDs of other contexts.
-*/
- if (stream->perf->exclusive_stream->ctx &&
- stream->specific_ctx_id != ctx_id) {
- report32[2] = INVALID_CTX_ID;
- }
-
+ if (!stream->perf->exclusive_stream->n_ctxs) {
ret = append_oa_sample(stream, buf, count, offset,
report);
if (ret)
break;
+ } else {
+ bool ctx_match = ctx_id != INVALID_CTX_ID &&
+ ctx_id_match(stream, ctx_id);
+
+ if (ctx_match ||
+ stream->oa_buffer.last_ctx_match ||
+ reason & OAREPORT_REASON_CTX_SWITCH) {
+
+ /*
+* While filtering for a single context we avoid
+* leaking the IDs of other contexts.
+*/
+ if (!ctx_match)
+ report32[2] = INVALID_CTX_ID;
+
+ ret = append_oa_sample(stream, buf, count,
offset,
+ report);
+ if (ret)
+ break;
+ }
- stream->oa_buffer.last_ctx_id = ctx_id;
+ stream->oa_buffer.last_ctx_match = ctx_match;
}
/*
@@ -1191,138 +1216,163 @@ static int i915_oa_read(struct i915_
[Intel-gfx] [PATCH v2 1/3] drm/i915/perf: break OA config buffer object in 2
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
configurations are per context.
v2: Use an offset into the same VMA (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 176 ---
1 file changed, 116 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ae935b1b1ae3..8b28afb0526e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -372,6 +372,7 @@ struct i915_oa_config_bo {
struct i915_oa_config *oa_config;
struct i915_vma *vma;
+ uint32_t per_context_offset;
};
static struct ctl_table_header *sysctl_header;
@@ -1828,37 +1829,43 @@ static struct i915_oa_config_bo *
alloc_oa_config_buffer(struct i915_perf_stream *stream,
struct i915_oa_config *oa_config)
{
- struct drm_i915_gem_object *obj;
struct i915_oa_config_bo *oa_bo;
+ struct drm_i915_gem_object *obj;
size_t config_length = 0;
- u32 *cs;
+ u32 *cs_start, *cs;
int err;
oa_bo = kzalloc(sizeof(*oa_bo), GFP_KERNEL);
if (!oa_bo)
return ERR_PTR(-ENOMEM);
+ /*
+* Global configuration requires a jump into the NOA wait BO for it to
+* apply.
+*/
config_length += num_lri_dwords(oa_config->mux_regs_len);
config_length += num_lri_dwords(oa_config->b_counter_regs_len);
- config_length += num_lri_dwords(oa_config->flex_regs_len);
config_length += 3; /* MI_BATCH_BUFFER_START */
+
+ config_length += num_lri_dwords(oa_config->flex_regs_len);
+ config_length += 1 /* MI_BATCH_BUFFER_END */;
+
config_length = ALIGN(sizeof(u32) * config_length, I915_GTT_PAGE_SIZE);
- obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);
+ obj = i915_gem_object_create_shmem(stream->perf->i915,
+ config_length);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
goto err_free;
}
- cs = i915_gem_object_pin_map(obj, I915_MAP_WB);
- if (IS_ERR(cs)) {
- err = PTR_ERR(cs);
- goto err_oa_bo;
+ cs_start = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(cs_start)) {
+ err = PTR_ERR(cs_start);
+ goto err_bo;
}
- cs = write_cs_mi_lri(cs,
-oa_config->mux_regs,
-oa_config->mux_regs_len);
+ cs = cs_start;
cs = write_cs_mi_lri(cs,
oa_config->b_counter_regs,
oa_config->b_counter_regs_len);
@@ -1873,6 +1880,14 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
*cs++ = i915_ggtt_offset(stream->noa_wait);
*cs++ = 0;
+ oa_bo->per_context_offset = 4 * (cs - cs_start);
+
+ cs = write_cs_mi_lri(cs,
+oa_config->mux_regs,
+oa_config->mux_regs_len);
+
+ *cs++ = MI_BATCH_BUFFER_END;
+
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
@@ -1881,7 +1896,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
NULL);
if (IS_ERR(oa_bo->vma)) {
err = PTR_ERR(oa_bo->vma);
- goto err_oa_bo;
+ goto err_bo;
}
oa_bo->oa_config = i915_oa_config_get(oa_config);
@@ -1889,15 +1904,15 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
return oa_bo;
-err_oa_bo:
+err_bo:
i915_gem_object_put(obj);
err_free:
kfree(oa_bo);
return ERR_PTR(err);
}
-static struct i915_vma *
-get_oa_vma(struct i915_perf_stream *stream, struct i915_oa_config *oa_config)
+static struct i915_oa_config_bo *
+get_oa_bo(struct i915_perf_stream *stream, struct i915_oa_config *oa_config)
{
struct i915_oa_config_bo *oa_bo;
@@ -1910,34 +1925,31 @@ get_oa_vma(struct i915_perf_stream *stream, struct
i915_oa_config *oa_config)
memcmp(oa_bo->oa_config->uuid,
oa_config->uuid,
sizeof(oa_config->uuid)) == 0)
- goto out;
+ return oa_bo;
}
- oa_bo = alloc_oa_config_buffer(stream, oa_config);
- if (IS_ERR(oa_bo))
- return ERR_CAST(oa_bo);
-
-out:
- return i915_vma_get(oa_bo->vma);
+ return alloc_oa_config_buffer(stream, oa_config);
}
static int
emit_oa_config(struct i915_perf_stream *stream,
struct i915_oa_config *oa_config,
struct intel
[Intel-gfx] [CI] drm/i915: Defer kicking the tasklet until all rescheduling is complete
Since we may kick more than engine, and may kick each one a couple of times, coalesce the tasklet execution to the end. This also ensures that we have the chance to run the tasklet immediately after priority bumping. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_scheduler.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c index 68b06a7ba667..612185674b4e 100644 --- a/drivers/gpu/drm/i915/i915_scheduler.c +++ b/drivers/gpu/drm/i915/i915_scheduler.c @@ -464,11 +464,15 @@ int i915_sched_node_add_dependency(struct i915_sched_node *node, if (!dep) return -ENOMEM; + local_bh_disable(); + if (!__i915_sched_node_add_dependency(node, signal, dep, I915_DEPENDENCY_EXTERNAL | I915_DEPENDENCY_ALLOC)) i915_dependency_free(dep); + local_bh_enable(); /* kick submission tasklet */ + return 0; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Report all failed registers for ctx isolation
Quoting Mika Kuoppala (2020-03-31 12:56:49)
> We want to log all failed registers so don't stop
> on a first.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
The s.e.p. field is failing.
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index d3e163c93e22..7d7b0ab52b63 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -5104,6 +5104,7 @@ static int compare_isolation(struct intel_engine_cs
> *engine,
> {
> u32 x, dw, *hw, *lrc;
> u32 *A[2], *B[2];
> + unsigned long failed;
> int err = 0;
>
> A[0] = i915_gem_object_pin_map(ref[0]->obj, I915_MAP_WC);
> @@ -5136,6 +5137,7 @@ static int compare_isolation(struct intel_engine_cs
> *engine,
> }
> lrc += LRC_STATE_PN * PAGE_SIZE / sizeof(*hw);
>
> + failed = 0;
> x = 0;
> dw = 0;
> hw = engine->pinned_default_state;
> @@ -5169,8 +5171,7 @@ static int compare_isolation(struct intel_engine_cs
> *engine,
>hw[dw], hw[dw + 1],
>A[0][x], B[0][x], B[1][x],
>poison, lrc[dw + 1]);
> - err = -EINVAL;
> - break;
> + failed++;
> }
> }
> dw += 2;
> @@ -5179,6 +5180,9 @@ static int compare_isolation(struct intel_engine_cs
> *engine,
> } while (dw < PAGE_SIZE / sizeof(u32) &&
> (hw[dw] & ~BIT(0)) != MI_BATCH_BUFFER_END);
>
> + if (failed)
> + err = -EINVAL;
> +
> i915_gem_object_unpin_map(ce->state->obj);
> err_B1:
> i915_gem_object_unpin_map(result[1]->obj);
You also want
@@ -5330,13 +5330,15 @@ static int live_lrc_isolation(void *arg)
intel_engine_pm_get(engine);
if (engine->pinned_default_state) {
for (i = 0; i < ARRAY_SIZE(poison); i++) {
- err = __lrc_isolation(engine, poison[i]);
- if (err)
- break;
+ int result;
- err = __lrc_isolation(engine, ~poison[i]);
- if (err)
- break;
+ result = __lrc_isolation(engine, poison[i]);
+ if (result && !err)
+ err = result;
+
+ result = __lrc_isolation(engine, ~poison[i]);
+ if (result && !err)
+ err = result;
}
}
intel_engine_pm_put(engine);
for this mode.
With that or as a separate patch,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Include a few tracek for timeslicing
Add a few telltales to see when timeslicing is being enabled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 20 +---
drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 744737e57d1d..55bf3cdf3b38 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1814,16 +1814,25 @@ active_timeslice(const struct intel_engine_cs *engine)
static void set_timeslice(struct intel_engine_cs *engine)
{
+ unsigned long duration;
+
if (!intel_engine_has_timeslices(engine))
return;
- set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
+ duration = active_timeslice(engine);
+ ENGINE_TRACE(engine, "bump timeslicing, interval:%lu", duration);
+
+ set_timer_ms(&engine->execlists.timer, duration);
}
static void start_timeslice(struct intel_engine_cs *engine)
{
struct intel_engine_execlists *execlists = &engine->execlists;
- int prio = queue_prio(execlists);
+ const int prio = queue_prio(execlists);
+ unsigned long duration;
+
+ if (!intel_engine_has_timeslices(engine))
+ return;
WRITE_ONCE(execlists->switch_priority_hint, prio);
if (prio == INT_MIN)
@@ -1832,7 +1841,12 @@ static void start_timeslice(struct intel_engine_cs
*engine)
if (timer_pending(&execlists->timer))
return;
- set_timer_ms(&execlists->timer, timeslice(engine));
+ duration = timeslice(engine);
+ ENGINE_TRACE(engine,
+"start timeslicing, prio:%d, interval:%lu",
+prio, duration);
+
+ set_timer_ms(&execlists->timer, duration);
}
static void record_preemption(struct intel_engine_execlists *execlists)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 68b06a7ba667..065176cb0258 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -209,6 +209,12 @@ static void kick_submission(struct intel_engine_cs *engine,
if (!inflight)
goto unlock;
+ ENGINE_TRACE(engine,
+"bumping queue-priority-hint:%d for rq:%llx:%lld,
inflight:%llx:%lld prio %d\n",
+prio,
+rq->fence.context, rq->fence.seqno,
+inflight->fence.context, inflight->fence.seqno,
+inflight->sched.attr.priority);
engine->execlists.queue_priority_hint = prio;
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Report all failed registers for ctx isolation
We want to log all failed registers so don't stop
on a first.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index d3e163c93e22..7d7b0ab52b63 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -5104,6 +5104,7 @@ static int compare_isolation(struct intel_engine_cs
*engine,
{
u32 x, dw, *hw, *lrc;
u32 *A[2], *B[2];
+ unsigned long failed;
int err = 0;
A[0] = i915_gem_object_pin_map(ref[0]->obj, I915_MAP_WC);
@@ -5136,6 +5137,7 @@ static int compare_isolation(struct intel_engine_cs
*engine,
}
lrc += LRC_STATE_PN * PAGE_SIZE / sizeof(*hw);
+ failed = 0;
x = 0;
dw = 0;
hw = engine->pinned_default_state;
@@ -5169,8 +5171,7 @@ static int compare_isolation(struct intel_engine_cs
*engine,
hw[dw], hw[dw + 1],
A[0][x], B[0][x], B[1][x],
poison, lrc[dw + 1]);
- err = -EINVAL;
- break;
+ failed++;
}
}
dw += 2;
@@ -5179,6 +5180,9 @@ static int compare_isolation(struct intel_engine_cs
*engine,
} while (dw < PAGE_SIZE / sizeof(u32) &&
(hw[dw] & ~BIT(0)) != MI_BATCH_BUFFER_END);
+ if (failed)
+ err = -EINVAL;
+
i915_gem_object_unpin_map(ce->state->obj);
err_B1:
i915_gem_object_unpin_map(result[1]->obj);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Fill all the unused space in the GGTT
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last tile row).
Reported-by: Imre Deak
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Imre Deak
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index d8944dabed55..ad56059651b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -191,10 +191,11 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
enum i915_cache_level level,
u32 flags)
{
+ const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, 0);
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
- gen8_pte_t __iomem *gtt_entries;
- const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, 0);
+ gen8_pte_t __iomem *gte;
+ gen8_pte_t __iomem *end;
dma_addr_t addr;
/*
@@ -202,10 +203,16 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
- gtt_entries += vma->node.start / I915_GTT_PAGE_SIZE;
+ gte = (gen8_pte_t __iomem *)ggtt->gsm;
+ gte += vma->node.start / I915_GTT_PAGE_SIZE;
+ end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, sgt_iter, vma->pages)
- gen8_set_pte(gtt_entries++, pte_encode | addr);
+ gen8_set_pte(gte++, pte_encode | addr);
+ GEM_BUG_ON(gte > end);
+
+ /* Fill the allocated but "unused" space beyond the end of the buffer */
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0].encode);
/*
* We want to flush the TLBs only after we're certain all the PTE
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Include a few tracek for timeslicing
Chris Wilson writes:
> Add a few telltales to see when timeslicing is being enabled.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 20 +---
> drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
> 2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 744737e57d1d..55bf3cdf3b38 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1814,16 +1814,25 @@ active_timeslice(const struct intel_engine_cs *engine)
>
> static void set_timeslice(struct intel_engine_cs *engine)
> {
> + unsigned long duration;
> +
> if (!intel_engine_has_timeslices(engine))
> return;
>
> - set_timer_ms(&engine->execlists.timer, active_timeslice(engine));
> + duration = active_timeslice(engine);
> + ENGINE_TRACE(engine, "bump timeslicing, interval:%lu", duration);
> +
> + set_timer_ms(&engine->execlists.timer, duration);
> }
>
> static void start_timeslice(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists *execlists = &engine->execlists;
> - int prio = queue_prio(execlists);
> + const int prio = queue_prio(execlists);
> + unsigned long duration;
> +
> + if (!intel_engine_has_timeslices(engine))
> + return;
>
> WRITE_ONCE(execlists->switch_priority_hint, prio);
> if (prio == INT_MIN)
> @@ -1832,7 +1841,12 @@ static void start_timeslice(struct intel_engine_cs
> *engine)
> if (timer_pending(&execlists->timer))
> return;
>
> - set_timer_ms(&execlists->timer, timeslice(engine));
> + duration = timeslice(engine);
> + ENGINE_TRACE(engine,
> + "start timeslicing, prio:%d, interval:%lu",
> + prio, duration);
> +
> + set_timer_ms(&execlists->timer, duration);
> }
>
> static void record_preemption(struct intel_engine_execlists *execlists)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 68b06a7ba667..065176cb0258 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -209,6 +209,12 @@ static void kick_submission(struct intel_engine_cs
> *engine,
> if (!inflight)
> goto unlock;
>
> + ENGINE_TRACE(engine,
> + "bumping queue-priority-hint:%d for rq:%llx:%lld,
> inflight:%llx:%lld prio %d\n",
> + prio,
> + rq->fence.context, rq->fence.seqno,
> + inflight->fence.context, inflight->fence.seqno,
> + inflight->sched.attr.priority);
> engine->execlists.queue_priority_hint = prio;
>
> /*
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/selftests: Tidy up an error message for live_error_interrupt
Chris Wilson writes:
> Since we don't wait for the error interrupt to reset, restart and then
> complete the guilty request, clean up the error messages.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index d3e163c93e22..b929e52a8f5a 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -649,9 +649,9 @@ static int live_error_interrupt(void *arg)
>error_repr(p->error[i]));
>
> if (!i915_request_started(client[i])) {
> - pr_debug("%s: %s request not stated!\n",
> - engine->name,
> - error_repr(p->error[i]));
> + pr_err("%s: %s request not started!\n",
> +engine->name,
> +error_repr(p->error[i]));
> err = -ETIME;
> goto out;
> }
> @@ -659,9 +659,10 @@ static int live_error_interrupt(void *arg)
> /* Kick the tasklet to process the error */
> intel_engine_flush_submission(engine);
> if (client[i]->fence.error != p->error[i]) {
> - pr_err("%s: %s request completed with
> wrong error code: %d\n",
> + pr_err("%s: %s request (%s) with wrong
> error code: %d\n",
> engine->name,
> error_repr(p->error[i]),
> +
> i915_request_completed(client[i]) ? "completed" : "running",
> client[i]->fence.error);
> err = -EINVAL;
> goto out;
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/execlists: Pause CS flow before reset
Chris Wilson writes: > Since we may be attempting to reset an active engine, we try to freeze > it in place before resetting -- to be on the safe side. We can go one > step further if we are using the CS flow semaphore to prevent the > context switching into the next. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c > b/drivers/gpu/drm/i915/gt/intel_lrc.c > index 9fff4e02cee6..9e18c0896a83 100644 > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > @@ -3669,6 +3669,7 @@ static void execlists_reset_prepare(struct > intel_engine_cs *engine) >* >* FIXME: Wa for more modern gens needs to be validated >*/ > + ring_set_paused(engine, 1); > intel_engine_stop_cs(engine); > } > > -- > 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 5.4+
The bot has tested the following trees: v5.5.13, v5.4.28.
v5.5.13: Failed to apply! Possible dependencies:
1326a92c3466 ("drm/i915: Perform automated conversions for crtc uapi/hw
split, base -> hw.")
2225f3c6f1d7 ("drm/i915: Perform automated conversions for crtc uapi/hw
split, base -> uapi.")
2b808b3a27d1 ("drm/i915: Add aliases for uapi and hw to crtc_state")
54ed6902cabc ("drm/i915/dsi: abstract afe_clk calculation")
b7d02c3a124d ("drm/i915: Pass intel_encoder to enc_to_*()")
v5.4.28: Failed to apply! Possible dependencies:
0456417ef680 ("drm: Add for_each_oldnew_intel_crtc_in_state_reverse()")
131d3b1af105 ("drm/i915: Stop using drm_atomic_helper_check_planes()")
2225f3c6f1d7 ("drm/i915: Perform automated conversions for crtc uapi/hw
split, base -> uapi.")
2b808b3a27d1 ("drm/i915: Add aliases for uapi and hw to crtc_state")
2e7f76c1e4b6 ("drm/i915: s/pipe_config/crtc_state/ in
intel_crtc_atomic_check()")
3e30d70805d5 ("drm/i915: Make .modeset_calc_cdclk() mandatory")
54ed6902cabc ("drm/i915/dsi: abstract afe_clk calculation")
af9fbfa657c8 ("drm/i915: Introduce and use
intel_atomic_crtc_state_for_each_plane_state.")
b7d02c3a124d ("drm/i915: Pass intel_encoder to enc_to_*()")
bb6ae9e653dc ("drm/i915: Allow planes to declare their minimum acceptable
cdclk")
d06a79d33e0f ("drm/i915: Use enum pipe instead of crtc index to track
active pipes")
fe4709a8d033 ("drm/i915: Extract intel_modeset_calc_cdclk()")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Include the execlists CCID of each port in the engine dump
== Series Details == Series: drm/i915/gt: Include the execlists CCID of each port in the engine dump URL : https://patchwork.freedesktop.org/series/75298/ State : warning == Summary == $ dim checkpatch origin/drm-tip fed75169a8a6 drm/i915/gt: Include the execlists CCID of each port in the engine dump -:53: WARNING:LONG_LINE: line over 100 characters #53: FILE: drivers/gpu/drm/i915/gt/intel_engine_cs.c:1257: + DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context), total: 0 errors, 1 warnings, 0 checks, 128 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 00/12] Convert PWM period and duty cycle to u64
On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote: > On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote: > > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote: > > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > > > > This is a giant CC list. > > > > > > Yes, this is because I received feedback [1] on an earlier patchset > > > directing me to add the reviewers of patches to the cover letter as > > > well so that they get some context for the patch. > > > ... > > > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html > > > > Strictly speaking I only asked for backlight maintainers to be Cc:ed. > > I was fairly careful to be specific since I'm aware there are a variety > > of differing habits when putting together the Cc: list for covering > > letters. > > > > With the original patch header the purpose of the patch I was Cc:ed on > > was impossible to determine without the covering letter. > > I suspect this might be the case for all the other reviewers as well - > that they also would appreciate context for the specific patch they are > being added to review. > > I wasn't entirely sure what the convention was, so I applied your > suggestion to all the files. How do you suggest I handle this in my next > patchset? I fully agree that such a large CC list does look really > ungainly. IHMO there should not be a mechanical convention. Instead your goal needs to be how to make it as easy as possible to review your patches. Think about it this way: Each person in the To: of a patch (and maybe also Cc: depending on how you construct things) is a person you are asking to review and comment on the patch. If that person will find it easier to review the patch if they are included in the cover letter then either they should be included or you should improve the patch description of the patch itself (sometimes both). Either way it is about optimizing the patchset for readability. More people read them than write them. Daniel. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Report all failed registers for ctx isolation
For CI it is enough to point out a single failure
in isolation. However it is beneficial to gather
info in logs for transients further down
the line.
Do not stop into first comparison failure but
continue probing forward.
v2: for all engines and poisons (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index d3e163c93e22..d5b170adff1c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -5170,7 +5170,6 @@ static int compare_isolation(struct intel_engine_cs
*engine,
A[0][x], B[0][x], B[1][x],
poison, lrc[dw + 1]);
err = -EINVAL;
- break;
}
}
dw += 2;
@@ -5309,6 +5308,7 @@ static int live_lrc_isolation(void *arg)
0x,
0x,
};
+ int err = 0;
/*
* Our goal is try and verify that per-context state cannot be
@@ -5319,7 +5319,6 @@ static int live_lrc_isolation(void *arg)
*/
for_each_engine(engine, gt, id) {
- int err = 0;
int i;
/* Just don't even ask */
@@ -5330,23 +5329,25 @@ static int live_lrc_isolation(void *arg)
intel_engine_pm_get(engine);
if (engine->pinned_default_state) {
for (i = 0; i < ARRAY_SIZE(poison); i++) {
- err = __lrc_isolation(engine, poison[i]);
- if (err)
- break;
+ int result;
- err = __lrc_isolation(engine, ~poison[i]);
- if (err)
- break;
+ result = __lrc_isolation(engine, poison[i]);
+ if (result && !err)
+ err = result;
+
+ result = __lrc_isolation(engine, ~poison[i]);
+ if (result && !err)
+ err = result;
}
}
intel_engine_pm_put(engine);
- if (igt_flush_test(gt->i915))
+ if (igt_flush_test(gt->i915)) {
err = -EIO;
- if (err)
- return err;
+ break;
+ }
}
- return 0;
+ return err;
}
static void garbage_reset(struct intel_engine_cs *engine,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Include the execlists CCID of each port in the engine dump
== Series Details == Series: drm/i915/gt: Include the execlists CCID of each port in the engine dump URL : https://patchwork.freedesktop.org/series/75298/ State : success == Summary == CI Bug Log - changes from CI_DRM_8223 -> Patchwork_17150 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/index.html Changes --- No changes found Participating hosts (41 -> 37) -- Additional (6): fi-bdw-5557u fi-hsw-peppy fi-skl-guc fi-bwr-2160 fi-kbl-7500u fi-ivb-3770 Missing(10): fi-bdw-samus fi-hsw-4200u fi-snb-2520m fi-ctg-p8600 fi-cfl-8109u fi-kbl-7560u fi-byt-clapper fi-bsw-nick fi-skl-6600u fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8223 -> Patchwork_17150 CI-20190529: 20190529 CI_DRM_8223: 1d63647b277eabde6a0a6f1b68b6569482ff4063 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5548: d9e70dc1b35633b7d5c81cbfa165e331189eb260 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17150: fed75169a8a6f90d25d54dd6132ed6b9faaab629 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fed75169a8a6 drm/i915/gt: Include the execlists CCID of each port in the engine dump == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/perf: Do not clear pollin for small user read buffers (rev5)
== Series Details == Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev5) URL : https://patchwork.freedesktop.org/series/75085/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17148_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17148_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17148_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17148_full: ### IGT changes ### Possible regressions * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-snb4/igt@i915_pm_rc6_reside...@rc6-idle.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-snb1/igt@i915_pm_rc6_reside...@rc6-idle.html Known issues Here are the changes found in Patchwork_17148_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +10 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-iclb6/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_suspend@sysfs-reader: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl6/igt@i915_susp...@sysfs-reader.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-kbl4/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#300]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-skl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-kbl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-kbl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#31]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl3/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17148/shard-skl8/igt@kms_setm...@basic.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Utilize rcu iteration of context engines (rev2)
== Series Details == Series: drm/i915/gem: Utilize rcu iteration of context engines (rev2) URL : https://patchwork.freedesktop.org/series/75270/ State : success == Summary == CI Bug Log - changes from CI_DRM_8223 -> Patchwork_17151 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/index.html Known issues Here are the changes found in Patchwork_17151 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] ([i915#1430] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (41 -> 43) -- Additional (6): fi-bdw-5557u fi-hsw-peppy fi-skl-guc fi-bwr-2160 fi-kbl-7500u fi-ivb-3770 Missing(4): fi-ctg-p8600 fi-byt-clapper fi-bdw-samus fi-hsw-4200u Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8223 -> Patchwork_17151 CI-20190529: 20190529 CI_DRM_8223: 1d63647b277eabde6a0a6f1b68b6569482ff4063 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5548: d9e70dc1b35633b7d5c81cbfa165e331189eb260 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17151: c8a455ae5b6044259ff17fcb49dbb9125d3be278 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c8a455ae5b60 drm/i915/gem: Utilize rcu iteration of context engines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Add request throughput measurement to perf
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
94cc68dbc29b drm/i915/selftests: Add request throughput measurement to perf
-:96: WARNING:LINE_SPACING: Missing a blank line after declarations
#96: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1525:
+ struct perf_series *ps = arg;
+ IGT_TIMEOUT(end_time);
-:130: WARNING:LINE_SPACING: Missing a blank line after declarations
#130: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1559:
+ struct i915_request *prev = NULL;
+ IGT_TIMEOUT(end_time);
-:165: WARNING:LINE_SPACING: Missing a blank line after declarations
#165: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1594:
+ struct perf_series *ps = arg;
+ IGT_TIMEOUT(end_time);
-:188: WARNING:LINE_SPACING: Missing a blank line after declarations
#188: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1617:
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
-:196: WARNING:LINE_SPACING: Missing a blank line after declarations
#196: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1625:
+ struct intel_engine_cs *engine;
+ int (* const *fn)(void *arg);
-:325: WARNING:LINE_SPACING: Missing a blank line after declarations
#325: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1754:
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
-:393: WARNING:LINE_SPACING: Missing a blank line after declarations
#393: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1822:
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
-:462: WARNING:LINE_SPACING: Missing a blank line after declarations
#462: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1891:
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
-:518: WARNING:LINE_SPACING: Missing a blank line after declarations
#518: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1947:
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
-:526: WARNING:LINE_SPACING: Missing a blank line after declarations
#526: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1955:
+ struct intel_engine_cs *engine;
+ int (* const *fn)(void *arg);
-:571: WARNING:YIELD: Using yield() is generally wrong. See yield() kernel-doc
(sched/core.c)
#571: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:2000:
+ yield(); /* start all threads before we kthread_stop() */
total: 0 errors, 11 warnings, 0 checks, 611 lines checked
4542d6196afe drm/i915/gt: Yield the timeslice if caught waiting on a user
semaphore
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Return the right vswing tables
On Mon, Mar 30, 2020 at 07:24:55PM +, Souza, Jose wrote:
> On Mon, 2020-03-30 at 17:50 +0300, Ville Syrjälä wrote:
> > On Fri, Mar 27, 2020 at 02:34:11PM -0700, José Roberto de Souza
> > wrote:
> > > DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type
> > > and
> > > later eDP ports that have the type changed to INTEL_OUTPUT_EDP.
> > > But for all other DDI ports it can drive HDMI or DP depending on
> > > what
> > > user connects to the ports.
> > >
> > > ehl_get_combo_buf_trans() and tgl_get_combo_buf_trans() was
> > > checking
> > > for INTEL_OUTPUT_DP that was never true, causing eDP vswing tables
> > > being used.
> > >
> > > So here changing the check to INTEL_OUTPUT_DDI, HDMI cases will be
> > > correctly handled as it do not use encoder->type, instead it calls
> > > the
> > > functions with INTEL_OUTPUT_HDMI as type parameter and HDMI don't
> > > have
> > > retraining.
> > >
> > > Fixes: bd3cf6f7ce20 ("drm/i915/dp/tgl+: Update combo phy vswing
> > > tables")
> > > Cc: Clinton A Taylor
> > > Cc: Matt Roper
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 916a802af788..7af1572d4f1d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -947,7 +947,7 @@ static const struct cnl_ddi_buf_trans *
> > > ehl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int
> > > type, int rate,
> > > int *n_entries)
> > > {
> > > - if (type == INTEL_OUTPUT_DP && rate > 27) {
> > > + if (type == INTEL_OUTPUT_DDI && rate > 27) {
> >
> > Please no. I'd rather not see "DDI" here. We want to check which mode
> > we're driving the output in, and "DDI" isn't one of the valid
> > choices.
> >
> > The fact that we sometimes pass in encoder->type is a bit of shortcut
> > to make the DP vs. EDP distinction. And so far every function knew to
> > only compare the value against EDP/HDMI and neve against DP. Looks
> > like
> > someone broke that (admittedly crappy) convention.
> >
> > We should probably fix this a bit higher up and make sure we only
> > ever
> > pass in EDP/DP/HDMI, never DDI.
>
> Okay so for now I will just do the bellow:
>
> if (type != INTEL_OUTPUT_EDP && type != INTEL_OUTPUT_HDMI && rate >
> 27) {
>
> Good enough for now?
Works for me.
> >
> > > *n_entries =
> > > ARRAY_SIZE(ehl_combo_phy_ddi_translations_hbr2_hbr3);
> > > return ehl_combo_phy_ddi_translations_hbr2_hbr3;
> > > }
> > > @@ -959,7 +959,7 @@ static const struct cnl_ddi_buf_trans *
> > > tgl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int
> > > type, int rate,
> > > int *n_entries)
> > > {
> > > - if (type != INTEL_OUTPUT_DP) {
> > > + if (type != INTEL_OUTPUT_DDI) {
> > > return icl_get_combo_buf_trans(dev_priv, type, rate,
> > > n_entries);
> > > } else if (rate > 27) {
> > > *n_entries =
> > > ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
> > > --
> > > 2.26.0
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Include the execlists CCID of each port in the engine dump
Chris Wilson writes:
> Since we print out EXECLISTS_STATUS in the dump, also print out the CCID
> of each context so we can cross check between the two.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 105 --
> 1 file changed, 56 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index dff0bbe9e1a6..b01af08eaaf7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1221,6 +1221,49 @@ static void print_request(struct drm_printer *m,
> name);
> }
>
> +static struct intel_timeline *get_timeline(struct i915_request *rq)
> +{
> + struct intel_timeline *tl;
> +
> + /*
> + * Even though we are holding the engine->active.lock here, there
> + * is no control over the submission queue per-se and we are
> + * inspecting the active state at a random point in time, with an
> + * unknown queue. Play safe and make sure the timeline remains valid.
> + * (Only being used for pretty printing, one extra kref shouldn't
> + * cause a camel stampede!)
> + */
> + rcu_read_lock();
> + tl = rcu_dereference(rq->timeline);
> + if (!kref_get_unless_zero(&tl->kref))
> + tl = NULL;
> + rcu_read_unlock();
> +
> + return tl;
> +}
> +
> +static int print_ring(char *buf, int sz, struct i915_request *rq)
> +{
> + int len = 0;
> +
> + if (!i915_request_signaled(rq)) {
> + struct intel_timeline *tl = get_timeline(rq);
> +
> + len = scnprintf(buf, sz,
> + "ring:{start:%08x, hwsp:%08x, seqno:%08x,
> runtime:%llums}, ",
> + i915_ggtt_offset(rq->ring->vma),
> + tl ? tl->hwsp_offset : 0,
> + hwsp_seqno(rq),
> +
> DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
> + 1000 * 1000));
> +
> + if (tl)
> + intel_timeline_put(tl);
> + }
> +
> + return len;
> +}
> +
> static void hexdump(struct drm_printer *m, const void *buf, size_t len)
> {
> const size_t rowsize = 8 * sizeof(u32);
> @@ -1250,27 +1293,6 @@ static void hexdump(struct drm_printer *m, const void
> *buf, size_t len)
> }
> }
>
> -static struct intel_timeline *get_timeline(struct i915_request *rq)
> -{
> - struct intel_timeline *tl;
> -
> - /*
> - * Even though we are holding the engine->active.lock here, there
> - * is no control over the submission queue per-se and we are
> - * inspecting the active state at a random point in time, with an
> - * unknown queue. Play safe and make sure the timeline remains valid.
> - * (Only being used for pretty printing, one extra kref shouldn't
> - * cause a camel stampede!)
> - */
> - rcu_read_lock();
> - tl = rcu_dereference(rq->timeline);
> - if (!kref_get_unless_zero(&tl->kref))
> - tl = NULL;
> - rcu_read_unlock();
> -
> - return tl;
> -}
> -
> static const char *repr_timer(const struct timer_list *t)
> {
> if (!READ_ONCE(t->expires))
> @@ -1383,39 +1405,24 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
> int len;
>
> len = scnprintf(hdr, sizeof(hdr),
> - "\t\tActive[%d]: ",
> - (int)(port - execlists->active));
> - if (!i915_request_signaled(rq)) {
> - struct intel_timeline *tl = get_timeline(rq);
> -
> - len += scnprintf(hdr + len, sizeof(hdr) - len,
> - "ring:{start:%08x, hwsp:%08x,
> seqno:%08x, runtime:%llums}, ",
> -
> i915_ggtt_offset(rq->ring->vma),
> - tl ? tl->hwsp_offset : 0,
> - hwsp_seqno(rq),
> -
> DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
> -1000 *
> 1000));
> -
> - if (tl)
> - intel_timeline_put(tl);
> - }
> + "\t\tActive[%d]: ccid:%08x, ",
> + (int)(port - execlists->active),
> + upper_32_bits(rq->context->lrc_desc));
> + len += print_ring(hdr + len, sizeof(hdr) - len, rq);
> scnprintf(hdr + len, sizeof(hdr) - len, "rq: ");
> print_reques
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/selftests: Add request throughput measurement to perf
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Add request throughput measurement to perf URL : https://patchwork.freedesktop.org/series/75301/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8223 -> Patchwork_17152 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17152 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17152, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17152/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17152: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/fi-icl-guc/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17152/fi-icl-guc/igt@i915_selftest@l...@hangcheck.html * igt@runner@aborted: - fi-icl-guc: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17152/fi-icl-guc/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17152 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@common-hpd-after-suspend: - fi-cml-u2: [PASS][4] -> [DMESG-WARN][5] ([IGT#4]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17152/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html [IGT#4]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/4 Participating hosts (41 -> 40) -- Additional (5): fi-hsw-peppy fi-skl-guc fi-bwr-2160 fi-kbl-7500u fi-ivb-3770 Missing(6): fi-hsw-4200u fi-ctg-p8600 fi-skl-lmem fi-blb-e6850 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8223 -> Patchwork_17152 CI-20190529: 20190529 CI_DRM_8223: 1d63647b277eabde6a0a6f1b68b6569482ff4063 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5548: d9e70dc1b35633b7d5c81cbfa165e331189eb260 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17152: 4542d6196afe80c755c038e4b7966acc72f32b0d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4542d6196afe drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore 94cc68dbc29b drm/i915/selftests: Add request throughput measurement to perf == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17152/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fill all the unused space in the GGTT
On Tue, 31 Mar 2020 at 13:42, Chris Wilson wrote: > > When we allocate space in the GGTT we may have to allocate a larger > region than will be populated by the object to accommodate fencing. Make > sure that this space beyond the end of the buffer points safely into > scratch space, in case the HW tries to access it anyway (e.g. fenced > access to the last tile row). > > Reported-by: Imre Deak > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554 > Signed-off-by: Chris Wilson > Cc: Matthew Auld > Cc: Imre Deak > Cc: sta...@vger.kernel.org Do we not need similar treatment for gen6? It seems to also play tricks with the nop clear range, or did we disable gen7 ppgtt in the end? Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fill all the unused space in the GGTT
Quoting Matthew Auld (2020-03-31 16:07:21) > On Tue, 31 Mar 2020 at 13:42, Chris Wilson wrote: > > > > When we allocate space in the GGTT we may have to allocate a larger > > region than will be populated by the object to accommodate fencing. Make > > sure that this space beyond the end of the buffer points safely into > > scratch space, in case the HW tries to access it anyway (e.g. fenced > > access to the last tile row). > > > > Reported-by: Imre Deak > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554 > > Signed-off-by: Chris Wilson > > Cc: Matthew Auld > > Cc: Imre Deak > > Cc: sta...@vger.kernel.org > > Do we not need similar treatment for gen6? It seems to also play > tricks with the nop clear range, or did we disable gen7 ppgtt in the > end? Currently disabled. But yes, if we use nop_clear_range we will need similar clearing. As this method turned out to be much easier than expected, I guess we should just do it anyway. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Fill all the unused space in the GGTT
When we allocate space in the GGTT we may have to allocate a larger
region than will be populated by the object to accommodate fencing. Make
sure that this space beyond the end of the buffer points safely into
scratch space, in case the HW tries to access it anyway (e.g. fenced
access to the last tile row).
v2: Preemptively / conservatively guard gen6 ggtt as well.
Reported-by: Imre Deak
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Imre Deak
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 37
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index d8944dabed55..ae07bcd7c226 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -191,10 +191,11 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
enum i915_cache_level level,
u32 flags)
{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- struct sgt_iter sgt_iter;
- gen8_pte_t __iomem *gtt_entries;
const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, 0);
+ struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+ gen8_pte_t __iomem *gte;
+ gen8_pte_t __iomem *end;
+ struct sgt_iter iter;
dma_addr_t addr;
/*
@@ -202,10 +203,17 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
- gtt_entries += vma->node.start / I915_GTT_PAGE_SIZE;
- for_each_sgt_daddr(addr, sgt_iter, vma->pages)
- gen8_set_pte(gtt_entries++, pte_encode | addr);
+ gte = (gen8_pte_t __iomem *)ggtt->gsm;
+ gte += vma->node.start / I915_GTT_PAGE_SIZE;
+ end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+
+ for_each_sgt_daddr(addr, iter, vma->pages)
+ gen8_set_pte(gte++, pte_encode | addr);
+ GEM_BUG_ON(gte > end);
+
+ /* Fill the allocated but "unused" space beyond the end of the buffer */
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0].encode);
/*
* We want to flush the TLBs only after we're certain all the PTE
@@ -241,13 +249,22 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
u32 flags)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- gen6_pte_t __iomem *entries = (gen6_pte_t __iomem *)ggtt->gsm;
- unsigned int i = vma->node.start / I915_GTT_PAGE_SIZE;
+ gen6_pte_t __iomem *gte;
+ gen6_pte_t __iomem *end;
struct sgt_iter iter;
dma_addr_t addr;
+ gte = (gen6_pte_t __iomem *)ggtt->gsm;
+ gte += vma->node.start / I915_GTT_PAGE_SIZE;
+ end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+
for_each_sgt_daddr(addr, iter, vma->pages)
- iowrite32(vm->pte_encode(addr, level, flags), &entries[i++]);
+ iowrite32(vm->pte_encode(addr, level, flags), gte++);
+ GEM_BUG_ON(gte > end);
+
+ /* Fill the allocated but "unused" space beyond the end of the buffer */
+ while (gte < end)
+ iowrite32(vm->scratch[0].encode, gte++);
/*
* We want to flush the TLBs only after we're certain all the PTE
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fill all the unused space in the GGTT
On Tue, Mar 31, 2020 at 01:42:02PM +0100, Chris Wilson wrote:
> When we allocate space in the GGTT we may have to allocate a larger
> region than will be populated by the object to accommodate fencing. Make
> sure that this space beyond the end of the buffer points safely into
> scratch space, in case the HW tries to access it anyway (e.g. fenced
> access to the last tile row).
>
> Reported-by: Imre Deak
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Imre Deak
> Cc: sta...@vger.kernel.org
Thanks,
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index d8944dabed55..ad56059651b8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -191,10 +191,11 @@ static void gen8_ggtt_insert_entries(struct
> i915_address_space *vm,
>enum i915_cache_level level,
>u32 flags)
> {
> + const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, 0);
> struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
> struct sgt_iter sgt_iter;
> - gen8_pte_t __iomem *gtt_entries;
> - const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, 0);
> + gen8_pte_t __iomem *gte;
> + gen8_pte_t __iomem *end;
> dma_addr_t addr;
>
> /*
> @@ -202,10 +203,16 @@ static void gen8_ggtt_insert_entries(struct
> i915_address_space *vm,
>* not to allow the user to override access to a read only page.
>*/
>
> - gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
> - gtt_entries += vma->node.start / I915_GTT_PAGE_SIZE;
> + gte = (gen8_pte_t __iomem *)ggtt->gsm;
> + gte += vma->node.start / I915_GTT_PAGE_SIZE;
> + end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
> for_each_sgt_daddr(addr, sgt_iter, vma->pages)
> - gen8_set_pte(gtt_entries++, pte_encode | addr);
> + gen8_set_pte(gte++, pte_encode | addr);
> + GEM_BUG_ON(gte > end);
> +
> + /* Fill the allocated but "unused" space beyond the end of the buffer */
> + while (gte < end)
> + gen8_set_pte(gte++, vm->scratch[0].encode);
>
> /*
>* We want to flush the TLBs only after we're certain all the PTE
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/dp/ehl: Update vswing table for HBR and RBR
On Mon, Mar 30, 2020 at 02:00:43PM -0700, José Roberto de Souza wrote:
> EHL has now only one table for all DP rates.
>
> BSpec: 21257
> Signed-off-by: José Roberto de Souza
1-2 are
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 053b21c11b0c..dedb86712a98 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -568,7 +568,7 @@ static const struct cnl_ddi_buf_trans
> icl_combo_phy_ddi_translations_hdmi[] = {
> { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600 850 3.0 */
> };
>
> -static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_hbr2_hbr3[] = {
> +static const struct cnl_ddi_buf_trans ehl_combo_phy_ddi_translations_dp[] = {
> /* NT mV Trans mV db*/
> { 0xA, 0x33, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> { 0xA, 0x47, 0x36, 0x00, 0x09 },/* 350 500 3.1 */
> @@ -947,10 +947,9 @@ static const struct cnl_ddi_buf_trans *
> ehl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int
> rate,
> int *n_entries)
> {
> - if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP &&
> - rate > 27) {
> - *n_entries =
> ARRAY_SIZE(ehl_combo_phy_ddi_translations_hbr2_hbr3);
> - return ehl_combo_phy_ddi_translations_hbr2_hbr3;
> + if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP) {
> + *n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
> + return ehl_combo_phy_ddi_translations_dp;
> }
>
> return icl_get_combo_buf_trans(dev_priv, type, rate, n_entries);
> --
> 2.26.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
On Mon, Mar 30, 2020 at 11:23:24PM +0300, Souza, Jose wrote:
> On Sat, 2020-03-28 at 11:57 +0200, Imre Deak wrote:
> [...]
> > > + if (ret == 0) {
> > > + if (block &&
> > > + low_val & TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED)
> > > + ret = -EIO;
> > > + else
> > > + break;
> > > + }
> > > +
> > > + if (ret != -EAGAIN)
> > > + tries++;
> > > + } while (tries < 3);
> > > +
> > > + return ret;
> >
> > The return value isn't used and I think we can't do much about it, so
> > just make the function a void type and warn about a timeout?
>
> The return is usefull to have just one warm message between ICL and
> TGL.
Ah, in tc_cold_request(), but then we won't use the return value from
that.
> > [...]
> > ICL, I think we need a tc_cold_off power well/domain. The tc_cold_off
> > power ref would be get/put around the FIA access sequence here
> > (intel_tc_port_reset_mode()) and would be held whenever we hold an
> > AUX power ref.
>
> For TGL the tc_cold_off power well would work and would be pretty easy
> to implement but for ICL I'm not sure.
>
> For ICL, because of preemptions we need to get the aux power of the TC
> port before request PCODE to exit TC cold.
>
> So a single tc_cold_off would need to depend into all aux's?
> Even if we have one tc_cold_off per TC DDI, if we make it depend into aux
> we would get aux power enable timeouts. So we would need to enable aux
> power inside of the tc_cold_off enable function and the aux enable call
> would need to not check the HW status.
>
> Thoughts?
On ICL we wouldn't have a power domain/well for tc-cold, since the PCODE
request for it has anyway the strange timeout semantics, without the
proper block/unblock interface like TGL has.
So for ICL you'd need to get an AUX power domain ref here, and the AUX
power well enable hook would do the
enable AUX
block tc-cold
wait for AUX ACK
sequence in the AUX power well's enable hook (for legacy ports).
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 6/6] drm/i915/dp: Get TC link reference during DP detection
On Mon, Mar 30, 2020 at 11:27:06PM +0300, Souza, Jose wrote:
> On Sat, 2020-03-28 at 12:26 +0200, Imre Deak wrote:
> > On Tue, Mar 24, 2020 at 01:14:29PM -0700, José Roberto de Souza
> > wrote:
> > > As now the cost to lock and use a TC port is higher due the
> > > implementation of the TCCOLD sequences it is worty to hold a
> > > reference of the TC port to avoid all this locking at every
> > > aux transaction part of the DisplayPort detection.
> >
> > The problem with locking the port for detection is that it would
> > block modesets on the port, which we should avoid. By blocking
> > tc-cold
>
> It will not block modesets on the port, intel_tc_port_get_link and
> intel_tc_port_put_link gets locks tc_lock, increment or decrement
> tc_link_refcount and then unlock,
The effect of holding a link_refcount is that it's not possible to
update the TC port mode and select the correct TBT/MG PLL for the mode.
This will only be possible in the middle of the modeset sequence where
an active mode is first disabled on the port and that's the place we
don't want to wait for the detect sequence to finish.
So only an active mode should hold a link_refcount, so that it's
guaranteed that a modeset can update the TC port mode to its current
state.
> it would only avoid the TC cold sequences over and over.
Yes, but that would be also avoided by disabling the AUX power well only
with a delay.
>
> > whenever enabling an AUX power well you would avoid the overhead of
> > the
> > PCODE requests for each AUX transfer, since the AUX power refs are
> > dropped asynchronously with a delay.
>
> Left comments on your proposal in patch 1.
>
> >
> > > Cc: Imre Deak
> > > Cc: Cooper Chiou
> > > Cc: Kai-Heng Feng
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 19 ++-
> > > 1 file changed, 14 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 7f1a4e55cda1..6fbf3beee544 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -6041,6 +6041,7 @@ intel_dp_detect(struct drm_connector
> > > *connector,
> > > struct intel_dp *intel_dp =
> > > intel_attached_dp(to_intel_connector(connector));
> > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > struct intel_encoder *encoder = &dig_port->base;
> > > + enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > > enum drm_connector_status status;
> > >
> > > drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s]\n",
> > > @@ -6049,12 +6050,17 @@ intel_dp_detect(struct drm_connector
> > > *connector,
> > > !drm_modeset_is_locked(&dev_priv-
> > > >drm.mode_config.connection_mutex));
> > >
> > > /* Can't disconnect eDP */
> > > - if (intel_dp_is_edp(intel_dp))
> > > + if (intel_dp_is_edp(intel_dp)) {
> > > status = edp_detect(intel_dp);
> > > - else if (intel_digital_port_connected(encoder))
> > > - status = intel_dp_detect_dpcd(intel_dp);
> > > - else
> > > - status = connector_status_disconnected;
> > > + } else {
> > > + if (intel_phy_is_tc(dev_priv, phy))
> > > + intel_tc_port_get_link(dig_port, 1);
> > > +
> > > + if (intel_digital_port_connected(encoder))
> > > + status = intel_dp_detect_dpcd(intel_dp);
> > > + else
> > > + status = connector_status_disconnected;
> > > + }
> > >
> > > if (status == connector_status_disconnected) {
> > > memset(&intel_dp->compliance, 0, sizeof(intel_dp-
> > > >compliance));
> > > @@ -6132,6 +6138,9 @@ intel_dp_detect(struct drm_connector
> > > *connector,
> > > if (status != connector_status_connected && !intel_dp->is_mst)
> > > intel_dp_unset_edid(intel_dp);
> > >
> > > + if (intel_phy_is_tc(dev_priv, phy))
> > > + intel_tc_port_put_link(dig_port);
> > > +
> > > /*
> > >* Make sure the refs for power wells enabled during detect are
> > >* dropped to avoid a new detect cycle triggered by HPD
> > > polling.
> > > --
> > > 2.26.0
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Ignore readonly failures when updating relocs
If the user passes in a readonly reloc[], by the time we notice we have
already commited to modifying the execobjects, or have indeed done so
already. Reporting the failure just compounds the issue as we have no
second pass to fall back to anymore.
Testcase: igt/gem_exec_reloc/readonly
Fixes: 7dc8f1143778 ("drm/i915/gem: Drop relocation slowpath")
References: fddcd00a49e9 ("drm/i915: Force the slow path after a user-write
error")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cda35e6dfc44..bc8aa9604787 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1540,10 +1540,8 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
struct eb_vma *ev)
* can read from this userspace address.
*/
offset = gen8_canonical_addr(offset & ~UPDATE);
- if (unlikely(__put_user(offset,
&urelocs[r-stack].presumed_offset))) {
- remain = -EFAULT;
- goto out;
- }
+ __put_user(offset,
+ &urelocs[r-stack].presumed_offset);
}
} while (r++, --count);
urelocs += ARRAY_SIZE(stack);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] i915/gem_exec_reloc: Smoke test parallel relocations
Check we can handle active gpu relocations across multiple engines
simultaneously without blocking unrelated contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 139
1 file changed, 139 insertions(+)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 275cf6ae9..a9cabbc05 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -21,6 +21,9 @@
* IN THE SOFTWARE.
*/
+#include
+#include
+
#include "igt.h"
#include "igt_dummyload.h"
@@ -704,6 +707,139 @@ static void basic_softpin(int fd)
gem_close(fd, obj[1].handle);
}
+static struct drm_i915_gem_relocation_entry *
+parallel_relocs(int count, unsigned long *out)
+{
+ struct drm_i915_gem_relocation_entry *reloc;
+ unsigned long sz;
+ int i;
+
+ sz = count * sizeof(*reloc);
+ sz = ALIGN(sz, 4096);
+
+ reloc = mmap(0, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
+ igt_assert(reloc != MAP_FAILED);
+ for (i = 0; i < count; i++) {
+ reloc[i].target_handle = 0;
+ reloc[i].presumed_offset = ~0ull;
+ reloc[i].offset = 8 * i;
+ reloc[i].delta = i;
+ reloc[i].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
+ reloc[i].write_domain = 0;
+ }
+ mprotect(reloc, sz, PROT_READ);
+
+ *out = sz;
+ return reloc;
+}
+
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, &bbe, sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
+static int __execbuf(int i915, struct drm_i915_gem_execbuffer2 *execbuf)
+{
+ int err;
+
+ err = 0;
+ if (ioctl(i915, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static void parallel_child(int i915,
+ const struct intel_execution_engine2 *engine,
+ struct drm_i915_gem_relocation_entry *reloc,
+ uint32_t common)
+{
+ igt_spin_t *spin = __igt_spin_new(i915, .engine = engine->flags);
+ struct drm_i915_gem_exec_object2 reloc_target = {
+ .handle = gem_create(i915, 32 * 1024 * 8),
+ .relocation_count = 32 * 1024,
+ .relocs_ptr = to_user_pointer(reloc),
+ };
+ struct drm_i915_gem_exec_object2 obj[3] = {
+ reloc_target,
+ { .handle = common },
+ spin->obj[1],
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = ARRAY_SIZE(obj),
+ .flags = engine->flags | I915_EXEC_HANDLE_LUT,
+ };
+ unsigned long count = 0;
+
+ gem_execbuf(i915, &execbuf);
+ for (;;) {
+ count++;
+ if (__execbuf(i915, &execbuf))
+ break;
+ }
+
+ igt_info("%s: count %lu\n", engine->name, count);
+ igt_spin_free(i915, spin);
+}
+
+static void parallel(int i915)
+{
+ const struct intel_execution_engine2 *e;
+ struct drm_i915_gem_relocation_entry *reloc;
+ uint32_t common = gem_create(i915, 4096);
+ uint32_t batch = batch_create(i915);
+ unsigned long reloc_sz;
+ uint32_t ctx;
+
+ reloc = parallel_relocs(32 * 1024, &reloc_sz);
+
+ __for_each_physical_engine(i915, e) {
+ igt_fork(child, 1)
+ parallel_child(i915, e, reloc, common);
+ }
+
+ sleep(5);
+
+ ctx = gem_context_create(i915);
+ __for_each_physical_engine(i915, e) {
+ struct drm_i915_gem_exec_object2 obj[2] = {
+ { .handle = common },
+ { .handle = batch },
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = ARRAY_SIZE(obj),
+ .flags = e->flags,
+ .rsvd1 = ctx,
+ };
+ gem_execbuf(i915, &execbuf);
+ }
+ gem_context_destroy(i915, ctx);
+ gem_sync(i915, batch);
+ gem_close(i915, batch);
+
+ kill(-getpgrp(), SIGINT);
+ igt_waitchildren();
+
+ gem_close(i915, common);
+ munmap(reloc, reloc_sz);
+}
+
igt_main
{
const struct intel_execution_engine2 *e;
@@ -826,6 +962,9 @@ igt_main
}
}
+ igt_subtest("basic-parallel")
+ parallel(fd);
+
igt_fixture
close(fd);
}
--
2.26.0
_
[Intel-gfx] [PATCH i-g-t 1/2] i915/gem_exec_reloc: Dynamic active engine tests
Use igt_subtest_with_dynamic for the flexible approach to engine
dependent test discovery.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 38 -
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 1aa03fba3..275cf6ae9 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -261,13 +261,13 @@ static void active(int fd, unsigned engine)
nengine = 0;
if (engine == ALL_ENGINES) {
- for_each_physical_engine(e, fd) {
- if (gem_can_store_dword(fd, eb_ring(e)))
- engines[nengine++] = eb_ring(e);
+ const struct intel_execution_engine2 *e;
+
+ __for_each_physical_engine(fd, e) {
+ if (gem_class_can_store_dword(fd, e->class))
+ engines[nengine++] = e->flags;
}
} else {
- igt_require(gem_has_ring(fd, engine));
- igt_require(gem_can_store_dword(fd, engine));
engines[nengine++] = engine;
}
igt_require(nengine);
@@ -706,6 +706,7 @@ static void basic_softpin(int fd)
igt_main
{
+ const struct intel_execution_engine2 *e;
const struct mode {
const char *name;
unsigned before, after;
@@ -805,15 +806,26 @@ igt_main
igt_subtest("gpu")
from_gpu(fd);
- igt_subtest("basic-active")
- active(fd, ALL_ENGINES);
- for (const struct intel_execution_engine *e = intel_execution_engines;
-e->name; e++) {
- igt_subtest_f("basic-active-%s", e->name)
- active(fd, eb_ring(e));
- igt_subtest_f("basic-spin-%s", e->name)
- active_spin(fd, eb_ring(e));
+ igt_subtest_with_dynamic("basic-active") {
+ igt_dynamic("all")
+ active(fd, ALL_ENGINES);
+
+ __for_each_physical_engine(fd, e) {
+ if (!gem_class_can_store_dword(fd, e->class))
+ continue;
+
+ igt_dynamic_f("%s", e->name)
+ active(fd, e->flags);
+ }
+ }
+
+ igt_subtest_with_dynamic("basic-spin") {
+ __for_each_physical_engine(fd, e) {
+ igt_dynamic_f("%s", e->name)
+ active_spin(fd, e->flags);
+ }
}
+
igt_fixture
close(fd);
}
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next-fixes
On Tue, Mar 31, 2020 at 03:00:25PM +0800, Zhenyu Wang wrote: > > Hi, > > Here's more queued gvt fixes for 5.7. Please see details below. > > Thanks > -- > The following changes since commit a61ac1e75105a077ec1efd6923ae3c619f862304: > > drm/i915/gvt: Wean gvt off using dev_priv (2020-03-06 10:08:10 +0800) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2020-03-31 > > for you to fetch changes up to eb0ff8074e0baecba2cd0c7813f6cfa99bafc430: > > drm/i915/gvt: Fix klocwork issues about data size (2020-03-27 15:37:58 > +0800) pulled, thanks > > > gvt-next-fixes-2020-03-31 > > - Fix non-privilege access warning (Tina) > - Fix display port type (Tina) > - BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan) > - Bypass length check of LRI (Yan) > - Fix one klocwork warning (Tina) > > > Tina Zhang (3): > drm/i915/gvt: Add some regs to force-to-nonpriv whitelist > drm/i915/gvt: Fix display port type issue > drm/i915/gvt: Fix klocwork issues about data size > > Yan Zhao (2): > drm/i915/gvt: add support to command SWTESS_BASE_ADDRESS > drm/i915/gvt: do not check len & max_len for lri > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 16 > drivers/gpu/drm/i915/gvt/display.c| 6 +++--- > drivers/gpu/drm/i915/gvt/handlers.c | 8 ++-- > drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++-- > 4 files changed, 15 insertions(+), 19 deletions(-) > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Kernel 5.2 to current: possible i915 related problems
On Mon, 30 Mar 2020, Dirk Gouders wrote: > Dirk Gouders writes: > >> Some additional information: >> >> I tried to get more information by using netconsole with kernel >> 5.6.0-rc7+. After some time, the system stopped to respond and I >> checked the messages sent to the remote machine. Unfortunately they >> gave no other information than the local logfile. >> >> Dirk >> >> Dirk Gouders writes: >> >>> Hello, >>> >>> because of the current pandemic situation the usage of my laptop has >>> changed. It is now running at home 24/7 with a monitor attached to it >>> and after about 12 days running a somewhat older kernel (5.2), it >>> stopped working. >>> >>> After a reboot I found some information in the syslog that I attach to >>> this mail. The next hang happened one day later but without any >>> information. >>> >>> With a current 5.6.0-rc7+ I seem to get more frequent hangs but without any >>> information in the log file and somewhat non-reproducable. Today, I >>> experienced two hangs when starting xterms or other programs but after >>> this (and necessary reboots) I am unable to reproduce a hang. >>> >>> Perhaps, someone has suggestion for me how to produce debugging >>> information that survives the hangs and reboots. >>> > > This time, I have some information from a hang with the current kernel > 5.6.0-rc7+ that obviously could be written to the logfile while the > system was starting to get problems. A minute later or so, it > completely stopped to respond and a hard reset was necessary: > > Mar 30 10:37:52 lena kernel: i915 :00:02.0: GPU HANG: ecode 8:1:85d9, > in X [4278] > Mar 30 10:37:52 lena kernel: GPU hangs can indicate a bug anywhere in the > entire gfx stack, including userspace. > Mar 30 10:37:52 lena kernel: Please file a _new_ bug report at > https://gitlab.freedesktop.org/drm/intel/issues/new. > Mar 30 10:37:52 lena kernel: Please see > https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for > details. > Mar 30 10:37:52 lena kernel: drm/i915 developers can then reassign to the > right component if it's not a kernel issue. > Mar 30 10:37:52 lena kernel: The GPU crash dump is required to analyze GPU > hangs, so please always attach it. > Mar 30 10:37:52 lena kernel: GPU crash dump saved to > /sys/class/drm/card0/error > Mar 30 10:37:52 lena kernel: i915 :00:02.0: Resetting rcs0 for stopped > heartbeat on rcs0 > Mar 30 10:37:52 lena kernel: i915 :00:02.0: X[4278] context reset due to > GPU hang > > Adding the i915 maintainers because I doubt the data in > /sys/class/drm/card0/error is useful after a reboot. Should I file a > bug report as suggested above, anyway? Please do. BR, Jani. > > Dirk > >>> >>> >>> Mar 27 19:36:51 lena kernel: [drm:intel_cpu_fifo_underrun_irq_handler >>> [i915]] *ERROR* CPU pipe B FIFO underrun >>> Mar 27 21:45:19 lena kernel: usb 1-1: USB disconnect, device number 15 >>> Mar 27 21:45:19 lena kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache >>> Mar 27 21:45:19 lena kernel: sd 2:0:0:0: [sdb] Synchronize Cache(10) >>> failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK >>> Mar 27 22:00:53 lena kernel: [drm:intel_cpu_fifo_underrun_irq_handler >>> [i915]] *ERROR* CPU pipe B FIFO underrun >>> Mar 27 23:46:13 lena kernel: [ cut here ] >>> Mar 27 23:46:13 lena kernel: vblank wait timed out on crtc 1 >>> Mar 27 23:46:13 lena kernel: WARNING: CPU: 0 PID: 4221 at >>> drm_wait_one_vblank+0xfa/0x12a [drm] >>> Mar 27 23:46:13 lena kernel: Modules linked in: usblp uas usb_storage >>> uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 >>> videobuf2_common snd_hda_codec >>> _hdmi snd_hda_codec_realtek snd_hda_codec_generic crc32_pclmul >>> crc32c_intel ghash_clmulni_intel i915 aesni_intel drm_kms_helper >>> cfbfillrect crypto_simd glue_he >>> lper syscopyarea cfbimgblt sysfillrect sysimgblt snd_hda_intel >>> fb_sys_fops cfbcopyarea snd_hda_codec sdhci_acpi drm xhci_pci >>> snd_hwdep sdhci drm_panel_orientat >>> ion_quirks snd_hda_core intel_gtt mmc_core xhci_hcd iosf_mbi >>> Mar 27 23:46:13 lena kernel: CPU: 0 PID: 4221 Comm: X Not tainted 5.2.0+ #44 >>> Mar 27 23:46:13 lena kernel: Hardware name: Acer Aspire ES1-131/Garp_BA, >>> BIOS V1.23 06/22/2016 >>> Mar 27 23:46:13 lena kernel: RIP: 0010:drm_wait_one_vblank+0xfa/0x12a [drm] >>> Mar 27 23:46:13 lena kernel: Code: 89 e7 e8 31 eb 74 e1 49 89 c4 eb bf >>> 48 89 e6 4c 89 f7 e8 d5 b5 ff e0 45 85 e4 75 10 89 de 48 c7 c7 cf de >>> 0d a0 e8 2e bd fc e >>> 0 <0f> 0b 89 de 48 89 ef e8 82 fe ff ff 48 8b 44 24 28 65 48 33 04 25 >>> Mar 27 23:46:13 lena kernel: RSP: 0018:c9e73ac0 EFLAGS: 00010296 >>> Mar 27 23:46:13 lena kernel: RAX: RBX: 0001 >>> RCX: 0007 >>> Mar 27 23:46:13 lena kernel: RDX: RSI: 0002 >>> RDI: 888277a163a0 >>> Mar 27 23:46:13 lena kernel: RBP: 888271b4 R08:
Re: [Intel-gfx] [PATCH v3] drm/i915/gt: move remaining debugfs interfaces into gt
Quoting Andi Shyti (2020-03-31 17:45:08)
> +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> + int slice, u8 *to_mask)
> +{
> + int offset = slice * sseu->ss_stride;
> +
> + memcpy(&to_mask[offset], &sseu->subslice_mask[offset],
> sseu->ss_stride);
> +}
Worth moving all the sseu into their file? There's quite a few of them
and each quite chunky.
> +static int interrupt_info_show(struct seq_file *m, void *data)
And if we start there, we might end up with debugfs_gt_irq.c as well?
(Not that I see any use for this debugfs info :)
> +static int reset_get(void *data, u64 *val)
> +{
> + struct intel_gt *gt = data;
> + int ret = intel_gt_terminally_wedged(gt);
> +
> + switch (ret) {
> + case -EIO:
> + *val = 1;
> + return 0;
> + case 0:
> + *val = 0;
> + return 0;
> + default:
> + return ret;
> + }
reset_get? Ok if you document it as reporting wedged status :)
> +}
> +
> +static int reset_set(void *data, u64 val)
> +{
> + struct intel_gt *gt = data;
> +
> + /* Flush any previous reset before applying for a new one */
> + wait_event(gt->reset.queue,
> + !test_bit(I915_RESET_BACKOFF, >->reset.flags));
> +
> + intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
> + "Manually set wedged engine mask = %llx", val);
No hint of i915_wedged any more. Just "Manual reset engine mask %llx",
or somesuch will do.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] i915/gem_exec_reloc: Smoke test parallel relocations
Check we can handle active gpu relocations across multiple engines
simultaneously without blocking unrelated contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 159
1 file changed, 159 insertions(+)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 275cf6ae9..02bda0f29 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -21,6 +21,9 @@
* IN THE SOFTWARE.
*/
+#include
+#include
+
#include "igt.h"
#include "igt_dummyload.h"
@@ -704,6 +707,159 @@ static void basic_softpin(int fd)
gem_close(fd, obj[1].handle);
}
+static struct drm_i915_gem_relocation_entry *
+parallel_relocs(int count, unsigned long *out)
+{
+ struct drm_i915_gem_relocation_entry *reloc;
+ unsigned long sz;
+ int i;
+
+ sz = count * sizeof(*reloc);
+ sz = ALIGN(sz, 4096);
+
+ reloc = mmap(0, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
+ igt_assert(reloc != MAP_FAILED);
+ for (i = 0; i < count; i++) {
+ reloc[i].target_handle = 0;
+ reloc[i].presumed_offset = ~0ull;
+ reloc[i].offset = 8 * i;
+ reloc[i].delta = i;
+ reloc[i].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
+ reloc[i].write_domain = 0;
+ }
+ mprotect(reloc, sz, PROT_READ);
+
+ *out = sz;
+ return reloc;
+}
+
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, &bbe, sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
+static int __execbuf(int i915, struct drm_i915_gem_execbuffer2 *execbuf)
+{
+ int err;
+
+ err = 0;
+ if (ioctl(i915, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static void sighandler(int sig)
+{
+}
+
+static void parallel_child(int i915,
+ const struct intel_execution_engine2 *engine,
+ struct drm_i915_gem_relocation_entry *reloc,
+ uint32_t common)
+{
+ igt_spin_t *spin = __igt_spin_new(i915, .engine = engine->flags);
+ struct drm_i915_gem_exec_object2 reloc_target = {
+ .handle = gem_create(i915, 32 * 1024 * 8),
+ .relocation_count = 32 * 1024,
+ .relocs_ptr = to_user_pointer(reloc),
+ };
+ struct drm_i915_gem_exec_object2 obj[3] = {
+ reloc_target,
+ { .handle = common },
+ spin->obj[1],
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = ARRAY_SIZE(obj),
+ .flags = engine->flags | I915_EXEC_HANDLE_LUT,
+ };
+ struct sigaction act = {
+ .sa_handler = sighandler,
+ };
+ unsigned long count = 0;
+
+ sigaction(SIGINT, &act, NULL);
+ for (;;) {
+ int err = __execbuf(i915, &execbuf);
+ if (err == -EINTR)
+ break;
+
+ igt_assert_eq(err, 0);
+ count++;
+ }
+
+ igt_info("%s: count %lu\n", engine->name, count);
+ igt_spin_free(i915, spin);
+}
+
+static void kill_children(int sig)
+{
+ signal(sig, SIG_IGN);
+ kill(-getpgrp(), SIGINT);
+ signal(sig, SIG_DFL);
+}
+
+static void parallel(int i915)
+{
+ const struct intel_execution_engine2 *e;
+ struct drm_i915_gem_relocation_entry *reloc;
+ uint32_t common = gem_create(i915, 4096);
+ uint32_t batch = batch_create(i915);
+ unsigned long reloc_sz;
+ uint32_t ctx;
+
+ reloc = parallel_relocs(32 * 1024, &reloc_sz);
+
+ __for_each_physical_engine(i915, e) {
+ igt_fork(child, 1)
+ parallel_child(i915, e, reloc, common);
+ }
+ sleep(2);
+
+ if (gem_scheduler_enabled(i915)) {
+ uint32_t ctx = gem_context_clone_with_engines(i915, 0);
+
+ __for_each_physical_engine(i915, e) {
+ struct drm_i915_gem_exec_object2 obj[2] = {
+ { .handle = common },
+ { .handle = batch },
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = ARRAY_SIZE(obj),
+ .flags = e->flags,
+ .rsvd1 = ctx,
+ };
+ gem_execbuf(i915, &execbuf);
+ }
+
+
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode
On Tue, Mar 31, 2020 at 09:47:39AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT mode > URL : https://patchwork.freedesktop.org/series/75253/ > State : success Thanks for the review, pushed to -dinq. > > == Summary == > > CI Bug Log - changes from CI_DRM_8219_full -> Patchwork_17137_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_17137_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_busy@busy-vcs1: > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +7 similar > issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb4/igt@gem_b...@busy-vcs1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb5/igt@gem_b...@busy-vcs1.html > > * igt@gem_exec_schedule@implicit-both-bsd: > - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd.html > > * igt@gem_exec_schedule@implicit-both-bsd1: > - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) > +3 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html > > * igt@gem_exec_schedule@preempt-queue-bsd1: > - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar > issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html > > * igt@gem_exec_schedule@reorder-wide-bsd: > - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +2 similar > issues >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html > > * igt@gem_workarounds@suspend-resume-context: > - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1 > similar issue >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-apl2/igt@gem_workarou...@suspend-resume-context.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-apl1/igt@gem_workarou...@suspend-resume-context.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-skl: [PASS][13] -> [FAIL][14] ([i915#46]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl10/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > - shard-glk: [PASS][15] -> [FAIL][16] ([i915#46]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-glk3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: > - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#648] / > [i915#69]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html > > * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: > - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html > > * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: > - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8219/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17137/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html > > * igt@kms_psr@psr2_sprite_render: > - shard-iclb
Re: [Intel-gfx] [PATCH v3] drm/i915/gt: move remaining debugfs interfaces into gt
Quoting Andi Shyti (2020-03-31 18:13:09)
> Hi Chris,
>
> On Tue, Mar 31, 2020 at 05:53:32PM +0100, Chris Wilson wrote:
> > Quoting Andi Shyti (2020-03-31 17:45:08)
> > > +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> > > + int slice, u8 *to_mask)
> > > +{
> > > + int offset = slice * sseu->ss_stride;
> > > +
> > > + memcpy(&to_mask[offset], &sseu->subslice_mask[offset],
> > > sseu->ss_stride);
> > > +}
> >
> > Worth moving all the sseu into their file? There's quite a few of them
> > and each quite chunky.
> >
> > > +static int interrupt_info_show(struct seq_file *m, void *data)
> >
> > And if we start there, we might end up with debugfs_gt_irq.c as well?
> > (Not that I see any use for this debugfs info :)
>
> add a debufs_gt_sseu.c and debugfs_gt_irq.c, isn't it a bit
> excessive? I also do agree that everything in one file looks a
> bit stuffed.
I think debugfs_gt_sseu.c is reasonably justified. (There's also an rcs
topology apparently!) That's a good chunk of 250+ lines of code that no
one wants to ever to have to read.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath"
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75303/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eeef100fe92e Revert "drm/i915/gem: Drop relocation slowpath"
-:78: WARNING:LINE_SPACING: Missing a blank line after declarations
#78: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1602:
+ int err = __get_user(c, addr);
+ if (err)
total: 0 errors, 1 warnings, 0 checks, 257 lines checked
9a40fc4e0126 perf/core: Only copy-to-user after completely unlocking all locks.
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
<4> [604.892540] 8264a558 (rcu_state.barrier_mutex){+.+.}, at:
rcu_barrier+0x23/0x190
-:197: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#197: FILE: kernel/events/core.c:5008:
+__perf_read(struct perf_event *event, char __user *buf,
+ size_t count, u64 **values)
total: 0 errors, 1 warnings, 1 checks, 129 lines checked
bf82242e9adb drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:506: WARNING:LONG_LINE: line over 100 characters
#506: FILE: drivers/gpu/drm/i915/i915_gem.c:1338:
+ while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 481 lines checked
d25a2e312d46 drm/i915: Remove locking from i915_gem_object_prepare_read/write
916faf76594a drm/i915: Parse command buffer earlier in eb_relocate(slow)
4541b2c7c495 Revert "drm/i915/gem: Split eb_vma into its own allocation"
56ce33f78717 drm/i915: Use per object locking in execbuf, v7.
3df3f15a61a1 drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 202 lines checked
c1e7cee727f1 drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1100:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
5146c267604d drm/i915: Nuke arguments to eb_pin_engine
854e2ee83997 drm/i915: Pin engine before pinning all objects, v3.
d48be0119197 drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+
-:340: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#340: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3099:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 445 lines checked
147622f95cc6 drm/i915: Make sure execbuffer always passes ww state to
i915_vma_pin.
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:573:
+ err = i915_vma_pin_ww(vma, &eb->ww,
entry->pad_to_size, entry->alignment,
-:188: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#188: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2195:
+* hsw should have this fixed, but bdw mucks it up again. */
total: 0 errors, 1 warnings, 1 checks, 812 lines checked
b2ff840394a8 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking
as well, v2.
c986782b8ae9 drm/i915: Kill last user of intel_context_create_request outside
of selftests
e20a2878f608 drm/i915: Convert i915_perf to ww locking as well
e18d1f7e2329 drm/i915: Dirty hack to fix selftests locking inversion
46a71cab08bb drm/i915/selftests: Fix locking inversion in lrc selftest.
2b05d002a697 drm/i915: Use ww pinning for intel_context_create_request()
9b4f1c5ce49e drm/i915: Move i915_vma_lock in the selftests to avoid lock
inversion, v2.
837267b4880f drm/i915: Add ww locking to vm_fault_gtt
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 91 lines checked
46887931504c drm/i915: Add ww locking to pin_to_display_plane
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 129 lines checked
783376875259 drm/i915: Ensure we hold the pin mutex
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 37 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/gt: move remaining debugfs interfaces into gt
Hi Chris,
On Tue, Mar 31, 2020 at 05:53:32PM +0100, Chris Wilson wrote:
> Quoting Andi Shyti (2020-03-31 17:45:08)
> > +static void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> > + int slice, u8 *to_mask)
> > +{
> > + int offset = slice * sseu->ss_stride;
> > +
> > + memcpy(&to_mask[offset], &sseu->subslice_mask[offset],
> > sseu->ss_stride);
> > +}
>
> Worth moving all the sseu into their file? There's quite a few of them
> and each quite chunky.
>
> > +static int interrupt_info_show(struct seq_file *m, void *data)
>
> And if we start there, we might end up with debugfs_gt_irq.c as well?
> (Not that I see any use for this debugfs info :)
add a debufs_gt_sseu.c and debugfs_gt_irq.c, isn't it a bit
excessive? I also do agree that everything in one file looks a
bit stuffed.
> > +static int reset_get(void *data, u64 *val)
> > +{
> > + struct intel_gt *gt = data;
> > + int ret = intel_gt_terminally_wedged(gt);
> > +
> > + switch (ret) {
> > + case -EIO:
> > + *val = 1;
> > + return 0;
> > + case 0:
> > + *val = 0;
> > + return 0;
> > + default:
> > + return ret;
> > + }
>
> reset_get? Ok if you document it as reporting wedged status :)
>
> > +}
> > +
> > +static int reset_set(void *data, u64 val)
> > +{
> > + struct intel_gt *gt = data;
> > +
> > + /* Flush any previous reset before applying for a new one */
> > + wait_event(gt->reset.queue,
> > + !test_bit(I915_RESET_BACKOFF, >->reset.flags));
> > +
> > + intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
> > + "Manually set wedged engine mask = %llx",
> > val);
>
> No hint of i915_wedged any more. Just "Manual reset engine mask %llx",
> or somesuch will do.
OK, I will try to improve the transition freom "wedged" to
"reset". Thanks.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> Add 2 new properties to the i915-perf open ioctl to specify an array
> of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than one logical context instance that OA could track. The extension to
track multiple pinned contexts should equally work for multiple engines.
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
struct drm_i915_gem_context_param p = {
.ctx_id = gem_context_create(i915),
.param = I915_CONTEXT_PARAM_ENGINES,
.value = to_user_pointer(&engines),
.size = sizeof(struct i915_context_param_engines),
};
gem_context_set_param(i915, &p);
would do the trick in creating one context with 64 rcs0 that they may
want to track. And that also opens the door to virtual engines over top.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath"
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75303/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228 -> Patchwork_17153
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17153 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17153, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17153:
### IGT changes ###
Possible regressions
* igt@gem_close_race@basic-process:
- fi-ivb-3770:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-ivb-3770/igt@gem_close_r...@basic-process.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-ivb-3770/igt@gem_close_r...@basic-process.html
- fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-hsw-4770/igt@gem_close_r...@basic-process.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-hsw-4770/igt@gem_close_r...@basic-process.html
* igt@gem_exec_fence@basic-await@rcs0:
- fi-blb-e6850: [PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html
- fi-elk-e7500: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html
- fi-pnv-d510:[PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-pnv-d510/igt@gem_exec_fence@basic-aw...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-pnv-d510/igt@gem_exec_fence@basic-aw...@rcs0.html
- fi-ilk-650: [PASS][11] -> [DMESG-WARN][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-ilk-650/igt@gem_exec_fence@basic-aw...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-ilk-650/igt@gem_exec_fence@basic-aw...@rcs0.html
* igt@gem_exec_fence@basic-await@vcs0:
- fi-ilk-650: [PASS][13] -> [INCOMPLETE][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-ilk-650/igt@gem_exec_fence@basic-aw...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-ilk-650/igt@gem_exec_fence@basic-aw...@vcs0.html
* igt@gem_render_tiled_blits@basic:
- fi-gdg-551: [PASS][15] -> [DMESG-WARN][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-gdg-551/igt@gem_render_tiled_bl...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-gdg-551/igt@gem_render_tiled_bl...@basic.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
- fi-skl-lmem:[PASS][19] -> [DMESG-WARN][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {fi-kbl-7560u}: [PASS][21] -> [DMESG-WARN][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-kbl-7560u/igt@i915_selftest@live@gem_contexts.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-kbl-7560u/igt@i915_selftest@live@gem_contexts.html
Known issues
Here are the changes found in Patchwork_17153 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-process:
- fi-byt-j1900: [PASS][23] -> [INCOMPLETE][24] ([i915#45])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/fi-byt-j1900/igt@gem_close_r...@basic-process.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/fi-byt-j1900/igt@gem_close_r...@basic-process.html
-
