Re: [Intel-gfx] [PATCH 05/27] drm/i915/guc: Process all G2H message at once in work queue
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Cc: Daniel Vetter
Cc: Michal Wajdeczko
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 22b4733b55e2..20c710a74498 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1042,9 +1042,9 @@ static void ct_incoming_request_worker_func(struct
work_struct *w)
container_of(w, struct intel_guc_ct, requests.worker);
bool done;
- done = ct_process_incoming_requests(ct);
- if (!done)
- queue_work(system_unbound_wq, >requests.worker);
+ do {
+ done = ct_process_incoming_requests(ct);
+ } while (!done);
}
static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
Re: [Intel-gfx] [PATCH 04/27] drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
On Thu, Aug 19, 2021 at 05:01:03PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > Don't drop ce->guc_active.lock when unwinding a context after reset.
> > At one point we had to drop this because of a lock inversion but that is
> > no longer the case. It is much safer to hold the lock so let's do that.
> >
> > Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC
> > interface")
> > Signed-off-by: Matthew Brost
> > Cc:
>
> Reviewed-by: Daniele Ceraolo Spurio
>
> Do we have a trybot of this series with GuC enabled? I've checked the
> functions called in the previously unlocked chunk and didn't spot anything
> requiring the lock to be dropped, but I'd feel safer if we had lockdep
> results as well.
>
RKL uses GuC submission with BAT. This has been thoroughly tested by me
too and no lockdep splats. Can kick off a trybot on the next rev of this
series too.
Matt
> Daniele
>
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 9ca0ba4ea85a..e4a099f8f820 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -812,8 +812,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
> > continue;
> > list_del_init(>sched.link);
> > - spin_unlock(>guc_active.lock);
> > -
> > __i915_request_unsubmit(rq);
> > /* Push the request back into the queue for later resubmission.
> > */
> > @@ -826,8 +824,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
> > list_add(>sched.link, pl);
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > -
> > - spin_lock(>guc_active.lock);
> > }
> > spin_unlock(>guc_active.lock);
> > spin_unlock_irqrestore(_engine->lock, flags);
>
Re: [Intel-gfx] [PATCH 03/27] drm/i915/guc: Unwind context requests in reverse order
On 8/19/2021 4:53 PM, Matthew Brost wrote:
On Thu, Aug 19, 2021 at 04:54:00PM -0700, Daniele Ceraolo Spurio wrote:
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 32c414aa9009..9ca0ba4ea85a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -805,9 +805,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
spin_lock_irqsave(_engine->lock, flags);
spin_lock(>guc_active.lock);
- list_for_each_entry_safe(rq, rn,
->guc_active.requests,
-sched.link) {
+ list_for_each_entry_safe_reverse(rq, rn,
+>guc_active.requests,
+sched.link) {
if (i915_request_completed(rq))
The execlists unwind function has a list_del if the request is completed.
Any reason not to do that here?
Def isn't needed here as this is done in remove_from_context(), probably
not needed in execlists mode either.
continue;
@@ -824,7 +824,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
}
GEM_BUG_ON(i915_sched_engine_is_empty(sched_engine));
- list_add_tail(>sched.link, pl);
+ list_add(>sched.link, pl);
Since you always do both list_del and list_add and it doesn't look like you
use the fact that the list is empty between the 2 calls, you can merge them
in a list_move.
Can't use a list move here because we drop
spin_lock(>guc_active.lock), that gets fixed later in the series and
at that point we likely can use a list_move.
fair enough. I'll leave it to you to decide if it is worth moving this
patch after the next one and using a list_move. With or without that,
this is:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
Matt
Apart from these nits, the change to navigate the list in reverse and append
here at the top LGTM.
Daniele
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
spin_lock(>guc_active.lock);
Re: [Intel-gfx] [PATCH 04/27] drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Cc:
Reviewed-by: Daniele Ceraolo Spurio
Do we have a trybot of this series with GuC enabled? I've checked the
functions called in the previously unlocked chunk and didn't spot
anything requiring the lock to be dropped, but I'd feel safer if we had
lockdep results as well.
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9ca0ba4ea85a..e4a099f8f820 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -812,8 +812,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
continue;
list_del_init(>sched.link);
- spin_unlock(>guc_active.lock);
-
__i915_request_unsubmit(rq);
/* Push the request back into the queue for later resubmission. */
@@ -826,8 +824,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
-
- spin_lock(>guc_active.lock);
}
spin_unlock(>guc_active.lock);
spin_unlock_irqrestore(_engine->lock, flags);
Re: [Intel-gfx] [PATCH 03/27] drm/i915/guc: Unwind context requests in reverse order
On Thu, Aug 19, 2021 at 04:54:00PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > When unwinding requests on a reset context, if other requests in the
> > context are in the priority list the requests could be resubmitted out
> > of seqno order. Traverse the list of active requests in reverse and
> > append to the head of the priority list to fix this.
> >
> > Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC
> > interface")
> > Signed-off-by: Matthew Brost
> > Cc:
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 32c414aa9009..9ca0ba4ea85a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -805,9 +805,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
> > spin_lock_irqsave(_engine->lock, flags);
> > spin_lock(>guc_active.lock);
> > - list_for_each_entry_safe(rq, rn,
> > ->guc_active.requests,
> > -sched.link) {
> > + list_for_each_entry_safe_reverse(rq, rn,
> > +>guc_active.requests,
> > +sched.link) {
> > if (i915_request_completed(rq))
>
> The execlists unwind function has a list_del if the request is completed.
> Any reason not to do that here?
>
Def isn't needed here as this is done in remove_from_context(), probably
not needed in execlists mode either.
> > continue;
> > @@ -824,7 +824,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
> > }
> > GEM_BUG_ON(i915_sched_engine_is_empty(sched_engine));
> > - list_add_tail(>sched.link, pl);
> > + list_add(>sched.link, pl);
>
> Since you always do both list_del and list_add and it doesn't look like you
> use the fact that the list is empty between the 2 calls, you can merge them
> in a list_move.
>
Can't use a list move here because we drop
spin_lock(>guc_active.lock), that gets fixed later in the series and
at that point we likely can use a list_move.
Matt
> Apart from these nits, the change to navigate the list in reverse and append
> here at the top LGTM.
>
> Daniele
>
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > spin_lock(>guc_active.lock);
>
Re: [Intel-gfx] [PATCH 03/27] drm/i915/guc: Unwind context requests in reverse order
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 32c414aa9009..9ca0ba4ea85a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -805,9 +805,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
spin_lock_irqsave(_engine->lock, flags);
spin_lock(>guc_active.lock);
- list_for_each_entry_safe(rq, rn,
->guc_active.requests,
-sched.link) {
+ list_for_each_entry_safe_reverse(rq, rn,
+>guc_active.requests,
+sched.link) {
if (i915_request_completed(rq))
The execlists unwind function has a list_del if the request is
completed. Any reason not to do that here?
continue;
@@ -824,7 +824,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
}
GEM_BUG_ON(i915_sched_engine_is_empty(sched_engine));
- list_add_tail(>sched.link, pl);
+ list_add(>sched.link, pl);
Since you always do both list_del and list_add and it doesn't look like
you use the fact that the list is empty between the 2 calls, you can
merge them in a list_move.
Apart from these nits, the change to navigate the list in reverse and
append here at the top LGTM.
Daniele
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
spin_lock(>guc_active.lock);
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/1] i915/gem_scheduler: Ensure submission order in manycontexts
On 7/29/2021 17:00, Matthew Brost wrote:
On Thu, Jul 29, 2021 at 04:54:08PM -0700, John Harrison wrote:
On 7/27/2021 11:20, Matthew Brost wrote:
With GuC submission contexts can get reordered (compared to submission
order), if contexts get reordered the sequential nature of the batches
releasing the next batch's semaphore in function timesliceN() get broken
resulting in the test taking much longer than if should. e.g. Every
contexts needs to be timesliced to release the next batch. Corking the
first submission until all the batches have been submitted should ensure
submission order.
Signed-off-by: Matthew Brost
---
tests/i915/gem_exec_schedule.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index f03842478..41f2591a5 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -597,12 +597,13 @@ static void timesliceN(int i915, const intel_ctx_cfg_t
*cfg,
struct drm_i915_gem_execbuffer2 execbuf = {
.buffers_ptr = to_user_pointer(),
.buffer_count = 1,
- .flags = engine | I915_EXEC_FENCE_OUT,
+ .flags = engine | I915_EXEC_FENCE_OUT | I915_EXEC_FENCE_SUBMIT,
};
uint32_t *result =
gem_mmap__device_coherent(i915, obj.handle, 0, sz, PROT_READ);
const intel_ctx_t *ctx;
int fence[count];
+ IGT_CORK_FENCE(cork);
/*
* Create a pair of interlocking batches, that ping pong
@@ -614,6 +615,17 @@ static void timesliceN(int i915, const intel_ctx_cfg_t
*cfg,
igt_require(gem_scheduler_has_timeslicing(i915));
igt_require(intel_gen(intel_get_drm_devid(i915)) >= 8);
+ /*
+* With GuC submission contexts can get reordered (compared to
+* submission order), if contexts get reordered the sequential
+* nature of the batches releasing the next batch's semaphore gets
+* broken resulting in the test taking much longer than it should (e.g.
+* every context needs to be timesliced to release the next batch).
+* Corking the first submission until all batches have been
+* submitted should ensure submission order.
+*/
+ execbuf.rsvd2 = igt_cork_plug(, i915);
+
/* No coupling between requests; free to timeslice */
for (int i = 0; i < count; i++) {
@@ -624,8 +636,10 @@ static void timesliceN(int i915, const intel_ctx_cfg_t
*cfg,
intel_ctx_destroy(i915, ctx);
fence[i] = execbuf.rsvd2 >> 32;
+ execbuf.rsvd2 >>= 32;
This means you are passing fence_out[A] as fenc_in[B]? I.e. this patch is
also changing the behaviour to make each batch dependent upon the previous
This is a submission fence, it just ensures they get submitted in order.
Corking the first request + the fence, ensures all the requests get
submitted basically at the same time compared to execbuf IOCTL time
without it.
The input side is the submit fence, but the output side is the
completion fence. You are chaining the out fence of the previous request
as the submit fence of the next request.
Loop 0:
execbuf.rsvd2 = cork
submit()
execbuf.rsvd2 is now the out fence in the upper 32
fence[0] = execbuf.rsvd2 >> 32;
execbuf.rsvd2 >>= 32;
move new out fence to be the next in fence
Loop 1:
execbuf.rsvd2 == fence[0]
submit()
fence[1] = new out fence
Loop 2:
execbuf.rsvd2 == fence[1]
...
You have changed the parallel requests into a sequential line. Request X
is now waiting for Request Y to *complete* before it can be submitted.
Only the first request is waiting on the cork.
John.
one. That change is not mentioned in the new comment. It is also the exact
Yea, I could explain this better. Will fix.
Matt
opposite of the comment immediately above the loop - 'No coupling between
requests'.
John.
}
+ igt_cork_unplug();
gem_sync(i915, obj.handle);
gem_close(i915, obj.handle);
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg1: remove __maybe_unused leftover
== Series Details == Series: drm/i915/dg1: remove __maybe_unused leftover URL : https://patchwork.freedesktop.org/series/93842/ State : success == Summary == CI Bug Log - changes from CI_DRM_10499_full -> Patchwork_20857_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20857_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-apl6/igt@gem_ctx_isolation@preservation...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-apl1/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-snb6/igt@gem_ctx_persiste...@engines-hostile-preempt.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +431 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_media_vme: - shard-tglb: NOTRUN -> [SKIP][10] ([i915#284]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb1/igt@gem_media_vme.html * igt@gem_mmap_gtt@coherency: - shard-tglb: NOTRUN -> [SKIP][11] ([fdo#111656]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb5/igt@gem_mmap_...@coherency.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#307]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-iclb7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-iclb8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2428] / [i915#307]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-iclb4/igt@gem_mmap_...@cpuset-medium-copy-xy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-iclb3/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_userptr_blits@dmabuf-sync: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-skl8/igt@gem_userptr_bl...@dmabuf-sync.html - shard-tglb: NOTRUN -> [SKIP][17] ([i915#3323]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb5/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][18] ([i915#3002]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-skl2/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][19] ([i915#2724]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-snb7/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_render_tiledy_blits: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb5/igt@gen3_render_tiledy_blits.html * igt@kms_big_fb@y-tiled-64bpp-rotate-90: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111614]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb5/igt@kms_big...@y-tiled-64bpp-rotate-90.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-180: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111615]) +2 similar issues [22]:
Re: [Intel-gfx] [PATCH 1/1] drm/i915/selftests: Increase timeout in i915_gem_contexts selftests
On 7/26/2021 20:17, Matthew Brost wrote:
Like in the case of several other selftests, generating lots of requests
in a loop takes a bit longer with GuC submission. Increase a timeout in
i915_gem_contexts selftest to take this into account.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 8eb5050f8cb3..4d2758718d21 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -94,7 +94,7 @@ static int live_nop_switch(void *arg)
rq = i915_request_get(this);
i915_request_add(this);
}
- if (i915_request_wait(rq, 0, HZ / 5) < 0) {
+ if (i915_request_wait(rq, 0, HZ) < 0) {
pr_err("Failed to populated %d contexts\n", nctx);
intel_gt_set_wedged(>gt);
i915_request_put(rq);
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev7)
== Series Details == Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev7) URL : https://patchwork.freedesktop.org/series/93570/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10499_full -> Patchwork_20856_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20856_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20856_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_20856_full: ### IGT changes ### Possible regressions * igt@kms_plane_cursor@pipe-a-overlay-size-128: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-skl4/igt@kms_plane_cur...@pipe-a-overlay-size-128.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-skl3/igt@kms_plane_cur...@pipe-a-overlay-size-128.html * igt@sysfs_heartbeat_interval@mixed@rcs0: - shard-skl: [PASS][3] -> [WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-skl7/igt@sysfs_heartbeat_interval@mi...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-skl5/igt@sysfs_heartbeat_interval@mi...@rcs0.html Known issues Here are the changes found in Patchwork_20856_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][5] ([i915#3002]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-kbl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +5 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +4 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-snb5/igt@gem_ctx_persiste...@process.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#3063] / [i915#3648]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-tglb5/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-tglb5/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][11] ([i915#3354]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-kbl3/igt@gem_exec_f...@basic-deadline.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-kbl6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_media_vme: - shard-tglb: NOTRUN -> [SKIP][21] ([i915#284]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-tglb8/igt@gem_media_vme.html * igt@gem_mmap_gtt@coherency: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111656]) [22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg1: remove __maybe_unused leftover
== Series Details ==
Series: drm/i915/dg1: remove __maybe_unused leftover
URL : https://patchwork.freedesktop.org/series/93842/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10499 -> Patchwork_20857
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/index.html
Known issues
Here are the changes found in Patchwork_20857 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-1115g4: [PASS][1] -> [DMESG-WARN][2] ([i915#4002]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-tgl-1115g4/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-tgl-1115g4/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#3958])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-tgl-1115g4: [DMESG-WARN][5] ([i915#4002]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-tgl-1115g4/igt@core_hotunp...@unbind-rebind.html
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-rkl-11600: [SKIP][9] -> [PASS][10] +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-rkl-11600/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-rkl-11600/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
* igt@kms_prop_blob@basic:
- fi-tgl-1115g4: [DMESG-WARN][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-tgl-1115g4/igt@kms_prop_b...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-tgl-1115g4/igt@kms_prop_b...@basic.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4: [FAIL][13] ([i915#1888]) -> [DMESG-WARN][14]
([i915#4002])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-1115g4: [SKIP][15] ([fdo#111827] / [i915#1385]) -> [SKIP][16]
([fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-tgl-1115g4/igt@kms_chamel...@dp-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-tgl-1115g4/igt@kms_chamel...@dp-hpd-fast.html
* igt@kms_psr@primary_page_flip:
- fi-tgl-1115g4: [SKIP][17] ([i915#1072] / [i915#1385]) -> [SKIP][18]
([i915#1072])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-tgl-1115g4/igt@kms_psr@primary_page_flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/fi-tgl-1115g4/igt@kms_psr@primary_page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1385]: https://gitlab.freedesktop.org/drm/intel/issues/1385
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
[i915#4002]: https://gitlab.freedesktop.org/drm/intel/issues/4002
[i915#750]: https://gitlab.freedesktop.org/drm/intel/issues/750
Participating hosts (42 -> 34)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-cfl-guc
fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10499 -> Patchwork_20857
CI-20190529: 20190529
Re: [Intel-gfx] [PATCH 02/27] drm/i915/guc: Fix outstanding G2H accounting
On Thu, Aug 19, 2021 at 02:31:51PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > A small race that could result in incorrect accounting of the number
> > of outstanding G2H. Basically prior to this patch we did not increment
> > the number of outstanding G2H if we encoutered a GT reset while sending
> > a H2G. This was incorrect as the context state had already been updated
> > to anticipate a G2H response thus the counter should be incremented.
> >
> > Also always use helper when decrementing this value.
> >
> > Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in
> > buffer")
> > Signed-off-by: Matthew Brost
> > Cc:
> > ---
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ++-
> > 1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 69faa39da178..32c414aa9009 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -352,6 +352,12 @@ static inline void set_lrc_desc_registered(struct
> > intel_guc *guc, u32 id,
> > xa_unlock_irqrestore(>context_lookup, flags);
> > }
> > +static void decr_outstanding_submission_g2h(struct intel_guc *guc)
> > +{
> > + if (atomic_dec_and_test(>outstanding_submission_g2h))
> > + wake_up_all(>ct.wq);
> > +}
> > +
> > static int guc_submission_send_busy_loop(struct intel_guc *guc,
> > const u32 *action,
> > u32 len,
> > @@ -360,11 +366,13 @@ static int guc_submission_send_busy_loop(struct
> > intel_guc *guc,
> > {
> > int err;
> > - err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
> > -
> > - if (!err && g2h_len_dw)
> > + if (g2h_len_dw)
> > atomic_inc(>outstanding_submission_g2h);
> > + err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
> > + if (err == -EBUSY && g2h_len_dw)
> > + decr_outstanding_submission_g2h(guc);
> > +
>
> here you're special casing -EBUSY, which kind of implies that the caller
> needs to handle this differently, but most callers seem to ignore the return
> code. Is the counter handled somewhere else in case of EBUSY? if so, please
> add a comment about it.
>
Good catch, this is a dead code path. Will delete.
Matt
> Daniele
>
> > return err;
> > }
> > @@ -616,7 +624,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
> > intel_guc *guc)
> > init_sched_state(ce);
> > if (pending_enable || destroyed || deregister) {
> > - atomic_dec(>outstanding_submission_g2h);
> > + decr_outstanding_submission_g2h(guc);
> > if (deregister)
> > guc_signal_context_fence(ce);
> > if (destroyed) {
> > @@ -635,7 +643,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
> > intel_guc *guc)
> > intel_engine_signal_breadcrumbs(ce->engine);
> > }
> > intel_context_sched_disable_unpin(ce);
> > - atomic_dec(>outstanding_submission_g2h);
> > + decr_outstanding_submission_g2h(guc);
> > spin_lock_irqsave(>guc_state.lock, flags);
> > guc_blocked_fence_complete(ce);
> > spin_unlock_irqrestore(>guc_state.lock, flags);
> > @@ -2583,12 +2591,6 @@ g2h_context_lookup(struct intel_guc *guc, u32
> > desc_idx)
> > return ce;
> > }
> > -static void decr_outstanding_submission_g2h(struct intel_guc *guc)
> > -{
> > - if (atomic_dec_and_test(>outstanding_submission_g2h))
> > - wake_up_all(>ct.wq);
> > -}
> > -
> > int intel_guc_deregister_done_process_msg(struct intel_guc *guc,
> > const u32 *msg,
> > u32 len)
>
Re: [Intel-gfx] [PATCH 02/27] drm/i915/guc: Fix outstanding G2H accounting
On 8/18/2021 11:16 PM, Matthew Brost wrote:
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate a G2H response thus the counter should be incremented.
Also always use helper when decrementing this value.
Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer")
Signed-off-by: Matthew Brost
Cc:
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ++-
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 69faa39da178..32c414aa9009 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -352,6 +352,12 @@ static inline void set_lrc_desc_registered(struct
intel_guc *guc, u32 id,
xa_unlock_irqrestore(>context_lookup, flags);
}
+static void decr_outstanding_submission_g2h(struct intel_guc *guc)
+{
+ if (atomic_dec_and_test(>outstanding_submission_g2h))
+ wake_up_all(>ct.wq);
+}
+
static int guc_submission_send_busy_loop(struct intel_guc *guc,
const u32 *action,
u32 len,
@@ -360,11 +366,13 @@ static int guc_submission_send_busy_loop(struct intel_guc
*guc,
{
int err;
- err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
-
- if (!err && g2h_len_dw)
+ if (g2h_len_dw)
atomic_inc(>outstanding_submission_g2h);
+ err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
+ if (err == -EBUSY && g2h_len_dw)
+ decr_outstanding_submission_g2h(guc);
+
here you're special casing -EBUSY, which kind of implies that the
caller needs to handle this differently, but most callers seem to ignore
the return code. Is the counter handled somewhere else in case of EBUSY?
if so, please add a comment about it.
Daniele
return err;
}
@@ -616,7 +624,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc)
init_sched_state(ce);
if (pending_enable || destroyed || deregister) {
- atomic_dec(>outstanding_submission_g2h);
+ decr_outstanding_submission_g2h(guc);
if (deregister)
guc_signal_context_fence(ce);
if (destroyed) {
@@ -635,7 +643,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
intel_engine_signal_breadcrumbs(ce->engine);
}
intel_context_sched_disable_unpin(ce);
- atomic_dec(>outstanding_submission_g2h);
+ decr_outstanding_submission_g2h(guc);
spin_lock_irqsave(>guc_state.lock, flags);
guc_blocked_fence_complete(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
@@ -2583,12 +2591,6 @@ g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
return ce;
}
-static void decr_outstanding_submission_g2h(struct intel_guc *guc)
-{
- if (atomic_dec_and_test(>outstanding_submission_g2h))
- wake_up_all(>ct.wq);
-}
-
int intel_guc_deregister_done_process_msg(struct intel_guc *guc,
const u32 *msg,
u32 len)
[Intel-gfx] [PATCH] drm/i915/dg1: remove __maybe_unused leftover
This was added in commit 05e265841f7e ("drm/i915/dg1: add initial DG-1
definitions") so we could continue to add support for DG1 without
risk to expose a broken UAPI. Now that we added DG1 to the PCI ID list
i915 may bind to, remove the leftover.
Fixes: d5ef86b38e4c ("drm/i915: Add pci ids and uapi for DG1")
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 93ccdc6bbd03..96cfd6427cec 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -894,7 +894,7 @@ static const struct intel_device_info rkl_info = {
.has_snoop = 1, \
.is_dgfx = 1
-static const struct intel_device_info dg1_info __maybe_unused = {
+static const struct intel_device_info dg1_info = {
GEN12_FEATURES,
DGFX_FEATURES,
.graphics_rel = 10,
--
2.31.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev7)
== Series Details ==
Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev7)
URL : https://patchwork.freedesktop.org/series/93570/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10499 -> Patchwork_20856
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/index.html
Known issues
Here are the changes found in Patchwork_20856 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +23 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@amdgpu/amd_cs_nop@sync-compute0:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-compute0.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][3] ([i915#3718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][4] -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-rkl-11600: [SKIP][6] -> [PASS][7] +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10499/fi-rkl-11600/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/fi-rkl-11600/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
Participating hosts (42 -> 35)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-tgl-1115g4 fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-
* Linux: CI_DRM_10499 -> Patchwork_20856
CI-20190529: 20190529
CI_DRM_10499: 31a08664127ff61b69d9e540ebf153eb7493d2ae @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6179: e41ebfddab3031b7765cc7cbcbf73b03c3c46bd1 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20856: eed02538bb892fe7264d9986c851963a73d86474 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
eed02538bb89 drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
be9b370eeb61 drm/i915/hdcp: read RxInfo once when reading
RepeaterAuth_Send_ReceiverID_List
e8e6771ed7e1 drm/i915/hdcp: update cp_irq_count_cached in
intel_dp_hdcp2_read_msg()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/index.html
Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On Wed, 2021-08-18 at 11:51 +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Li, Juston
> > Sent: Friday, August 13, 2021 12:14 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: seanp...@chromium.org; Gupta, Anshuman <
> > anshuman.gu...@intel.com>;
> > C, Ramalingam ; Vivi, Rodrigo
> > ; Li, Juston
> > Subject: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info
> > for mst stream
> > type1 capability check
> >
> > On some MST docking stations, rx_info can only be read after
> > RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
> > otherwise
> > the read will return -EIO.
> >
> > This behavior causes the mst stream type1 capability test to fail
> > to read rx_info
> > and determine if the topology supports type1 and fallback to type0.
> >
> > To fix this, check for type1 capability when we receive rx_info
> > within the AKE
> > flow when we read RepeaterAuth_Send_ReceiverID_List instead of an
> > explicit
> > read just for type1 capability checking.
> >
> > This does require moving where we set stream_types to after
> > hdcp2_authenticate_sink() when we get rx_info but this occurs
> > before we do
> > hdcp2_propagate_stream_management_info.
> >
> > Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check
> > for that as
> > well.
> >
> > Changes since v4:
> > - move topology_type1_capable to intel_digital_port and rename it
> > as
> > hdcp_mst_type1_capable (Anshuman)
> > - make a helper function intel_set_stream_types() to set stream
> > types
> > in hdcp2_authenticate_and_encrypt() (Anshuman)
> > - break on failure to set stream types and retry instead of
> > returning
> > - remove no longer used declaration for streams_type1_capable()
> >
> > Changes since v2:
> > - Remove no longer used variables in _intel_hdcp2_enable()
> >
> > Signed-off-by: Juston Li
> > Reviewed-by: Ramalingam C
> > ---
> > .../drm/i915/display/intel_display_types.h | 6 +-
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 64 +++
> >
> > 3 files changed, 38 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index dbdfe54d0340..1f85ff344ab7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -428,10 +428,6 @@ struct intel_hdcp_shim {
> > int (*hdcp_2_2_capable)(struct intel_digital_port *dig_port,
> > bool *capable);
> >
> > -/* Detects whether a HDCP 1.4 sink connected in MST topology */
> > -int (*streams_type1_capable)(struct intel_connector *connector,
> > - bool *capable);
> > -
> > /* Write HDCP2.2 messages */
> > int (*write_2_2_msg)(struct intel_digital_port *dig_port,
> > void *buf, size_t size);
> > @@ -1684,6 +1680,8 @@ struct intel_digital_port {
> > bool hdcp_auth_status;
> > /* HDCP port data need to pass to security f/w */
> > struct hdcp_port_data hdcp_port_data;
> > +/* Whether the MST topology supports HDCP Type 1 Content */
> > +bool hdcp_mst_type1_capable;
> >
> > void (*write_infoframe)(struct intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state, diff --
> > git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index fbfb3c4d16bb..540a669e01dd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct
> > intel_digital_port
> > *dig_port,
> > return size;
> > }
> >
> > -static int
> > -get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port
> > *dig_port, bool
> > *hdcp_1_x) -{
> > -u8 rx_info[HDCP_2_2_RXINFO_LEN];
> > -int ret;
> > -
> > -ret = drm_dp_dpcd_read(_port->dp.aux,
> > - DP_HDCP_2_2_REG_RXINFO_OFFSET,
> > - (void *)rx_info, HDCP_2_2_RXINFO_LEN);
> > -
> > -if (ret != HDCP_2_2_RXINFO_LEN)
> > -return ret >= 0 ? -EIO : ret;
> > -
> > -*hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true
> > : false;
> > -return 0;
> > -}
> > -
> > static
> > ssize_t get_receiver_id_list_rx_info(struct intel_digital_port
> > *dig_port, u32
> > *dev_cnt, u8 *byte) { @@ -665,27 +648,6 @@ int
> > intel_dp_hdcp2_capable(struct intel_digital_port *dig_port,
> > return 0;
> > }
> >
> > -static
> > -int intel_dp_mst_streams_type1_capable(struct intel_connector
> > *connector,
> > - bool *capable)
> > -{
> > -struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > -struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > -int ret;
> > -bool hdcp_1_x;
> > -
> > -ret = get_rxinfo_hdcp_1_dev_downstream(dig_port, _1_x);
> > -if (ret) {
> > -drm_dbg_kms(>drm,
> > - "[%s:%d] failed to read RxInfo ret=%d\n",
> > - connector->base.name, connector->base.base.id,
> > ret);
> >
[Intel-gfx] [PATCH v6 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and fallback
to type0.
To fix this, check for type1 capability when we receive rx_info within
the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
of an explicit read just for type1 capability checking.
This does require moving where we set stream_types to after
hdcp2_authenticate_sink() when we get rx_info but this occurs before we
do hdcp2_propagate_stream_management_info.
Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for
that as well.
Changes since v5:
- rename intel_set_stream_types() to intel_hdcp_prepare_streams()
(Anshuman)
Changes since v4:
- move topology_type1_capable to intel_digital_port and rename it as
hdcp_mst_type1_capable (Anshuman)
- make a helper function intel_set_stream_types() to set stream types
in hdcp2_authenticate_and_encrypt() (Anshuman)
- break on failure to set stream types and retry instead of returning
- remove no longer used declaration for streams_type1_capable()
Changes since v2:
- Remove no longer used variables in _intel_hdcp2_enable()
Signed-off-by: Juston Li
Reviewed-by: Ramalingam C
Reviewed-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 6 +-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
drivers/gpu/drm/i915/display/intel_hdcp.c | 64 +++
3 files changed, 38 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6bba1bed..34e90a841280 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -428,10 +428,6 @@ struct intel_hdcp_shim {
int (*hdcp_2_2_capable)(struct intel_digital_port *dig_port,
bool *capable);
- /* Detects whether a HDCP 1.4 sink connected in MST topology */
- int (*streams_type1_capable)(struct intel_connector *connector,
-bool *capable);
-
/* Write HDCP2.2 messages */
int (*write_2_2_msg)(struct intel_digital_port *dig_port,
void *buf, size_t size);
@@ -1684,6 +1680,8 @@ struct intel_digital_port {
bool hdcp_auth_status;
/* HDCP port data need to pass to security f/w */
struct hdcp_port_data hdcp_port_data;
+ /* Whether the MST topology supports HDCP Type 1 Content */
+ bool hdcp_mst_type1_capable;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index fbfb3c4d16bb..540a669e01dd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
return size;
}
-static int
-get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port *dig_port, bool
*hdcp_1_x)
-{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- int ret;
-
- ret = drm_dp_dpcd_read(_port->dp.aux,
- DP_HDCP_2_2_REG_RXINFO_OFFSET,
- (void *)rx_info, HDCP_2_2_RXINFO_LEN);
-
- if (ret != HDCP_2_2_RXINFO_LEN)
- return ret >= 0 ? -EIO : ret;
-
- *hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true : false;
- return 0;
-}
-
static
ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
@@ -665,27 +648,6 @@ int intel_dp_hdcp2_capable(struct intel_digital_port
*dig_port,
return 0;
}
-static
-int intel_dp_mst_streams_type1_capable(struct intel_connector *connector,
- bool *capable)
-{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- int ret;
- bool hdcp_1_x;
-
- ret = get_rxinfo_hdcp_1_dev_downstream(dig_port, _1_x);
- if (ret) {
- drm_dbg_kms(>drm,
- "[%s:%d] failed to read RxInfo ret=%d\n",
- connector->base.name, connector->base.base.id, ret);
- return ret;
- }
-
- *capable = !hdcp_1_x;
- return 0;
-}
-
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -834,7 +796,6 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim
= {
.stream_2_2_encryption =
[Intel-gfx] [PATCH v6 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit is set otherwise the read will return -EIO. The spec states that
the READY bit should be cleared as soon as RxInfo has been read.
In this case, the first RxInfo read succeeds but after the READY bit is
cleared, the second read fails.
Fix it by reading RxInfo once and storing it before reading the rest of
RepeaterAuth_Send_ReceiverID_List once we know the size.
Modify get_receiver_id_list_size() to read and store RxInfo in the
message buffer and also parse DEVICE_COUNT so we know the size of
RepeaterAuth_Send_ReceiverID_List.
Afterwards, retrieve the rest of the message at the offset for
seq_num_V.
Changes in v5:
- Don't change the offset define for Send_ReceiverID_List
When reading, update message offset to account for RxInfo being read
Changes in v4:
- rebase and edit commit message
Changes in v3:
- remove comment
Changes in v2:
- remove unnecessary moving of drm_i915_private from patch 1
Signed-off-by: Juston Li
Reviewed-by: Ramalingam C
Reviewed-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 31 ++--
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 1d0096654776..fbfb3c4d16bb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
intel_digital_port *dig_port, bool *hdcp
}
static
-ssize_t get_receiver_id_list_size(struct intel_digital_port *dig_port)
+ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- u32 dev_cnt;
ssize_t ret;
+ u8 *rx_info = byte;
ret = drm_dp_dpcd_read(_port->dp.aux,
DP_HDCP_2_2_REG_RXINFO_OFFSET,
@@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
intel_digital_port *dig_port)
if (ret != HDCP_2_2_RXINFO_LEN)
return ret >= 0 ? -EIO : ret;
- dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
+ *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
- if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
- dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
-
- ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
- HDCP_2_2_RECEIVER_IDS_MAX_LEN +
- (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+ if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
+ *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
return ret;
}
@@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
ktime_t msg_end = ktime_set(0, 0);
bool msg_expired;
+ u32 dev_cnt;
hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
if (!hdcp2_msg_data)
@@ -546,17 +542,22 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+ /* DP adaptation msgs has no msg_id */
+ byte++;
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
- ret = get_receiver_id_list_size(dig_port);
+ ret = get_receiver_id_list_rx_info(dig_port, _cnt, byte);
if (ret < 0)
return ret;
- size = ret;
+ byte += ret;
+ size = sizeof(struct hdcp2_rep_send_receiverid_list) -
+ HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
+ (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+ offset += HDCP_2_2_RXINFO_LEN;
}
- bytes_to_recv = size - 1;
- /* DP adaptation msgs has no msg_id */
- byte++;
+ bytes_to_recv = size - 1;
while (bytes_to_recv) {
len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
--
2.31.1
[Intel-gfx] [PATCH v6 1/3] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that
and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale
causing the wait to return right away rather than waiting for a new
CP_IRQ.
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
Reviewed-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index d697d169e8c1..1d0096654776 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -446,8 +446,6 @@ static
int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
void *buf, size_t size)
{
- struct intel_dp *dp = _port->dp;
- struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -463,8 +461,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
bytes_to_write = size - 1;
byte++;
- hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
-
while (bytes_to_write) {
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
@@ -530,6 +526,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
u8 msg_id, void *buf, size_t size)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct intel_dp *dp = _port->dp;
+ struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -546,6 +544,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
if (ret < 0)
return ret;
+ hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
ret = get_receiver_id_list_size(dig_port);
if (ret < 0)
--
2.31.1
[Intel-gfx] [PATCH v6 0/3] drm/i915/hdcp: HDCP2.2 MST dock fixes
Fixes to get HDCP2.2 over MST working on MST docking stations with certain behaviors that cause the current flow to fail. Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2. These fixes should make the flow more robust to handle behaviors that as far as I can tell are unclear in the HDCP spec: RxInfo contains repeater topology information needed for MST. The behavior on these docks is that this can only be read during RepeaterAuth_Send_ReceiverID_List when the RxStatus READY bit is set otherwise the dock will return NACK. It seems these docks treat reading this range at any other time as invalid when the READY bit isn't set possibly because it could be stale. The HDCP spec also states the READY bit is cleared after RxInfo is read. These fixes address this behavior by only reading RxInfo once during the AKE flow and reusing that data. Changes since v5: - rename intel_set_stream_types() to intel_hdcp_prepare_streams() (Anshuman) Changes since v4: - move topology_type1_capable to intel_digital_port and rename it as hdcp_mst_type1_capable (Anshuman) - make a helper function intel_set_stream_types() to set stream types in hdcp2_authenticate_and_encrypt() (Anshuman) - break on failure to set stream types and retry instead of returning - remove no longer used declaration for streams_type1_capable() Changes since v3: - Don't change the offset define for Send_ReceiverID_List When reading, update message offset to account for RxInfo being read Changes since v2: - Remove no longer used variables in _intel_hdcp2_enable() Changes since v1: - Fix subject line for 3/3 Juston Li (3): drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg() drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List drm/i915/hdcp: reuse rx_info for mst stream type1 capability check .../drm/i915/display/intel_display_types.h| 6 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 78 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 64 --- 3 files changed, 58 insertions(+), 90 deletions(-) -- 2.31.1
Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore
On Wed, Aug 18, 2021 at 01:20:54PM +0200, Heiko Carstens wrote:
> On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> > Hello,
> >
> > I have Fedora 33 running, and with the Fedore kernel update from 5.11
> > series to 5.12 my external monitor was not detected anymore. Same is
> > true with the Fedora supplied 5.13 kernel version.
> >
> > So I tried with vanilla kernel 5.11 and latest git head from Linus'
> > tree. 5.11 works while latest git head does not. Bisecting the problem
> > points to commit 32c3d9b0f51e ("Merge tag 'drm-intel-next-2021-01-27'
> > of git://anongit.freedesktop.org/drm/drm-intel into drm-next").
> >
> > Unfortunately it is a merge commit, so it looks like conflicting
> > changes have been made in the parent branches.
> >
> > Hardware in use:
> >
> > - ThinkPad X1 Yoga 4th / Carbon 7th
> > - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> >
> > The Thinkpad is connected to a ThinkPad Thunderbolt 3 Dock with a
> > Thunderbolt cable and a monitor (Eizo EV3285) is connected via
> > Displayport to the docking station.
> >
> > The monitor is detected and works without any problems (4k@60HZ)
> > before the above mentioned merge commit. With the commit and
> > afterwards it is not detected anymore and only the Thinkpad builtin
> > display can be used.
> >
> > Any idea what went wrong? I can provide more information, or test
> > debug patches if wanted. Just let me know.
>
> So looks like I made a mistake when bisecting (it literally took me
> two days due to the low power machine, even with a minimized kernel
> config). Anyway, looking into it again the first bad commit is
>
> ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
>
> With that commit the display is not detected anymore, one commit
> before that it still works. So this one seems to be broken.
>
> Ville, Stanislav, any idea how to fix this?
>
> commit ef79d62b5ce53851901d6c1d21b74cbb9e27219b
> Author: Ville Syrjälä
> Date: Fri Jan 22 22:56:32 2021 +0200
>
> drm/i915: Encapsulate dbuf state handling harder
That has nothing to do with display detection, so very mysterious.
Please file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
boot with drm.debug=0xe with both good and bad kernels and attach the
dmesg from both to the bug.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 15/17] drm/i915/dg2: use 128b/132b transcoder DDI mode
On Wed, Aug 18, 2021 at 09:10:50PM +0300, Jani Nikula wrote:
> 128b/132b has a separate transcoder DDI mode, which also requires the
> MST transport select to be set. Note that we'll use DP MST also for
> single-stream 128b/132b.
>
> Having the FDI and 128b/132b modes share the register mode value
> complicates things a bit.
>
> Bspec: 50493
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 27 ++--
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 8b8f5d679b72..1ee817348bf5 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -505,7 +505,10 @@ intel_ddi_transcoder_func_reg_val_get(struct
> intel_encoder *encoder,
> temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
> temp |= (crtc_state->fdi_lanes - 1) << 1;
> } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
> - temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> + if (crtc_state->port_clock > 100)
> + temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
> + else
> + temp |= TRANS_DDI_MODE_SELECT_DP_MST;
> temp |= DDI_PORT_WIDTH(crtc_state->lane_count);
>
> if (DISPLAY_VER(dev_priv) >= 12) {
> @@ -693,7 +696,12 @@ bool intel_ddi_connector_get_hw_state(struct
> intel_connector *intel_connector)
> break;
>
> case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
> - ret = type == DRM_MODE_CONNECTOR_VGA;
> + if (IS_DG2(dev_priv))
> + /* 128b/132b */
> + ret = false;
Maybe introduce HAS_FDI() or something to avoid these platform checks
all over?
> + else
> + /* FDI */
> + ret = type == DRM_MODE_CONNECTOR_VGA;
> break;
>
> default:
> @@ -780,8 +788,9 @@ static void intel_ddi_get_encoder_pipes(struct
> intel_encoder *encoder,
> if ((tmp & port_mask) != ddi_select)
> continue;
>
> - if ((tmp & TRANS_DDI_MODE_SELECT_MASK) ==
> - TRANS_DDI_MODE_SELECT_DP_MST)
> + if ((tmp & TRANS_DDI_MODE_SELECT_MASK) ==
> TRANS_DDI_MODE_SELECT_DP_MST ||
> + (IS_DG2(dev_priv) &&
> + (tmp & TRANS_DDI_MODE_SELECT_MASK) ==
> TRANS_DDI_MODE_SELECT_FDI_OR_128B132B))
> mst_pipe_mask |= BIT(p);
>
> *pipe_mask |= BIT(p);
> @@ -3572,9 +3581,6 @@ static void intel_ddi_read_func_ctl(struct
> intel_encoder *encoder,
> pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
> pipe_config->lane_count = 4;
> break;
> - case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
> - pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
> - break;
> case TRANS_DDI_MODE_SELECT_DP_SST:
> if (encoder->type == INTEL_OUTPUT_EDP)
> pipe_config->output_types |= BIT(INTEL_OUTPUT_EDP);
> @@ -3603,6 +3609,13 @@ static void intel_ddi_read_func_ctl(struct
> intel_encoder *encoder,
> pipe_config->infoframes.enable |=
> intel_hdmi_infoframes_enabled(encoder,
> pipe_config);
> break;
> + case TRANS_DDI_MODE_SELECT_FDI_OR_128B132B:
> + if (!IS_DG2(dev_priv)) {
> + /* FDI */
> + pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
> + break;
> + }
> + fallthrough; /* 128b/132b */
> case TRANS_DDI_MODE_SELECT_DP_MST:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
> pipe_config->lane_count =
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 13/17] drm/i915/dp: select 128b/132b channel encoding for UHBR rates
On Wed, Aug 18, 2021 at 09:10:48PM +0300, Jani Nikula wrote: > UHBR rates and 128b/132b channel encoding go hand in hand. > > Reviewed-by: Manasi Navare > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c > index 031c753fca56..01f0adc585d0 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c > @@ -495,7 +495,8 @@ intel_dp_prepare_link_train(struct intel_dp *intel_dp, > _select, 1); > > link_config[0] = crtc_state->vrr.enable ? DP_MSA_TIMING_PAR_IGNORE_EN : > 0; > - link_config[1] = DP_SET_ANSI_8B10B; > + link_config[1] = crtc_state->port_clock > 100 ? Should this be >= ? > + DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B; > drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2); > > intel_dp->DP |= DP_PORT_EN; > -- > 2.20.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 06/17] drm/i915/dp: read sink UHBR rates
On Wed, Aug 18, 2021 at 09:10:41PM +0300, Jani Nikula wrote:
> See if sink supports DP 2.0 128b/132b channel encoding, and update sink
> rates accordingly.
>
> FIXME: Also take LTTPR 128b/132b into account.
>
> Reviewed-by: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d273b3848785..079b5b37b85a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -141,6 +141,24 @@ static void intel_dp_set_sink_rates(struct intel_dp
> *intel_dp)
> intel_dp->sink_rates[i] = dp_rates[i];
> }
>
> + /*
> + * Sink rates for 128b/132b. If set, sink should support all 8b/10b
> + * rates and 10 Gbps.
> + */
> + if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B)
> {
> + u8 uhbr_rates = 0;
> +
> + drm_dp_dpcd_readb(_dp->aux,
> + DP_128B132B_SUPPORTED_LINK_RATES,
> _rates);
> +
> + if (uhbr_rates & DP_UHBR10)
> + intel_dp->sink_rates[i++] = 100;
> + if (uhbr_rates & DP_UHBR13_5)
> + intel_dp->sink_rates[i++] = 135;
> + if (uhbr_rates & DP_UHBR20)
> + intel_dp->sink_rates[i++] = 200;
OK, so the max link rate register isn't supposed to report the
new magic UHBR BW values it seems. That makes life a bit easier.
Maybe toss in a
BUILD_BUG_ON(ARRAY_SIZE(sink_rates) >= ARRAY_SIZE(dp_rates)+3);
or something to remind people that we are dealing with a fixed size
array here?
Reviewed-by: Ville Syrjälä
> + }
> +
> intel_dp->num_sink_rates = i;
> }
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 05/17] drm/i915/dp: use actual link rate values in struct link_config_limits
On Wed, Aug 18, 2021 at 09:10:40PM +0300, Jani Nikula wrote:
> The MST code uses actual link rates in the limits struct, while the DP
> code in general uses indexes to the ->common_rates[] array. Fix the
> confusion by using actual link rate values everywhere. This is a better
> abstraction than some obscure index.
>
> Rename the struct members while at it to ensure all the places are
> covered.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 30 -
> drivers/gpu/drm/i915/display/intel_dp.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 ++---
> 3 files changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 75d4ebc66941..d273b3848785 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1044,7 +1044,8 @@ intel_dp_adjust_compliance_config(struct intel_dp
> *intel_dp,
> intel_dp->num_common_rates,
>
> intel_dp->compliance.test_link_rate);
> if (index >= 0)
> - limits->min_clock = limits->max_clock = index;
> + limits->min_rate = limits->max_rate =
> + intel_dp->compliance.test_link_rate;
> limits->min_lane_count = limits->max_lane_count =
> intel_dp->compliance.test_lane_count;
> }
> @@ -1058,8 +1059,8 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> const struct link_config_limits *limits)
> {
> struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
> - int bpp, clock, lane_count;
> - int mode_rate, link_clock, link_avail;
> + int bpp, i, lane_count;
> + int mode_rate, link_rate, link_avail;
>
> for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> int output_bpp =
> intel_dp_output_bpp(pipe_config->output_format, bpp);
> @@ -1067,18 +1068,22 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> output_bpp);
>
> - for (clock = limits->min_clock; clock <= limits->max_clock;
> clock++) {
> + for (i = 0; i < intel_dp->num_common_rates; i++) {
> + link_rate = intel_dp->common_rates[i];
> + if (link_rate < limits->min_rate ||
> + link_rate > limits->max_rate)
> + continue;
> +
> for (lane_count = limits->min_lane_count;
>lane_count <= limits->max_lane_count;
>lane_count <<= 1) {
> - link_clock = intel_dp->common_rates[clock];
> - link_avail = intel_dp_max_data_rate(link_clock,
> + link_avail = intel_dp_max_data_rate(link_rate,
> lane_count);
>
> if (mode_rate <= link_avail) {
> pipe_config->lane_count = lane_count;
> pipe_config->pipe_bpp = bpp;
> - pipe_config->port_clock = link_clock;
> + pipe_config->port_clock = link_rate;
>
> return 0;
> }
> @@ -1212,7 +1217,7 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
>* with DSC enabled for the requested mode.
>*/
> pipe_config->pipe_bpp = pipe_bpp;
> - pipe_config->port_clock = intel_dp->common_rates[limits->max_clock];
> + pipe_config->port_clock = limits->max_rate;
> pipe_config->lane_count = limits->max_lane_count;
>
> if (intel_dp_is_edp(intel_dp)) {
> @@ -1321,8 +1326,8 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> /* No common link rates between source and sink */
> drm_WARN_ON(encoder->base.dev, common_len <= 0);
>
> - limits.min_clock = 0;
> - limits.max_clock = common_len - 1;
> + limits.min_rate = intel_dp->common_rates[0];
> + limits.max_rate = intel_dp->common_rates[common_len - 1];
>
> limits.min_lane_count = 1;
> limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
> @@ -1340,15 +1345,14 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
>* values correspond to the native resolution of the panel.
>*/
> limits.min_lane_count = limits.max_lane_count;
> -
Re: [Intel-gfx] [PATCH 04/17] drm/dp: add helper for extracting adjust 128b/132b TX FFE preset
On Wed, Aug 18, 2021 at 09:10:39PM +0300, Jani Nikula wrote:
> The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
> vswing and pre-emphasis.
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 14 ++
> include/drm/drm_dp_helper.h | 2 ++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 9389f92cb944..2843238a78e6 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -130,6 +130,20 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> +/* DP 2.0 128b/132b */
> +u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> +int lane)
> +{
> + int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> + int s = ((lane & 1) ?
> + DP_ADJUST_TX_FFE_PRESET_LANE1_SHIFT :
> + DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT);
> + u8 l = dp_link_status(link_status, i);
> +
> + return (l >> s) & 0xf;
> +}
> +EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
> +
> u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
>unsigned int lane)
> {
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index f3a61341011d..3ee0b3ffb8a5 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1494,6 +1494,8 @@ u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
>int lane);
> u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
> +u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
> +int lane);
> u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
>unsigned int lane);
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2)
Re-reported. Bug filed for the regression. #4009 igt@kms_atomic_transition@plane-toggle-modeset-transition - incomplete - No warnings/errors Lakshmi. -Original Message- From: Matthew Auld Sent: Thursday, August 19, 2021 6:40 AM To: Intel Graphics Development Cc: Thomas Hellström ; Vudum, Lakshminarayana Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2) On Tue, 17 Aug 2021 at 18:28, Patchwork wrote: > > Patch Details > Series:drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2) > URL:https://patchwork.freedesktop.org/series/93711/ > State:failure > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/index > .html > > CI Bug Log - changes from CI_DRM_10490_full -> Patchwork_20834_full > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_20834_full absolutely > need to be verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20834_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_20834_full: > > IGT changes > > Possible regressions > > igt@kms_atomic_transition@plane-toggle-modeset-transition: > > shard-tglb: PASS -> INCOMPLETE Lakshmi, this failure is unrelated.
Re: [Intel-gfx] [PATCH 2/4] drm/dp: use more of the extended receiver cap
On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
> Extend the use of extended receiver cap at 0x2200 to cover
> MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> the DP 2.0 128b/132b channel encoding cap.
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 9b2a2961fca8..9389f92cb944 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -608,7 +608,7 @@ static u8 drm_dp_downstream_port_count(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - u8 dpcd_ext[6];
> + u8 dpcd_ext[DP_MAIN_LINK_CHANNEL_CODING + 1];
Why are we even reading less of this than the normal receiver caps?
> int ret;
>
> /*
> --
> 2.20.1
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2)
== Series Details == Series: drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2) URL : https://patchwork.freedesktop.org/series/93711/ State : success == Summary == CI Bug Log - changes from CI_DRM_10490_full -> Patchwork_20834_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20834_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-snb2/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10490/shard-kbl6/igt@gem_ctx_isolation@preservation...@bcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-kbl1/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10490/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10490/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_suspend@basic-s4-devices: - shard-glk: NOTRUN -> [DMESG-WARN][10] ([i915#1610]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-glk1/igt@gem_exec_susp...@basic-s4-devices.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10490/shard-tglb2/igt@gem_huc_c...@huc-copy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-tglb: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-tglb1/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@access-control: - shard-tglb: NOTRUN -> [SKIP][14] ([i915#3297]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-tglb8/igt@gem_userptr_bl...@access-control.html - shard-iclb: NOTRUN -> [SKIP][15] ([i915#3297]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-iclb1/igt@gem_userptr_bl...@access-control.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][16] ([i915#3002]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-apl3/igt@gem_userptr_bl...@input-checking.html * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#198]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10490/shard-skl1/igt@i915_pm_backlight@fade_with_suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-skl6/igt@i915_pm_backlight@fade_with_suspend.html * igt@kms_addfb_basic@invalid-smem-bo-on-discrete: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#3826]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-tglb8/igt@kms_addfb_ba...@invalid-smem-bo-on-discrete.html - shard-iclb: NOTRUN -> [SKIP][20] ([i915#3826]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-iclb1/igt@kms_addfb_ba...@invalid-smem-bo-on-discrete.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#2521]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10490/shard-skl4/igt@kms_async_fl...@alternate-sync-async-flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/shard-skl9/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_atomic@plane-primary-overlay-mutable-zpos: - shard-tglb: NOTRUN ->
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
Re-reported. Following bugs are filed #4007 SNB: igt@gem_ppgtt@blt-vs-render-ctxn - fail - VM Periodic Tas invoked oom-killer #4008 TGL: igt@gem_spin_batch@legacy@bsd1 - incomplete - No logs Lakshmi. -Original Message- From: Matthew Auld Sent: Thursday, August 19, 2021 6:31 AM To: Intel Graphics Development Cc: Auld, Matthew ; Vudum, Lakshminarayana Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/buddy: add some pretty printing On Thu, 19 Aug 2021 at 14:04, Patchwork wrote: > > Patch Details > Series:series starting with [v2,1/2] drm/i915/buddy: add some pretty > printing URL:https://patchwork.freedesktop.org/series/93819/ > State:failure > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/index > .html > > CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20853_full > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_20853_full absolutely > need to be verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20853_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_20853_full: > > IGT changes > > Possible regressions > > igt@gem_ppgtt@blt-vs-render-ctxn: > > shard-snb: PASS -> FAIL > > igt@gem_spin_batch@legacy@bsd1: > > shard-tglb: PASS -> INCOMPLETE Lakshmi, these are unrelated to this series.
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
== Series Details == Series: series starting with [v2,1/2] drm/i915/buddy: add some pretty printing URL : https://patchwork.freedesktop.org/series/93819/ State : success == Summary == CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20853_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20853_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-snb2/igt@gem_ctx_persiste...@process.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][2] ([i915#3354]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_endless@dispatch@rcs0: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#3778]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb3/igt@gem_exec_endless@dispa...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-iclb3/igt@gem_exec_endless@dispa...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-iclb3/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-snb: [PASS][13] -> [FAIL][14] ([i915#4007]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-snb6/igt@gem_pp...@blt-vs-render-ctxn.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-snb7/igt@gem_pp...@blt-vs-render-ctxn.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-apl3/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-skl: NOTRUN -> [WARN][16] ([i915#2658]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-skl3/igt@gem_pwr...@basic-exhaustion.html * igt@gem_spin_batch@legacy@bsd1: - shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([i915#4008]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb3/igt@gem_spin_batch@leg...@bsd1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-tglb7/igt@gem_spin_batch@leg...@bsd1.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-apl3/igt@gem_workarou...@suspend-resume.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-apl1/igt@gem_workarou...@suspend-resume.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: NOTRUN -> [DMESG-WARN][21] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-skl3/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][22] -> [FAIL][23] ([i915#2521]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-skl7/igt@kms_async_fl...@alternate-sync-async-flip.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-skl3/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#3777]) [24]:
Re: [Intel-gfx] [PATCH 01/17] drm/dp: add DP 2.0 UHBR link rate and bw code conversions
On Wed, Aug 18, 2021 at 09:10:36PM +0300, Jani Nikula wrote:
> The bw code equals link_rate / 0.27 Gbps only for 8b/10b link
> rates. Handle DP 2.0 UHBR rates as special cases, though this is not
> pretty.
Ugh. So if I'm reading the spec right the behaviour of this
register now changes dynamically depending on the state of
some other bit in another register?
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_helper.c | 26 ++
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 6d0f2c447f3b..9b2a2961fca8 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -207,15 +207,33 @@ EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
>
> u8 drm_dp_link_rate_to_bw_code(int link_rate)
> {
> - /* Spec says link_bw = link_rate / 0.27Gbps */
> - return link_rate / 27000;
> + switch (link_rate) {
> + case 100:
> + return DP_LINK_BW_10;
> + case 135:
> + return DP_LINK_BW_13_5;
> + case 200:
> + return DP_LINK_BW_20;
> + default:
> + /* Spec says link_bw = link_rate / 0.27Gbps */
> + return link_rate / 27000;
> + }
> }
> EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
>
> int drm_dp_bw_code_to_link_rate(u8 link_bw)
> {
> - /* Spec says link_rate = link_bw * 0.27Gbps */
> - return link_bw * 27000;
> + switch (link_bw) {
> + case DP_LINK_BW_10:
> + return 100;
> + case DP_LINK_BW_13_5:
> + return 135;
> + case DP_LINK_BW_20:
> + return 200;
> + default:
> + /* Spec says link_rate = link_bw * 0.27Gbps */
> + return link_bw * 27000;
> + }
> }
> EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 5/5] drm/i915/fdi: move intel_fdi_link_freq() to intel_fdi.[ch]
On Wed, Aug 18, 2021 at 01:11:09PM +0300, Jani Nikula wrote:
> There's no performance reason to have it as static inline; move it out
> of intel_display_types.h to reduce clutter and dependency on i915_drv.h.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 9 -
> drivers/gpu/drm/i915/display/intel_fdi.c | 9 +
> drivers/gpu/drm/i915/display/intel_fdi.h | 4
> 3 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 7b5d7b1ae501..c2725d07b930 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -2040,15 +2040,6 @@ static inline u32 i9xx_dpll_compute_fp(struct dpll
> *dpll)
> return dpll->n << 16 | dpll->m1 << 8 | dpll->m2;
> }
>
> -static inline u32 intel_fdi_link_freq(struct drm_i915_private *dev_priv,
> - const struct intel_crtc_state
> *pipe_config)
> -{
> - if (HAS_DDI(dev_priv))
> - return pipe_config->port_clock; /* SPLL */
> - else
> - return dev_priv->fdi_pll_freq;
> -}
> -
> static inline bool is_ccs_modifier(u64 modifier)
> {
> return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
> diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
> b/drivers/gpu/drm/i915/display/intel_fdi.c
> index e10b9cd8e86e..970a57369b05 100644
> --- a/drivers/gpu/drm/i915/display/intel_fdi.c
> +++ b/drivers/gpu/drm/i915/display/intel_fdi.c
> @@ -95,6 +95,15 @@ static int ilk_check_fdi_lanes(struct drm_device *dev,
> enum pipe pipe,
> }
> }
>
> +u32 intel_fdi_link_freq(struct drm_i915_private *i915,
Could just change it to 'int' while at it.
Series is
Reviewed-by: Ville Syrjälä
> + const struct intel_crtc_state *pipe_config)
> +{
> + if (HAS_DDI(i915))
> + return pipe_config->port_clock; /* SPLL */
> + else
> + return i915->fdi_pll_freq;
> +}
> +
> int ilk_fdi_compute_config(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_fdi.h
> b/drivers/gpu/drm/i915/display/intel_fdi.h
> index af01d2c173a8..fd63a6a53fca 100644
> --- a/drivers/gpu/drm/i915/display/intel_fdi.h
> +++ b/drivers/gpu/drm/i915/display/intel_fdi.h
> @@ -6,12 +6,16 @@
> #ifndef _INTEL_FDI_H_
> #define _INTEL_FDI_H_
>
> +#include
> +
> struct drm_i915_private;
> struct intel_crtc;
> struct intel_crtc_state;
> struct intel_encoder;
>
> #define I915_DISPLAY_CONFIG_RETRY 1
> +u32 intel_fdi_link_freq(struct drm_i915_private *i915,
> + const struct intel_crtc_state *pipe_config);
> int ilk_fdi_compute_config(struct intel_crtc *intel_crtc,
> struct intel_crtc_state *pipe_config);
> void intel_fdi_normal_train(struct intel_crtc *crtc);
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Use max params for panels < eDP 1.4
On Thu, Aug 19, 2021 at 01:14:55AM +0800, Kai-Heng Feng wrote:
> Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> fast+narrow link on eDP again and fall back to the old max strategy on
> failure"), the screen starts to have wobbly effect.
>
> Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
> everything") doesn't help either, that means the affected eDP 1.2 panels
> only work with max params.
>
> So use max params for panels < eDP 1.4 as Windows does to solve the
> issue.
>
> v2:
> - Check eDP 1.4 instead of DPCD 1.1 to apply max params
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714
> Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and
> fall back to the old max strategy on failure")
> Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
> everything")
> Suggested-by: Ville Syrjälä
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 75d4ebc669411..f87fad78f1a9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1330,14 +1330,16 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> limits.min_bpp = intel_dp_min_bpp(pipe_config->output_format);
> limits.max_bpp = intel_dp_max_bpp(intel_dp, pipe_config);
>
> - if (intel_dp->use_max_params) {
> + if (intel_dp->use_max_params ||
> + intel_dp->edp_dpcd[0] < DP_EDP_14) {
I think we're going to need a is_edp check here or else we'll always
take this path on extenral DP when edp_dpcd[] is zeroed.
Hmm. Maybe just stick
intel_dp->use_max_params = intel_dp->edp_dpcd[0] < DP_EDP_14;
into intel_edp_init_dpcd()?
> /*
>* Use the maximum clock and number of lanes the eDP panel
>* advertizes being capable of in case the initial fast
> - * optimal params failed us. The panels are generally
> - * designed to support only a single clock and lane
> - * configuration, and typically on older panels these
> - * values correspond to the native resolution of the panel.
> + * optimal params failed us or the EDP rev is earlier than 1.4.
> + * The panels are generally designed to support only a single
> + * clock and lane configuration, and typically on older panels
> + * these values correspond to the native resolution of the
> + * panel.
>*/
> limits.min_lane_count = limits.max_lane_count;
> limits.min_clock = limits.max_clock;
> --
> 2.32.0
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support
On Wed, Aug 18, 2021 at 07:48:03PM +, Souza, Jose wrote: > On Wed, 2021-08-18 at 17:55 +0300, Ville Syrjälä wrote: > > On Tue, Aug 17, 2021 at 05:42:15PM -0700, José Roberto de Souza wrote: > > > By now all the userspace applications should have migrated to atomic > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB. > > > > > > With that we can kill frontbuffer rendering support in i915 for > > > modern platforms. > > > > > > So here converting legacy APIs into atomic commits so it can be > > > properly handled by driver i915. > > > > > > Several IGT tests will fail with this changes, because some tests > > > were stressing those frontbuffer rendering scenarios that no userspace > > > should be using by now, fixes to IGT should be sent soon. > > > > Blocking atomic commits instead of the current lightweight frontbuffer > > interface sounds like a terrible plan. How unusable is X with this > > approach? > > 100% usable, had no issues when running X in TGL and ADL-P. > Added a debug message in intel_user_framebuffer_dirty() and X is not even > using frontbuffer rendering at all. Turn off your compositor if you want to test front buffer rendering. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH V2 4/5] drm/i915/gt: Initialize unused MOCS entries with device specific values
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, August 17, 2021 3:42 AM
> To: Siddiqui, Ayaz A
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH V2 4/5] drm/i915/gt: Initialize unused MOCS
> entries with device specific values
>
> On Mon, Aug 16, 2021 at 10:22:28AM +0530, Ayaz A Siddiqui wrote:
> > During to creation mocs table,used field of drm_i915_mocs_entry is
> > being checked, if used field is 0, then it will check values of index
> > 1. All the unspecified indexes of xxx_mocs_table[] will contain
> > control value and l3cc value of index I915_MOCS_PTE if its
> > initialized.
>
> I think there might be some words missing in the description here; I'm having
> a bit of trouble following what it's saying. Maybe something like this would
> be more clear:
>
> Historically we've initialized all undefined/reserved entries in
> a platform's MOCS table to the contents of table entry #1 (i.e.,
> I915_MOCS_PTE).
>
> >
> > This patch is intended to provide capability to program device
> > specific control value and l3cc value index which can be used for all
> > the unspecified indexes of MOCS table.
>
> And maybe for this part
>
> Going forward, we can't assume that table entry #1 will always
> contain suitable values to use for undefined/reserved table
> indices. We'll allow a platform-specific table index to be
> selected at table initialization time in these cases.
>
> We should also make some mention about using this new mechanism to
> select an L3 WB entry for DG1 and all new platforms going forward, but note
> that we can't change our production gen12 platforms (TGL and RKL) since
> that would be an ABI break.
Thanks Matt for suggesting the better commit message,
will take care in next version.
>
> >
> > Signed-off-by: Ayaz A Siddiqui
> > ---
> > drivers/gpu/drm/i915/gt/intel_mocs.c | 38
> > +++-
> > 1 file changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > index df3c5d550c46a..cf00537ba4acc 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > @@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
> > unsigned int n_entries;
> > const struct drm_i915_mocs_entry *table;
> > u8 uc_index;
> > + u8 unused_entries_index;
> > };
> >
> > struct drm_i915_aux_table {
> > @@ -99,17 +100,23 @@ struct drm_i915_aux_table {
> > * Entries not part of the following tables are undefined as far as
> > * userspace is concerned and shouldn't be relied upon. For Gen < 12
> > * they will be initialized to PTE. Gen >= 12 onwards don't have a
> > setting for
> > - * PTE and will be initialized to an invalid value.
> > + * PTE and will be initialized L3 WB to catch accidental use of
> > + reserved and
> > + * unused mocs indexes.
>
> This comment doesn't seem to be quite true for all graphics ver >= 12
> platforms; TGL/RKL are still using an I915_MOCS_PTE setting (which is L3
> uncached) since we can't change it now without breaking ABI. Same for the
> NOTE2 below.
Sure I'll change it to "Gen12 onward excerpt TGL/RKL".
Regards
-Ayaz
>
>
> Matt
>
> > *
> > * The last few entries are reserved by the hardware. For ICL+ they
> > * should be initialized according to bspec and never used, for older
> > * platforms they should never be written to.
> > *
> > - * NOTE: These tables are part of bspec and defined as part of
> > hardware
> > + * NOTE1: These tables are part of bspec and defined as part of
> > + hardware
> > * interface for ICL+. For older platforms, they are part of kernel
> > * ABI. It is expected that, for specific hardware platform, existing
> > * entries will remain constant and the table will only be updated by
> > * adding new entries, filling unused positions.
> > + *
> > + * NOTE2: For GEN >= 12, reserved and unspecified MOCS indices have
> been
> > + *set to L3 WB. These reserved entries should never be used, they
> > + *may be changed to low performant variants with better coherency
> > + *in the future if more entries are needed.
> > */
> > #define GEN9_MOCS_ENTRIES \
> > MOCS_ENTRY(I915_MOCS_UNCACHED, \
> > @@ -292,17 +299,9 @@ static const struct drm_i915_mocs_entry
> > icl_mocs_table[] = { };
> >
> > static const struct drm_i915_mocs_entry dg1_mocs_table[] = {
> > - /* Error */
> > - MOCS_ENTRY(0, 0, L3_0_DIRECT),
> >
> > /* UC */
> > MOCS_ENTRY(1, 0, L3_1_UC),
> > -
> > - /* Reserved */
> > - MOCS_ENTRY(2, 0, L3_0_DIRECT),
> > - MOCS_ENTRY(3, 0, L3_0_DIRECT),
> > - MOCS_ENTRY(4, 0, L3_0_DIRECT),
> > -
> > /* WB - L3 */
> > MOCS_ENTRY(5, 0, L3_3_WB),
> > /* WB - L3 50% */
> > @@ -450,6 +449,7 @@ static unsigned int get_mocs_settings(const struct
> drm_i915_private *i915,
> >
Re: [Intel-gfx] refactor the i915 GVT support
Quoting Zhenyu Wang (2021-08-19 11:29:29)
> On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > Any updates on this? I'd really hate to miss this merge window.
> > >
> > > I'm still waiting for our validation team's report on this. I'm afraid
> > > it might be missing for next version as i915 merge window is mostly
> > > till rc5...and for any change outside of gvt, it still needs to be
> > > acked by i915 maintainers.
> >
> > Looks our validation team did have problem against recent i915 change.
> > If you like to try, we have a gvt-staging branch on
> > https://github.com/intel/gvt-linux which is generated against drm-tip
> > with gvt changes for testing, currently it's broken.
> >
> > One issue is with i915 export that intel_context_unpin has been
> > changed into static inline function. Another is that intel_gvt.c
> > should be part of i915 for gvt interface instead of depending on KVMGT
> > config.
>
> I'm working on below patch to resolve this. But I met a weird issue in
> case when building i915 as module and also kvmgt module, it caused
> busy wait on request_module("kvmgt") when boot, it doesn't happen if
> building i915 into kernel. I'm not sure what could be the reason?
>
> > But the problem I see is that after moving gvt device model (gvt/*.c
> > except kvmgt.c) into kvmgt module, we'll have issue with initial mmio
> > state which current gvt relies on, that is in design supposed to get
> > initial HW state before i915 driver has taken any operation.
As mentioned in some past discussions, I think it would be best rely on
golden MMIO located in /lib/firmware or elsewhere. This way we will better
isolate the guest system from host system updates/changes.
This should also hopefully allow enabling kvmgt module after i915 has
already loaded, as the initialization would not be conditional to
capture the MMIO.
Regards, Joonas
> > Before
> > we can ensure that, I think we may only remove MPT part first but
> > still keep gvt device model as part of i915 with config. I'll try to
> > split that out.
>
> Sorry I misread the code that as we always request kvmgt module when
> gvt init, so it should still apply original method that this isn't a
> problem. Our current validation result has shown no regression as well.
>
> ---8<---
> From 58ff84572f1a0f9d79ca1d7ec0cff5ecbe78d280 Mon Sep 17 00:00:00 2001
> From: Zhenyu Wang
> Date: Thu, 19 Aug 2021 16:36:33 +0800
> Subject: [PATCH] TESTONLY:drm/i915/gvt: potential fix for refactor against
> current tip
>
> ---
> drivers/gpu/drm/i915/Makefile | 4 +++-
> drivers/gpu/drm/i915/gt/intel_context.c | 5 +
> drivers/gpu/drm/i915/gt/intel_context.h | 3 ++-
> drivers/gpu/drm/i915/i915_trace.h | 1 +
> 4 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c4f953837f72..2248574428a1 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -296,7 +296,9 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
>
> # virtual gpu code
> i915-y += i915_vgpu.o
> -i915-$(CONFIG_DRM_I915_GVT_KVMGT) += intel_gvt.o
> +ifneq ($(CONFIG_DRM_I915_GVT_KVMGT),)
> +i915-y += intel_gvt.o
> +endif
>
> kvmgt-y += gvt/kvmgt.o \
> gvt/gvt.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 745e84c72c90..20e7522fed84 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -328,6 +328,11 @@ void __intel_context_do_unpin(struct intel_context *ce,
> int sub)
> intel_context_put(ce);
> }
>
> +void intel_context_unpin(struct intel_context *ce)
> +{
> + _intel_context_unpin(ce);
> +}
> +
> static void __intel_context_retire(struct i915_active *active)
> {
> struct intel_context *ce = container_of(active, typeof(*ce), active);
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index c41098950746..f942cbf6300a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -131,7 +131,7 @@ static inline void
> intel_context_sched_disable_unpin(struct intel_context *ce)
> __intel_context_do_unpin(ce, 2);
> }
>
> -static inline void intel_context_unpin(struct intel_context *ce)
> +static inline void _intel_context_unpin(struct intel_context *ce)
> {
> if (!ce->ops->sched_disable) {
> __intel_context_do_unpin(ce, 1);
> @@ -150,6 +150,7 @@ static inline void intel_context_unpin(struct
> intel_context *ce)
> }
> }
> }
> +void intel_context_unpin(struct intel_context *ce);
>
> void intel_context_enter_engine(struct intel_context *ce);
> void intel_context_exit_engine(struct intel_context *ce);
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index
Re: [Intel-gfx] [PATCH] drm/i915/display: Drop redundant debug print
On 16-Aug-21 5:58 PM, Jani Nikula wrote:
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
On 16-Aug-21 5:40 PM, Jani Nikula wrote:
On Mon, 16 Aug 2021, "Sharma, Swati2" wrote:
On 13-Aug-21 1:16 PM, Jani Nikula wrote:
On Thu, 12 Aug 2021, Swati Sharma wrote:
drm_dp_dpcd_read/write already has debug error message.
Drop redundant error messages which gives false
status even if correct value is read in drm_dp_dpcd_read().
I guess the only problem is it gets harder to associate the preceding
low level error messages with intel_dp_check_link_service_irq(). *shrug*
Reviewed-by: Jani Nikula
Thanks Jani for the review. Can you please merge?
There was another version with open review?
Yes. https://patchwork.freedesktop.org/series/93025/#rev3
Should I add debug prints how Imre suggested in other IRQ func
to make it generic or should it be dropped from here too?
Quoting imre
"Yes, that's why I suggested to return for the '0 value read' case
without any message printed, but still keep the message for the case
when the drm_dp_dpcd_readb() fails."
"Ok, it's good to keep them in sync at least, so I'm ok with removing
the debug messages from here too."
Please let me know what is the better approach.
IMO just nuke them.
Thanks Jani N. Imre agrees on same. Can we merge now?
https://patchwork.freedesktop.org/series/93025/#rev3
BR,
Jani
BR,
Jani.
Fixes: 9488a030ac91 ("drm/i915: Add support for enabling link status and
recovery")
Cc: Swati Sharma
Cc: Ankit Nautiyal
Cc: Uma Shankar (v2)
Cc: Jani Nikula
Cc: "Ville Syrj_l_"
Cc: Imre Deak
Cc: Manasi Navare
Cc: Uma Shankar
Cc: "Jos_ Roberto de Souza"
Cc: Sean Paul
Cc: # v5.12+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-12-ankit.k.nauti...@intel.com
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c386ef8eb200..5c84f51ad41d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3871,16 +3871,12 @@ static void intel_dp_check_link_service_irq(struct
intel_dp *intel_dp)
return;
if (drm_dp_dpcd_readb(_dp->aux,
- DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val) {
- drm_dbg_kms(>drm, "Error in reading link service irq
vector\n");
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val)
return;
- }
if (drm_dp_dpcd_writeb(_dp->aux,
- DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
- drm_dbg_kms(>drm, "Error in writing link service irq
vector\n");
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
return;
- }
if (val & HDMI_LINK_STATUS_CHANGED)
intel_dp_handle_hdmi_link_status_change(intel_dp);
--
~Swati Sharma
[Intel-gfx] ✗ Fi.CI.IGT: failure for MIPI DSI driver enhancements (rev7)
== Series Details == Series: MIPI DSI driver enhancements (rev7) URL : https://patchwork.freedesktop.org/series/92695/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20855_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20855_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20855_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_20855_full: ### IGT changes ### Possible regressions * igt@gem_exec_fence@syncobj-wait: - shard-skl: NOTRUN -> [WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-skl9/igt@gem_exec_fe...@syncobj-wait.html Known issues Here are the changes found in Patchwork_20855_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-apl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-snb6/igt@gem_ctx_persiste...@idempotent.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-apl: [PASS][4] -> [SKIP][5] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-apl6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb7/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-skl: NOTRUN -> [WARN][12] ([i915#2658]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-skl9/igt@gem_pwr...@basic-exhaustion.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1937]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-apl3/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3777]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-apl6/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-0-hflip.html * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][15] ([i915#3722]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-skl7/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html * igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-apl2/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-skl5/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html * igt@kms_chamelium@hdmi-hpd-with-enabled-mode: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +12 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/shard-snb6/igt@kms_chamel...@hdmi-hpd-with-enabled-mode.html * igt@kms_chamelium@vga-edid-read: -
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2)
On Tue, 17 Aug 2021 at 18:28, Patchwork wrote: > > Patch Details > Series:drm/i915: Ditch the i915_gem_ww_ctx loop member (rev2) > URL:https://patchwork.freedesktop.org/series/93711/ > State:failure > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20834/index.html > > CI Bug Log - changes from CI_DRM_10490_full -> Patchwork_20834_full > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_20834_full absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20834_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_20834_full: > > IGT changes > > Possible regressions > > igt@kms_atomic_transition@plane-toggle-modeset-transition: > > shard-tglb: PASS -> INCOMPLETE Lakshmi, this failure is unrelated.
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
On Thu, 19 Aug 2021 at 14:04, Patchwork wrote: > > Patch Details > Series:series starting with [v2,1/2] drm/i915/buddy: add some pretty printing > URL:https://patchwork.freedesktop.org/series/93819/ > State:failure > Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/index.html > > CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20853_full > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_20853_full absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20853_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_20853_full: > > IGT changes > > Possible regressions > > igt@gem_ppgtt@blt-vs-render-ctxn: > > shard-snb: PASS -> FAIL > > igt@gem_spin_batch@legacy@bsd1: > > shard-tglb: PASS -> INCOMPLETE Lakshmi, these are unrelated to this series.
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
== Series Details == Series: series starting with [v2,1/2] drm/i915/buddy: add some pretty printing URL : https://patchwork.freedesktop.org/series/93819/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20853_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20853_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20853_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_20853_full: ### IGT changes ### Possible regressions * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-snb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-snb6/igt@gem_pp...@blt-vs-render-ctxn.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-snb7/igt@gem_pp...@blt-vs-render-ctxn.html * igt@gem_spin_batch@legacy@bsd1: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb3/igt@gem_spin_batch@leg...@bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-tglb7/igt@gem_spin_batch@leg...@bsd1.html Known issues Here are the changes found in Patchwork_20853_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-snb2/igt@gem_ctx_persiste...@process.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][6] ([i915#3354]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_endless@dispatch@rcs0: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#3778]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb3/igt@gem_exec_endless@dispa...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-iclb3/igt@gem_exec_endless@dispa...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-iclb3/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-apl3/igt@gem_pr...@exhaustion.html * igt@gem_pwrite@basic-exhaustion: - shard-skl: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-skl3/igt@gem_pwr...@basic-exhaustion.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-apl3/igt@gem_workarou...@suspend-resume.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-apl1/igt@gem_workarou...@suspend-resume.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: NOTRUN -> [DMESG-WARN][21] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-skl3/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [PASS][22] -> [FAIL][23] ([i915#2521]) [22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for MIPI DSI driver enhancements (rev7)
== Series Details ==
Series: MIPI DSI driver enhancements (rev7)
URL : https://patchwork.freedesktop.org/series/92695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498 -> Patchwork_20855
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/index.html
Known issues
Here are the changes found in Patchwork_20855 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#3958])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#1372])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_selftest@live@gtt:
- {fi-tgl-dsi}: [DMESG-WARN][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-dsi/igt@i915_selftest@l...@gtt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/fi-tgl-dsi/igt@i915_selftest@l...@gtt.html
* igt@i915_selftest@live@perf:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#2867]) -> [PASS][8] +6 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
Warnings
* igt@kms_psr@primary_page_flip:
- fi-tgl-1115g4: [SKIP][9] ([i915#1072]) -> [SKIP][10] ([i915#1072] /
[i915#1385])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-1115g4/igt@kms_psr@primary_page_flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/fi-tgl-1115g4/igt@kms_psr@primary_page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1385]: https://gitlab.freedesktop.org/drm/intel/issues/1385
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
Participating hosts (35 -> 33)
--
Missing(2): fi-kbl-soraka fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_10498 -> Patchwork_20855
CI-20190529: 20190529
CI_DRM_10498: b66f2ed13db3f8f7bcf616cea0e59ebe8728b131 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6178: 146260200f9a6d4536e48a195e2ab49a07d4f0c1 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20855: 274307b0a40f6a7648cac20bdef790e8c9523819 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
274307b0a40f drm/i915/dsi: Read/write proper brightness value via MIPI DCS
command
f7aea1033bd7 drm/i915/dsi: Retrieve max brightness level from VBT.
f50ca18f152a drm/i915: Get proper min cdclk if vDSC enabled
e42e37033e14 drm/i915/dsi: refine send MIPI DCS command sequence
d1c8739af9ae drm/i915/dsi: wait for header and payload credit available
c45bb5984386 drm/i915/jsl: program DSI panel GPIOs
7b7b4e96bce6 drm/i915/dsi: send correct gpio_number on gen11 platform
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20855/index.html
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/debugfs: hook up ttm_resource_manager_debug
On 8/19/21 11:34 AM, Matthew Auld wrote: This should give a more complete view of the various bits of internal resource manager state, for device local-memory. v2(Thomas): - Move the region printing into a nice helper Signed-off-by: Matthew Auld Cc: Thomas Hellström For the series (2/2) Reviewed-by: Thomas Hellström
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for MIPI DSI driver enhancements (rev7)
== Series Details == Series: MIPI DSI driver enhancements (rev7) URL : https://patchwork.freedesktop.org/series/92695/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1901:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1901:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1901:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34:expected struct i915_address_space *vm +drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34:got struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:expected struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:got struct i915_address_space * +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:expected struct i915_address_space *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:got struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1268:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for MIPI DSI driver enhancements (rev7)
== Series Details == Series: MIPI DSI driver enhancements (rev7) URL : https://patchwork.freedesktop.org/series/92695/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7b7b4e96bce6 drm/i915/dsi: send correct gpio_number on gen11 platform c45bb5984386 drm/i915/jsl: program DSI panel GPIOs d1c8739af9ae drm/i915/dsi: wait for header and payload credit available e42e37033e14 drm/i915/dsi: refine send MIPI DCS command sequence f50ca18f152a drm/i915: Get proper min cdclk if vDSC enabled f7aea1033bd7 drm/i915/dsi: Retrieve max brightness level from VBT. -:58: WARNING:LINE_CONTINUATIONS: Avoid unnecessary line continuations #58: FILE: drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c:154: + panel->backlight.max = dev_priv->vbt.backlight.max_brightness_level \ -:61: WARNING:LINE_CONTINUATIONS: Avoid unnecessary line continuations #61: FILE: drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c:157: + panel->backlight.level = dev_priv->vbt.backlight.max_brightness_level \ total: 0 errors, 2 warnings, 0 checks, 42 lines checked 274307b0a40f drm/i915/dsi: Read/write proper brightness value via MIPI DCS command
Re: [Intel-gfx] [PATCH v3 7/9] drm: update global mutex lock in the ioctl handler
On Thu, Aug 19, 2021 at 12:53 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/8/21 7:02 pm, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
> >> In a future patch, a read lock on drm_device.master_rwsem is
> >> held in the ioctl handler before the check for ioctl
> >> permissions. However, this produces the following lockdep splat:
> >>
> >> ==
> >> WARNING: possible circular locking dependency detected
> >> 5.14.0-rc6-CI-Patchwork_20831+ #1 Tainted: G U
> >> --
> >> kms_lease/1752 is trying to acquire lock:
> >> 827bad88 (drm_global_mutex){+.+.}-{3:3}, at: drm_open+0x64/0x280
> >>
> >> but task is already holding lock:
> >> 88812e350108 (>master_rwsem){}-{3:3}, at:
> >> drm_ioctl_kernel+0xfb/0x1a0
> >>
> >> which lock already depends on the new lock.
> >>
> >> the existing dependency chain (in reverse order) is:
> >>
> >> -> #2 (>master_rwsem){}-{3:3}:
> >> lock_acquire+0xd3/0x310
> >> down_read+0x3b/0x140
> >> drm_master_internal_acquire+0x1d/0x60
> >> drm_client_modeset_commit+0x10/0x40
> >> __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
> >> drm_fb_helper_set_par+0x34/0x40
> >> intel_fbdev_set_par+0x11/0x40 [i915]
> >> fbcon_init+0x270/0x4f0
> >> visual_init+0xc6/0x130
> >> do_bind_con_driver+0x1de/0x2c0
> >> do_take_over_console+0x10e/0x180
> >> do_fbcon_takeover+0x53/0xb0
> >> register_framebuffer+0x22d/0x310
> >> __drm_fb_helper_initial_config_and_unlock+0x36c/0x540
> >> intel_fbdev_initial_config+0xf/0x20 [i915]
> >> async_run_entry_fn+0x28/0x130
> >> process_one_work+0x26d/0x5c0
> >> worker_thread+0x37/0x390
> >> kthread+0x13b/0x170
> >> ret_from_fork+0x1f/0x30
> >>
> >> -> #1 (>lock){+.+.}-{3:3}:
> >> lock_acquire+0xd3/0x310
> >> __mutex_lock+0xa8/0x930
> >> __drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xb0
> >> intel_fbdev_restore_mode+0x2b/0x50 [i915]
> >> drm_lastclose+0x27/0x50
> >> drm_release_noglobal+0x42/0x60
> >> __fput+0x9e/0x250
> >> task_work_run+0x6b/0xb0
> >> exit_to_user_mode_prepare+0x1c5/0x1d0
> >> syscall_exit_to_user_mode+0x19/0x50
> >> do_syscall_64+0x46/0xb0
> >> entry_SYSCALL_64_after_hwframe+0x44/0xae
> >>
> >> -> #0 (drm_global_mutex){+.+.}-{3:3}:
> >> validate_chain+0xb39/0x1e70
> >> __lock_acquire+0x5a1/0xb70
> >> lock_acquire+0xd3/0x310
> >> __mutex_lock+0xa8/0x930
> >> drm_open+0x64/0x280
> >> drm_stub_open+0x9f/0x100
> >> chrdev_open+0x9f/0x1d0
> >> do_dentry_open+0x14a/0x3a0
> >> dentry_open+0x53/0x70
> >> drm_mode_create_lease_ioctl+0x3cb/0x970
> >> drm_ioctl_kernel+0xc9/0x1a0
> >> drm_ioctl+0x201/0x3d0
> >> __x64_sys_ioctl+0x6a/0xa0
> >> do_syscall_64+0x37/0xb0
> >> entry_SYSCALL_64_after_hwframe+0x44/0xae
> >>
> >> other info that might help us debug this:
> >> Chain exists of:
> >>drm_global_mutex --> >lock --> >master_rwsem
> >> Possible unsafe locking scenario:
> >> CPU0CPU1
> >>
> >>lock(>master_rwsem);
> >> lock(>lock);
> >> lock(>master_rwsem);
> >>lock(drm_global_mutex);
> >>
> >> *** DEADLOCK ***
> >>
> >> The lock hierarchy inversion happens because we grab the
> >> drm_global_mutex while already holding on to master_rwsem. To avoid
> >> this, we do some prep work to grab the drm_global_mutex before
> >> checking for ioctl permissions.
> >>
> >> At the same time, we update the check for the global mutex to use the
> >> drm_dev_needs_global_mutex helper function.
> >
> > This is intentional, essentially we force all non-legacy drivers to have
> > unlocked ioctl (otherwise everyone forgets to set that flag).
> >
> > For non-legacy drivers the global lock only ensures ordering between
> > drm_open and lastclose (I think at least), and between
> > drm_dev_register/unregister and the backwards ->load/unload callbacks
> > (which are called in the wrong place, but we cannot fix that for legacy
> > drivers).
> >
> > ->load/unload should be completely unused (maybe radeon still uses it),
> > and ->lastclose is also on the decline.
> >
>
> Ah ok got it, I'll change the check back to
> drm_core_check_feature(dev, DRIVER_LEGACY) then.
>
> > Maybe we should update the comment of drm_global_mutex to explain what it
> > protects and why.
> >
>
> The comments in drm_dev_needs_global_mutex make sense I think, I just
> didn't read the code closely enough.
>
> > I'm also confused how this patch connects to the splat, since for i915 we
>
> Right, my bad, this is a separate instance of
[Intel-gfx] [v4] drm/i915/dsi: Read/write proper brightness value via MIPI DCS command
Driver has to swap the endian before send brightness level value
to tcon.
v2: Use __be16 instead of u16 to fix sparse warning.
v3: Send one or two bytes brightness value depend on the precision.
Reported-by: kernel test robot
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Vandita Kulkarni
Cc: Cooper Chiou
Cc: William Tseng
Signed-off-by: Lee Shawn C
---
.../drm/i915/display/intel_dsi_dcs_backlight.c| 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index cd85520d36e2..b8e14122a689 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -47,33 +47,36 @@ static u32 dcs_get_backlight(struct intel_connector
*connector, enum pipe unused
{
struct intel_encoder *encoder = intel_attached_encoder(connector);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+ struct intel_panel *panel = >panel;
struct mipi_dsi_device *dsi_device;
- u8 data = 0;
+ u8 data[2] = {0, 0};
enum port port;
/* FIXME: Need to take care of 16 bit brightness level */
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
mipi_dsi_dcs_read(dsi_device, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
- , sizeof(data));
+ ,
+ (panel->backlight.max >> 8) ? sizeof(data) :
1);
break;
}
- return data;
+ return ((data[1] << 8) | data[0]);
}
static void dcs_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
{
struct intel_dsi *intel_dsi =
enc_to_intel_dsi(to_intel_encoder(conn_state->best_encoder));
+ struct intel_panel *panel =
_intel_connector(conn_state->connector)->panel;
struct mipi_dsi_device *dsi_device;
- u8 data = level;
+ __be16 data = cpu_to_be16(level);
enum port port;
- /* FIXME: Need to take care of 16 bit brightness level */
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
dsi_device = intel_dsi->dsi_hosts[port]->device;
mipi_dsi_dcs_write(dsi_device, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
- , sizeof(data));
+ ,
+ (panel->backlight.max >> 8) ? sizeof(data) :
1);
}
}
--
2.17.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm, kernel: update locking for DRM (rev2)
== Series Details ==
Series: drm, kernel: update locking for DRM (rev2)
URL : https://patchwork.freedesktop.org/series/93782/
State : failure
== Summary ==
Applying: drm: move master_lookup_lock into drm_device
Applying: drm: hold master_lookup_lock when releasing a drm_file's master
Applying: drm: check for null master in drm_is_current_master_locked
Applying: drm: fix potential null ptr dereferences in drm_{auth, ioctl}
Applying: drm: protect magic_map, unique{_len} with master_lookup_lock
Applying: drm: convert drm_device.master_mutex into a rwsem
Applying: drm: update global mutex lock in the ioctl handler
error: patch failed: drivers/gpu/drm/drm_ioctl.c:712
error: drivers/gpu/drm/drm_ioctl.c: patch does not apply
error: patch failed: drivers/gpu/drm/drm_lease.c:500
error: drivers/gpu/drm/drm_lease.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Using index info to reconstruct a base tree...
M drivers/gpu/drm/drm_ioctl.c
M drivers/gpu/drm/drm_lease.c
Patch failed at 0007 drm: update global mutex lock in the ioctl handler
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH 7/8] drm/i915/fbc: Implement Wa_16011863758 for icl+
Maybe that TODO comment could be moved into the code instead of leaving
it just into commit message?
Either way, patch look ok to me.
Reviewed-by: Juha-Pekka Heikkila
On 2.7.2021 23.46, Ville Syrjala wrote:
From: Ville Syrjälä
There's some kind of weird corner cases in FBC which requires
FBC segments to be separated by at least one extra cacheline.
Make sure that is present.
TODO: the formula laid out in the spec seem to be semi-nonsense
so this is mostly my interpretation on what it is actually trying
to say. Need to wait for clarification from the hw folks to know
for sure.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2da5295092e7..daf2191dd3f6 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -88,6 +88,16 @@ static unsigned int intel_fbc_cfb_stride(struct
drm_i915_private *i915,
{
unsigned int stride = _intel_fbc_cfb_stride(cache);
+ /*
+* Wa_16011863758: icl+
+* CFB segment stride needs at least one extra cacheline.
+* We make sure each line has an extra cacheline so that
+* the 4 line segment will have one regarless of the
+* compression limit we choose later.
+*/
+ if (DISPLAY_VER(i915) >= 11)
+ stride = max(stride, cache->plane.src_w * 4 + 64u);
+
/*
* At least some of the platforms require each 4 line segment to
* be 512 byte aligned. Aligning each line to 512 bytes guarantees
Re: [Intel-gfx] [PATCH v3 7/9] drm: update global mutex lock in the ioctl handler
On 18/8/21 7:02 pm, Daniel Vetter wrote:
On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this produces the following lockdep splat:
==
WARNING: possible circular locking dependency detected
5.14.0-rc6-CI-Patchwork_20831+ #1 Tainted: G U
--
kms_lease/1752 is trying to acquire lock:
827bad88 (drm_global_mutex){+.+.}-{3:3}, at: drm_open+0x64/0x280
but task is already holding lock:
88812e350108 (>master_rwsem){}-{3:3}, at:
drm_ioctl_kernel+0xfb/0x1a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>master_rwsem){}-{3:3}:
lock_acquire+0xd3/0x310
down_read+0x3b/0x140
drm_master_internal_acquire+0x1d/0x60
drm_client_modeset_commit+0x10/0x40
__drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
drm_fb_helper_set_par+0x34/0x40
intel_fbdev_set_par+0x11/0x40 [i915]
fbcon_init+0x270/0x4f0
visual_init+0xc6/0x130
do_bind_con_driver+0x1de/0x2c0
do_take_over_console+0x10e/0x180
do_fbcon_takeover+0x53/0xb0
register_framebuffer+0x22d/0x310
__drm_fb_helper_initial_config_and_unlock+0x36c/0x540
intel_fbdev_initial_config+0xf/0x20 [i915]
async_run_entry_fn+0x28/0x130
process_one_work+0x26d/0x5c0
worker_thread+0x37/0x390
kthread+0x13b/0x170
ret_from_fork+0x1f/0x30
-> #1 (>lock){+.+.}-{3:3}:
lock_acquire+0xd3/0x310
__mutex_lock+0xa8/0x930
__drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xb0
intel_fbdev_restore_mode+0x2b/0x50 [i915]
drm_lastclose+0x27/0x50
drm_release_noglobal+0x42/0x60
__fput+0x9e/0x250
task_work_run+0x6b/0xb0
exit_to_user_mode_prepare+0x1c5/0x1d0
syscall_exit_to_user_mode+0x19/0x50
do_syscall_64+0x46/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (drm_global_mutex){+.+.}-{3:3}:
validate_chain+0xb39/0x1e70
__lock_acquire+0x5a1/0xb70
lock_acquire+0xd3/0x310
__mutex_lock+0xa8/0x930
drm_open+0x64/0x280
drm_stub_open+0x9f/0x100
chrdev_open+0x9f/0x1d0
do_dentry_open+0x14a/0x3a0
dentry_open+0x53/0x70
drm_mode_create_lease_ioctl+0x3cb/0x970
drm_ioctl_kernel+0xc9/0x1a0
drm_ioctl+0x201/0x3d0
__x64_sys_ioctl+0x6a/0xa0
do_syscall_64+0x37/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Chain exists of:
drm_global_mutex --> >lock --> >master_rwsem
Possible unsafe locking scenario:
CPU0CPU1
lock(>master_rwsem);
lock(>lock);
lock(>master_rwsem);
lock(drm_global_mutex);
*** DEADLOCK ***
The lock hierarchy inversion happens because we grab the
drm_global_mutex while already holding on to master_rwsem. To avoid
this, we do some prep work to grab the drm_global_mutex before
checking for ioctl permissions.
At the same time, we update the check for the global mutex to use the
drm_dev_needs_global_mutex helper function.
This is intentional, essentially we force all non-legacy drivers to have
unlocked ioctl (otherwise everyone forgets to set that flag).
For non-legacy drivers the global lock only ensures ordering between
drm_open and lastclose (I think at least), and between
drm_dev_register/unregister and the backwards ->load/unload callbacks
(which are called in the wrong place, but we cannot fix that for legacy
drivers).
->load/unload should be completely unused (maybe radeon still uses it),
and ->lastclose is also on the decline.
Ah ok got it, I'll change the check back to
drm_core_check_feature(dev, DRIVER_LEGACY) then.
Maybe we should update the comment of drm_global_mutex to explain what it
protects and why.
The comments in drm_dev_needs_global_mutex make sense I think, I just
didn't read the code closely enough.
I'm also confused how this patch connects to the splat, since for i915 we
Right, my bad, this is a separate instance of circular locking. I was
too hasty when I saw that for legacy drivers we might grab master_rwsem
then drm_global_mutex in the ioctl handler.
shouldn't be taking the drm_global_lock here at all. The problem seems to
be the drm_open_helper when we create a new lease, which is an entirely
different can of worms.
I'm honestly not sure how to best do that, but we should be able to create
a file and then call drm_open_helper directly, or well a version of that
which never takes the drm_global_mutex. Because that is not needed for
nested drm_file opening:
- legacy drivers never go down
Re: [Intel-gfx] [PATCH 6/8] drm/i915/fbc: Align FBC segments to 512B on glk+
Look ok to me.
Reviewed-by: Juha-Pekka Heikkila
On 2.7.2021 23.46, Ville Syrjala wrote:
From: Ville Syrjälä
Apply the same 512 byte FBC segment alignment to glk+ as we use
on skl+. The only real difference is that we now have a dedicated
register for the FBC override stride. Not 100% sure which
platforms really need the 512B alignment, but it's easieest
to just do it on everything.
Also the hardware no longer seems to misclaculate the CFB stride
for linear, so we can omit the use of the override stride for
linear unless the stride is misaligned.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 14 +++---
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2baf58af016c..2da5295092e7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -93,7 +93,7 @@ static unsigned int intel_fbc_cfb_stride(struct
drm_i915_private *i915,
* be 512 byte aligned. Aligning each line to 512 bytes guarantees
* that regardless of the compression limit we choose later.
*/
- if (DISPLAY_VER(i915) == 9)
+ if (DISPLAY_VER(i915) >= 9)
return ALIGN(stride, 512);
else
return stride;
@@ -334,10 +334,18 @@ static void gen7_fbc_activate(struct drm_i915_private
*dev_priv)
const struct intel_fbc_reg_params *params = >params;
u32 dpfc_ctl;
- /* Display WA #0529: skl, kbl, bxt. */
- if (DISPLAY_VER(dev_priv) == 9) {
+ if (DISPLAY_VER(dev_priv) >= 10) {
u32 val = 0;
+ if (params->override_cfb_stride)
+ val |= FBC_STRIDE_OVERRIDE |
+ FBC_STRIDE(params->override_cfb_stride /
fbc->limit);
+
+ intel_de_write(dev_priv, GLK_FBC_STRIDE, val);
+ } else if (DISPLAY_VER(dev_priv) == 9) {
+ u32 val = 0;
+
+ /* Display WA #0529: skl, kbl, bxt. */
if (params->override_cfb_stride)
val |= CHICKEN_FBC_STRIDE_OVERRIDE |
CHICKEN_FBC_STRIDE(params->override_cfb_stride /
fbc->limit);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab2bd4837efd..7cf318d84d81 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3334,6 +3334,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define ILK_DPFC_DISABLE_DUMMY0 (1 << 8)
#define ILK_DPFC_CHICKEN_COMP_DUMMY_PIXEL (1 << 14)
#define ILK_DPFC_NUKE_ON_ANY_MODIFICATION (1 << 23)
+#define GLK_FBC_STRIDE _MMIO(0x43228)
+#define FBC_STRIDE_OVERRIDE REG_BIT(15)
+#define FBC_STRIDE_MASK REG_GENMASK(14, 0)
+#define FBC_STRIDE(x)REG_FIELD_PREP(FBC_STRIDE_MASK, (x))
#define ILK_FBC_RT_BASE _MMIO(0x2128)
#define ILK_FBC_RT_VALID(1 << 0)
#define SNB_FBC_FRONT_BUFFER(1 << 1)
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/buddy: add some pretty printing
URL : https://patchwork.freedesktop.org/series/93819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498 -> Patchwork_20853
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/index.html
Known issues
Here are the changes found in Patchwork_20853 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][1] -> [DMESG-FAIL][2] ([i915#3928])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
* igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][3] ([i915#3928])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-rkl-guc/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-1115g4: [DMESG-WARN][4] ([i915#4002]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-1115g4/igt@i915_module_l...@reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-tgl-1115g4/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gtt:
- {fi-tgl-dsi}: [DMESG-WARN][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-dsi/igt@i915_selftest@l...@gtt.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-tgl-dsi/igt@i915_selftest@l...@gtt.html
* igt@i915_selftest@live@perf:
- {fi-tgl-dsi}: [DMESG-WARN][8] ([i915#2867]) -> [PASS][9] +6 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: [DMESG-WARN][10] ([i915#4002]) -> [DMESG-FAIL][11]
([i915#1888])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-tgl-1115g4: [INCOMPLETE][12] -> [INCOMPLETE][13] ([i915#1385])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
* igt@kms_psr@primary_page_flip:
- fi-tgl-1115g4: [SKIP][14] ([i915#1072]) -> [SKIP][15] ([i915#1072] /
[i915#1385])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-1115g4/igt@kms_psr@primary_page_flip.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/fi-tgl-1115g4/igt@kms_psr@primary_page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1385]: https://gitlab.freedesktop.org/drm/intel/issues/1385
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928
[i915#4002]: https://gitlab.freedesktop.org/drm/intel/issues/4002
Participating hosts (35 -> 34)
--
Missing(1): fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_10498 -> Patchwork_20853
CI-20190529: 20190529
CI_DRM_10498: b66f2ed13db3f8f7bcf616cea0e59ebe8728b131 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6178: 146260200f9a6d4536e48a195e2ab49a07d4f0c1 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20853: fa9e94eff7ca7b08e89ecc38f18d1faa67f89951 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fa9e94eff7ca drm/i915/debugfs: hook up ttm_resource_manager_debug
1e4418171eeb drm/i915/buddy: add some pretty printing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for refactor the i915 GVT support
== Series Details == Series: refactor the i915 GVT support URL : https://patchwork.freedesktop.org/series/93816/ State : failure == Summary == Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH v3 8/9] kernel: export task_work_add
On 19/8/21 5:26 pm, Christoph Hellwig wrote: On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote: +EXPORT_SYMBOL(task_work_add); EXPORT_SYMBOL_GPL for this kinds of functionality, please. Thanks, I wasn't aware of the GPL-only export. I'll update this in a future series if we still need the export.
[Intel-gfx] [PATCH v2 2/2] drm/i915/debugfs: hook up ttm_resource_manager_debug
This should give a more complete view of the various bits of internal
resource manager state, for device local-memory.
v2(Thomas):
- Move the region printing into a nice helper
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/intel_memory_region.c | 12
drivers/gpu/drm/i915/intel_memory_region.h | 4
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index eec0d349ea6a..04351a851586 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -238,6 +238,7 @@ i915_debugfs_describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
static int i915_gem_object_info(struct seq_file *m, void *data)
{
struct drm_i915_private *i915 = node_to_i915(m->private);
+ struct drm_printer p = drm_seq_file_printer(m);
struct intel_memory_region *mr;
enum intel_region_id id;
@@ -246,8 +247,7 @@ static int i915_gem_object_info(struct seq_file *m, void
*data)
atomic_read(>mm.free_count),
i915->mm.shrink_memory);
for_each_memory_region(mr, i915, id)
- seq_printf(m, "%s: total:%pa, available:%pa bytes\n",
- mr->name, >total, >avail);
+ intel_memory_region_debug(mr, );
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 779eb2fa90b6..e7f7e6627750 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -78,6 +78,18 @@ int intel_memory_region_reserve(struct intel_memory_region
*mem,
return i915_ttm_buddy_man_reserve(man, offset, size);
}
+void intel_memory_region_debug(struct intel_memory_region *mr,
+ struct drm_printer *printer)
+{
+ drm_printf(printer, "%s: ", mr->name);
+
+ if (mr->region_private)
+ ttm_resource_manager_debug(mr->region_private, printer);
+ else
+ drm_printf(printer, "total:%pa, available:%pa bytes\n",
+ >total, >avail);
+}
+
struct intel_memory_region *
intel_memory_region_create(struct drm_i915_private *i915,
resource_size_t start,
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 1f2b96efa69d..3feae3353d33 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -15,6 +15,7 @@
struct drm_i915_private;
struct drm_i915_gem_object;
+struct drm_printer;
struct intel_memory_region;
struct sg_table;
struct ttm_resource;
@@ -127,6 +128,9 @@ int intel_memory_region_reserve(struct intel_memory_region
*mem,
resource_size_t offset,
resource_size_t size);
+void intel_memory_region_debug(struct intel_memory_region *mr,
+ struct drm_printer *printer);
+
struct intel_memory_region *
i915_gem_ttm_system_setup(struct drm_i915_private *i915,
u16 type, u16 instance);
--
2.26.3
[Intel-gfx] [PATCH v2 1/2] drm/i915/buddy: add some pretty printing
Implement the debug hook for the buddy resource manager. For this we
want to print out the status of the memory manager, including how much
memory is still allocatable, what page sizes we have etc. This will be
triggered when TTM is unable to fulfil an allocation request for device
local-memory.
v2(Thomas):
- s/MB/MiB
- s/KB/KiB
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_buddy.c | 45 +++
drivers/gpu/drm/i915/i915_buddy.h | 8
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 20 -
3 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_buddy.c
b/drivers/gpu/drm/i915/i915_buddy.c
index 7b274c51cac0..6e2ad68f8f3f 100644
--- a/drivers/gpu/drm/i915/i915_buddy.c
+++ b/drivers/gpu/drm/i915/i915_buddy.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "i915_buddy.h"
@@ -82,6 +83,7 @@ int i915_buddy_init(struct i915_buddy_mm *mm, u64 size, u64
chunk_size)
size = round_down(size, chunk_size);
mm->size = size;
+ mm->avail = size;
mm->chunk_size = chunk_size;
mm->max_order = ilog2(size) - ilog2(chunk_size);
@@ -155,6 +157,8 @@ void i915_buddy_fini(struct i915_buddy_mm *mm)
i915_block_free(mm, mm->roots[i]);
}
+ GEM_WARN_ON(mm->avail != mm->size);
+
kfree(mm->roots);
kfree(mm->free_list);
}
@@ -230,6 +234,7 @@ void i915_buddy_free(struct i915_buddy_mm *mm,
struct i915_buddy_block *block)
{
GEM_BUG_ON(!i915_buddy_block_is_allocated(block));
+ mm->avail += i915_buddy_block_size(mm, block);
__i915_buddy_free(mm, block);
}
@@ -283,6 +288,7 @@ i915_buddy_alloc(struct i915_buddy_mm *mm, unsigned int
order)
}
mark_allocated(block);
+ mm->avail -= i915_buddy_block_size(mm, block);
kmemleak_update_trace(block);
return block;
@@ -368,6 +374,7 @@ int i915_buddy_alloc_range(struct i915_buddy_mm *mm,
}
mark_allocated(block);
+ mm->avail -= i915_buddy_block_size(mm, block);
list_add_tail(>link, );
continue;
}
@@ -402,6 +409,44 @@ int i915_buddy_alloc_range(struct i915_buddy_mm *mm,
return err;
}
+void i915_buddy_block_print(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block,
+ struct drm_printer *p)
+{
+ u64 start = i915_buddy_block_offset(block);
+ u64 size = i915_buddy_block_size(mm, block);
+
+ drm_printf(p, "%#018llx-%#018llx: %llu\n", start, start + size, size);
+}
+
+void i915_buddy_print(struct i915_buddy_mm *mm, struct drm_printer *p)
+{
+ int order;
+
+ drm_printf(p, "chunk_size: %lluKiB, total: %lluMiB, free: %lluMiB\n",
+ mm->chunk_size >> 10, mm->size >> 20, mm->avail >> 20);
+
+ for (order = mm->max_order; order >= 0; order--) {
+ struct i915_buddy_block *block;
+ u64 count = 0, free;
+
+ list_for_each_entry(block, >free_list[order], link) {
+ GEM_BUG_ON(!i915_buddy_block_is_free(block));
+ count++;
+ }
+
+ drm_printf(p, "order-%d ", order);
+
+ free = count * (mm->chunk_size << order);
+ if (free < SZ_1M)
+ drm_printf(p, "free: %lluKiB", free >> 10);
+ else
+ drm_printf(p, "free: %lluMiB", free >> 20);
+
+ drm_printf(p, ", pages: %llu\n", count);
+ }
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/i915_buddy.c"
#endif
diff --git a/drivers/gpu/drm/i915/i915_buddy.h
b/drivers/gpu/drm/i915/i915_buddy.h
index 3940d632f208..7077742112ac 100644
--- a/drivers/gpu/drm/i915/i915_buddy.h
+++ b/drivers/gpu/drm/i915/i915_buddy.h
@@ -10,6 +10,8 @@
#include
#include
+#include
+
struct i915_buddy_block {
#define I915_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
#define I915_BUDDY_HEADER_STATE GENMASK_ULL(11, 10)
@@ -69,6 +71,7 @@ struct i915_buddy_mm {
/* Must be at least PAGE_SIZE */
u64 chunk_size;
u64 size;
+ u64 avail;
};
static inline u64
@@ -129,6 +132,11 @@ void i915_buddy_free(struct i915_buddy_mm *mm, struct
i915_buddy_block *block);
void i915_buddy_free_list(struct i915_buddy_mm *mm, struct list_head *objects);
+void i915_buddy_print(struct i915_buddy_mm *mm, struct drm_printer *p);
+void i915_buddy_block_print(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block,
+ struct drm_printer *p);
+
void i915_buddy_module_exit(void);
int i915_buddy_module_init(void);
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index
Re: [Intel-gfx] [PATCH v3 8/9] kernel: export task_work_add
On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote: > +EXPORT_SYMBOL(task_work_add); EXPORT_SYMBOL_GPL for this kinds of functionality, please.
[Intel-gfx] ✗ Fi.CI.IGT: failure for Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
== Series Details == Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3) URL : https://patchwork.freedesktop.org/series/93704/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10498_full -> Patchwork_20851_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20851_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20851_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_20851_full: ### IGT changes ### Possible regressions * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-skl3/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-skl9/igt@gem_...@unwedge-stress.html Known issues Here are the changes found in Patchwork_20851_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-iclb: NOTRUN -> [SKIP][3] ([i915#1839]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-iclb5/igt@feature_discov...@display-4x.html * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-snb7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][6] ([i915#3354]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-iclb6/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][13] -> [SKIP][14] ([fdo#109271]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109313]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-iclb5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#118] / [i915#95]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-glk9/igt@gem_exec_whis...@basic-queues-priority.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-glk3/igt@gem_exec_whis...@basic-queues-priority.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][20] -> [FAIL][21] ([i915#307]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy-xy.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][22] ([i915#2658]) [22]:
Re: [Intel-gfx] refactor the i915 GVT support
On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > Any updates on this? I'd really hate to miss this merge window.
> >
> > I'm still waiting for our validation team's report on this. I'm afraid
> > it might be missing for next version as i915 merge window is mostly
> > till rc5...and for any change outside of gvt, it still needs to be
> > acked by i915 maintainers.
>
> Looks our validation team did have problem against recent i915 change.
> If you like to try, we have a gvt-staging branch on
> https://github.com/intel/gvt-linux which is generated against drm-tip
> with gvt changes for testing, currently it's broken.
>
> One issue is with i915 export that intel_context_unpin has been
> changed into static inline function. Another is that intel_gvt.c
> should be part of i915 for gvt interface instead of depending on KVMGT
> config.
I'm working on below patch to resolve this. But I met a weird issue in
case when building i915 as module and also kvmgt module, it caused
busy wait on request_module("kvmgt") when boot, it doesn't happen if
building i915 into kernel. I'm not sure what could be the reason?
> But the problem I see is that after moving gvt device model (gvt/*.c
> except kvmgt.c) into kvmgt module, we'll have issue with initial mmio
> state which current gvt relies on, that is in design supposed to get
> initial HW state before i915 driver has taken any operation. Before
> we can ensure that, I think we may only remove MPT part first but
> still keep gvt device model as part of i915 with config. I'll try to
> split that out.
Sorry I misread the code that as we always request kvmgt module when
gvt init, so it should still apply original method that this isn't a
problem. Our current validation result has shown no regression as well.
---8<---
From 58ff84572f1a0f9d79ca1d7ec0cff5ecbe78d280 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang
Date: Thu, 19 Aug 2021 16:36:33 +0800
Subject: [PATCH] TESTONLY:drm/i915/gvt: potential fix for refactor against
current tip
---
drivers/gpu/drm/i915/Makefile | 4 +++-
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
drivers/gpu/drm/i915/gt/intel_context.h | 3 ++-
drivers/gpu/drm/i915/i915_trace.h | 1 +
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c4f953837f72..2248574428a1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -296,7 +296,9 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
# virtual gpu code
i915-y += i915_vgpu.o
-i915-$(CONFIG_DRM_I915_GVT_KVMGT) += intel_gvt.o
+ifneq ($(CONFIG_DRM_I915_GVT_KVMGT),)
+i915-y += intel_gvt.o
+endif
kvmgt-y += gvt/kvmgt.o \
gvt/gvt.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 745e84c72c90..20e7522fed84 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -328,6 +328,11 @@ void __intel_context_do_unpin(struct intel_context *ce,
int sub)
intel_context_put(ce);
}
+void intel_context_unpin(struct intel_context *ce)
+{
+ _intel_context_unpin(ce);
+}
+
static void __intel_context_retire(struct i915_active *active)
{
struct intel_context *ce = container_of(active, typeof(*ce), active);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index c41098950746..f942cbf6300a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -131,7 +131,7 @@ static inline void intel_context_sched_disable_unpin(struct
intel_context *ce)
__intel_context_do_unpin(ce, 2);
}
-static inline void intel_context_unpin(struct intel_context *ce)
+static inline void _intel_context_unpin(struct intel_context *ce)
{
if (!ce->ops->sched_disable) {
__intel_context_do_unpin(ce, 1);
@@ -150,6 +150,7 @@ static inline void intel_context_unpin(struct intel_context
*ce)
}
}
}
+void intel_context_unpin(struct intel_context *ce);
void intel_context_enter_engine(struct intel_context *ce);
void intel_context_exit_engine(struct intel_context *ce);
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 806ad688274b..2c6a8bcef7c1 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -17,6 +17,7 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM i915
+#undef TRACE_INCLUDE_FILE
#define TRACE_INCLUDE_FILE i915_trace
/* watermark/fifo updates */
--
2.32.0
---8<---
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH] drm/damage_helper: Fix handling of cursor dirty buffers
On Wed, Aug 18, 2021 at 04:44:44PM +, Souza, Jose wrote:
> On Wed, 2021-08-18 at 11:54 +0200, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote:
> > > Cursors don't have a framebuffer so the fb comparisson was always
> > > failing and atomic state was being committed without any plane state.
> > >
> > > So here checking if objects match when checking cursors.
> >
> > This looks extremely backwards ... what exactly is this fixing? If this
> > isn't based on a real world compositor usage but some igt, then I'd say
> > the igt here is very wrong.
>
> Yes it is IGT.
> Writing to cursor buffer current in the screen and calling
> drmModeDirtyFB() causes a empty atomic commit by
> drm_atomic_helper_dirtyfb().
Ok if the cursor write is done through legacy cursor uapi then trying to
make that work with dirtyfb doesn't make sense.
But you've found a bug at least, namely the empty commit. I think that
should be filtered out, and our dirtyfb testcases (I hope we have some
vendor-agnostic kms_dirtyfb already) should be extended with a testcase
where we call dirtyfb on an fb which is not currently used anywhere.
Wrt the cursor: The legacy cursor ioctls get remapped onto the cursor
plane, which means they come in as full commits. So there's really not
dirtyfb required afterwards. The funny thing about the cursor ioctls is
that they never supported frontbuffer rendering. You _always_ had to call
them to upload data. So the test is invalid from a functional pov too.
-Daniel
>
>
> > -Daniel
> >
> > > Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
> > > Cc: Daniel Vetter
> > > Cc: Rob Clark
> > > Cc: Deepak Rawat
> > > Cc: Gwan-gyeong Mun
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/drm_damage_helper.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_damage_helper.c
> > > b/drivers/gpu/drm/drm_damage_helper.c
> > > index 8eeff0c7bdd47..595187d97c131 100644
> > > --- a/drivers/gpu/drm/drm_damage_helper.c
> > > +++ b/drivers/gpu/drm/drm_damage_helper.c
> > > @@ -157,12 +157,18 @@ int drm_atomic_helper_dirtyfb(struct
> > > drm_framebuffer *fb,
> > > retry:
> > > drm_for_each_plane(plane, fb->dev) {
> > > struct drm_plane_state *plane_state;
> > > + bool match;
> > >
> > > ret = drm_modeset_lock(>mutex, state->acquire_ctx);
> > > if (ret)
> > > goto out;
> > >
> > > - if (plane->state->fb != fb) {
> > > + match = plane->state->fb == fb;
> > > + /* Check if objs match to handle dirty buffers of cursors */
> > > + if (plane->type == DRM_PLANE_TYPE_CURSOR && plane->state->fb)
> > > + match |= fb->obj[0] == plane->state->fb->obj[0];
> > > +
> > > + if (!match) {
> > > drm_modeset_unlock(>mutex);
> > > continue;
> > > }
> > > --
> > > 2.32.0
> > >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure
On Wed, Aug 18, 2021 at 09:12:32PM +0200, Michal Wajdeczko wrote: > > > On 18.08.2021 18:35, Daniel Vetter wrote: > > On Wed, Aug 18, 2021 at 5:11 PM Michal Wajdeczko > > wrote: > >> > >> > >> > >> On 18.08.2021 16:20, Daniel Vetter wrote: > >>> On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote: > Instead of plain error value (%d) print more user friendly error > name (%pe). > > Signed-off-by: Michal Wajdeczko > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > index a26bb55c0898..18d52c39f0c2 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > @@ -167,8 +167,8 @@ static int ct_register_buffer(struct intel_guc_ct > *ct, u32 type, > err = guc_action_register_ct_buffer(ct_to_guc(ct), type, > desc_addr, buff_addr, size); > if (unlikely(err)) > -CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n", > - guc_ct_buffer_type_to_str(type), err); > +CT_ERROR(ct, "Failed to register %s buffer (%pe)\n", > + guc_ct_buffer_type_to_str(type), ERR_PTR(err)); > >>> > >>> errname() is what you want here, not this convoluted jumping through hoops > >>> to fake an error pointer. > >> > >> nope, I was already trying that shortcut, but errname() is not exported > >> so we fail with > >> > >> ERROR: modpost: "errname" [drivers/gpu/drm/i915/i915.ko] undefined! > >> > >> so unless we add that export we must follow initial approach [1] > > > > Then we export that function. This is all open source, we can actually > > fix things up, there should _never_ be a need to hack around things > > like this. > > simple export might be not sufficient, as this function returns NULL for > unrecognized error codes, and it might be hard to print that code in > plain format, as it %pe does it for us for free. "(%s:%i)", errname(ret), ret Would work, but maybe not so pretty. Otoh %pe for unrecognized integers is also not very pretty. > is that big problem to use ERR_PTR? I'm not the only/first one > > see > drivers/net/can/usb/etas_es58x/es58x_core.c > drivers/net/ethernet/freescale/enetc/enetc_pf.c > drivers/net/phy/phylink.c > ... Ah yeah, looking through grep more than half the users do this pattern. Which still feels extremely silly, because it's not a pointer we're printing, and when it's not an errno we should probably print it as an integer or something. But also meh. On both patches, as-is: Reviewed-by: Daniel Vetter > > And yes I'm keenly aware that there's a pile of i915-gem code which > > outright flaunts this principle, but that doesn't mean we should > > continue with that. scripts/get_maintainers.pl can help with finding > > all the people you need to cc on that export patch. > > I'm perfectly fine with updating/fixing shared code (did that before, > have few more ideas on my todo-list) but in this case I'm not so sure I think an %ie extension or something like that for printk would make some sense. There's absolute enormous amounts of this kind of casting going on, and it just doesn't make sense to me. It would be pretty easy way to get like 100 patches into the kernel to clean it all up :-) -Daniel > > -Michal > > > -Daniel > > > >> > >> -Michal > >> > >> [1] > >> https://cgit.freedesktop.org/drm/drm-tip/commit/?id=57f5677e535ba24b8926a7125be2ef8d7f09323c > >> > >>> > >>> With that: Reviewed-by: Daniel Vetter > return err; > } > > @@ -195,8 +195,8 @@ static int ct_deregister_buffer(struct intel_guc_ct > *ct, u32 type) > int err = guc_action_deregister_ct_buffer(ct_to_guc(ct), type); > > if (unlikely(err)) > -CT_ERROR(ct, "Failed to deregister %s buffer (err=%d)\n", > - guc_ct_buffer_type_to_str(type), err); > +CT_ERROR(ct, "Failed to deregister %s buffer (%pe)\n", > + guc_ct_buffer_type_to_str(type), ERR_PTR(err)); > return err; > } > > -- > 2.25.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >>> > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] drm/i915/ttm: ensure we release the intel_memory_region
On Thu, 19 Aug 2021 at 08:25, Thomas Hellström wrote: > > On Wed, 2021-08-18 at 18:12 +0100, Matthew Auld wrote: > > If the ttm_bo_init_reserved() call fails ensure we also release the > > region, otherwise we leak the reference, or worse hit some uaf, when > > we > > start using the objects.list. Also remove the make_unshrinkable call > > here, which doesn't do anything. > > > > Signed-off-by: Matthew Auld > > Cc: Thomas Hellström > > --- > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 7 +-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > index 771eb2963123..2e8cdcd5e4f7 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > @@ -909,7 +909,6 @@ int __i915_gem_ttm_object_init(struct > > intel_memory_region *mem, > > drm_gem_private_object_init(>drm, >base, size); > > i915_gem_object_init(obj, _gem_ttm_obj_ops, _class, > > flags); > > i915_gem_object_init_memory_region(obj, mem); > > - i915_gem_object_make_unshrinkable(obj); > > INIT_RADIX_TREE(>ttm.get_io_page.radix, GFP_KERNEL | > > __GFP_NOWARN); > > mutex_init(>ttm.get_io_page.lock); > > bo_type = (obj->flags & I915_BO_ALLOC_USER) ? > > ttm_bo_type_device : > > @@ -932,7 +931,7 @@ int __i915_gem_ttm_object_init(struct > > intel_memory_region *mem, > >page_size >> PAGE_SHIFT, > >, NULL, NULL, > > i915_ttm_bo_destroy); > > if (ret) > > - return i915_ttm_err_to_gem(ret); > > + goto err_release_mr; > > IIRC when ttm_object_init_reserved fails, it will call ttm_bo_put() > which will eventually end up in i915_ttm_bo_destroy() which will do the > right thing? Ah right, missed that. > > /Thomas > >
[Intel-gfx] ✓ Fi.CI.BAT: success for Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
URL : https://patchwork.freedesktop.org/series/93704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10498 -> Patchwork_20851
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/index.html
New tests
-
New tests have been introduced between CI_DRM_10498 and Patchwork_20851:
### New IGT tests (1) ###
* igt@i915_selftest@live@guc:
- Statuses : 29 pass(s)
- Exec time: [0.41, 5.16] s
Known issues
Here are the changes found in Patchwork_20851 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-soraka: [PASS][1] -> [FAIL][2] ([i915#2346])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-kbl-soraka/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/fi-kbl-soraka/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][3] ([i915#1602] / [i915#2029])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-1115g4: [DMESG-WARN][4] -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-1115g4/igt@i915_module_l...@reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/fi-tgl-1115g4/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gtt:
- {fi-tgl-dsi}: [DMESG-WARN][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-dsi/igt@i915_selftest@l...@gtt.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/fi-tgl-dsi/igt@i915_selftest@l...@gtt.html
* igt@i915_selftest@live@perf:
- {fi-tgl-dsi}: [DMESG-WARN][8] ([i915#2867]) -> [PASS][9] +6 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10498/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20851/fi-tgl-dsi/igt@i915_selftest@l...@perf.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
Participating hosts (35 -> 34)
--
Missing(1): fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_10498 -> Patchwork_20851
CI-20190529: 20190529
CI_DRM_10498: b66f2ed13db3f8f7bcf616cea0e59ebe8728b131 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6178: 146260200f9a6d4536e48a195e2ab49a07d4f0c1 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20851: 516f3fcdd0dda3d21d60a2644a099d50d7933835 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
516f3fcdd0dd drm/i915/guc: Drop static inline functions intel_guc_submission.c
16fdda30af6b drm/i915/guc: Add GuC kernel doc
a0ff703dedb1 drm/i915/guc: Drop guc_active move everything into guc_state
0e84142a2b56 drm/i915/guc: Move fields protected by guc->contexts_lock into sub
structure
9b10873534b2 drm/i915/guc: Move GuC priority fields in context under guc_active
2fd6d9d96159 drm/i915/guc: Drop pin count check trick between sched_disable and
re-pin
3bf483be619f drm/i915/guc: Proper xarray usage for contexts_lookup
c8b2f80e4529 drm/i915/guc: Rework and simplify locking
1debca6b1bd8 drm/i915/guc: Move guc_blocked fence to struct guc_state
f7a536406581 drm/i915/guc: Release submit fence from an irq_work
8081613c600f drm/i915/guc: Flush G2H work queue during reset
f739dd54a7ee drm/i915: Allocate error capture in nowait context
23d73efe3398 drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
fe52b71dec8a drm/i915/guc: Don't touch guc_state.sched_state without a lock
95c83c9a3e05 drm/i915/guc: Take context ref when cancelling request
24f6154536c7 drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
c328800aa348 drm/i915/selftests: Fix memory corruption in live_lrc_isolation
be92b59039f4 drm/i915/guc: Don't enable scheduling on a banned context, guc_id
invalid, not registered
72e6f5ea745f drm/i915/guc: Kick tasklet after queuing a request
b13cbbf2cc00 drm/i915/selftests: Add a cancel request selftest that triggers a
reset
7cc5849adb41 Revert "drm/i915/gt: Propagate change in error status to children
on unhold"
54c8cf84e527 drm/i915/guc: Workaround reset G2H is received after
Re: [Intel-gfx] [PATCH 2/2] drm/i915/debugfs: hook up ttm_resource_manager_debug
On Wed, 2021-08-18 at 15:58 +0100, Matthew Auld wrote:
> This should give a more complete view of the various bits of internal
> resource manager state, for device local-memory.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index eec0d349ea6a..109e6feed6be 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -238,6 +238,7 @@ i915_debugfs_describe_obj(struct seq_file *m,
> struct drm_i915_gem_object *obj)
> static int i915_gem_object_info(struct seq_file *m, void *data)
> {
> struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct drm_printer p = drm_seq_file_printer(m);
> struct intel_memory_region *mr;
> enum intel_region_id id;
>
> @@ -245,9 +246,14 @@ static int i915_gem_object_info(struct seq_file
> *m, void *data)
> i915->mm.shrink_count,
> atomic_read(>mm.free_count),
> i915->mm.shrink_memory);
> - for_each_memory_region(mr, i915, id)
> - seq_printf(m, "%s: total:%pa, available:%pa bytes\n",
> - mr->name, >total, >avail);
> + for_each_memory_region(mr, i915, id) {
> + seq_printf(m, "%s: ", mr->name);
> + if (mr->region_private)
> + ttm_resource_manager_debug(mr-
> >region_private, );
> + else
> + seq_printf(m, "total:%pa, available:%pa
> bytes\n",
> + >total, >avail);
Hm. Shouldn't we make the above intel_memory_region_debug() or perhaps
intel_memory_region_info() to avoid using memory region internals
directly here?
/Thomas
Re: [Intel-gfx] [PATCH] drm/i915/ttm: ensure we release the intel_memory_region
On Wed, 2021-08-18 at 18:12 +0100, Matthew Auld wrote: > If the ttm_bo_init_reserved() call fails ensure we also release the > region, otherwise we leak the reference, or worse hit some uaf, when > we > start using the objects.list. Also remove the make_unshrinkable call > here, which doesn't do anything. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > index 771eb2963123..2e8cdcd5e4f7 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > @@ -909,7 +909,6 @@ int __i915_gem_ttm_object_init(struct > intel_memory_region *mem, > drm_gem_private_object_init(>drm, >base, size); > i915_gem_object_init(obj, _gem_ttm_obj_ops, _class, > flags); > i915_gem_object_init_memory_region(obj, mem); > - i915_gem_object_make_unshrinkable(obj); > INIT_RADIX_TREE(>ttm.get_io_page.radix, GFP_KERNEL | > __GFP_NOWARN); > mutex_init(>ttm.get_io_page.lock); > bo_type = (obj->flags & I915_BO_ALLOC_USER) ? > ttm_bo_type_device : > @@ -932,7 +931,7 @@ int __i915_gem_ttm_object_init(struct > intel_memory_region *mem, > page_size >> PAGE_SHIFT, > , NULL, NULL, > i915_ttm_bo_destroy); > if (ret) > - return i915_ttm_err_to_gem(ret); > + goto err_release_mr; IIRC when ttm_object_init_reserved fails, it will call ttm_bo_put() which will eventually end up in i915_ttm_bo_destroy() which will do the right thing? /Thomas
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
== Series Details == Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3) URL : https://patchwork.freedesktop.org/series/93704/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/display/intel_display.c:1901:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1901:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1901:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34:expected struct i915_address_space *vm +drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34:got struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/i915_gem_context.c:1374:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:expected struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25:got struct i915_address_space * +drivers/gpu/drm/i915/gem/selftests/mock_context.c:43:25: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:expected struct i915_address_space *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34:got struct i915_address_space [noderef] __rcu *vm +drivers/gpu/drm/i915/gem/selftests/mock_context.c:60:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1268:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev3)
URL : https://patchwork.freedesktop.org/series/93704/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cdd86549dd1d drm/i915/guc: Fix blocked context accounting
de712a42478e drm/i915/guc: Fix outstanding G2H accounting
75fb55198651 drm/i915/guc: Unwind context requests in reverse order
ef46dfb56828 drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
c2e59d2d1528 drm/i915/guc: Process all G2H message at once in work queue
54c8cf84e527 drm/i915/guc: Workaround reset G2H is received after schedule done
G2H
-:7: WARNING:TYPO_SPELLING: 'cancelation' may be misspelled - perhaps
'cancellation'?
#7:
If the context is reset as a result of the request cancelation the
^^^
-:10: WARNING:TYPO_SPELLING: 'cancelation' may be misspelled - perhaps
'cancellation'?
#10:
waiting request cancelation code which resubmits the context. This races
^^^
-:12: WARNING:TYPO_SPELLING: 'cancelation' may be misspelled - perhaps
'cancellation'?
#12:
in this case it really should be a NOP as request cancelation code owns
^^^
-:58: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#58: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:856:
+ if (likely(!context_pending_enable(ce))) {
[...]
+ } else {
[...]
total: 0 errors, 4 warnings, 0 checks, 73 lines checked
7cc5849adb41 Revert "drm/i915/gt: Propagate change in error status to children
on unhold"
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
References: 3761baae908a (Revert "drm/i915: Propagate errors on awaiting
already signaled fences")
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 3761baae908a ("Revert "drm/i915:
Propagate errors on awaiting already signaled fences"")'
#17:
References: 3761baae908a (Revert "drm/i915: Propagate errors on awaiting
already signaled fences")
total: 1 errors, 1 warnings, 0 checks, 10 lines checked
b13cbbf2cc00 drm/i915/selftests: Add a cancel request selftest that triggers a
reset
72e6f5ea745f drm/i915/guc: Kick tasklet after queuing a request
-:8: WARNING:TYPO_SPELLING: 'inteface' may be misspelled - perhaps 'interface'?
#8:
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
total: 0 errors, 1 warnings, 0 checks, 7 lines checked
be92b59039f4 drm/i915/guc: Don't enable scheduling on a banned context, guc_id
invalid, not registered
c328800aa348 drm/i915/selftests: Fix memory corruption in live_lrc_isolation
24f6154536c7 drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
-:104: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#104:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 232 lines checked
95c83c9a3e05 drm/i915/guc: Take context ref when cancelling request
fe52b71dec8a drm/i915/guc: Don't touch guc_state.sched_state without a lock
23d73efe3398 drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
f739dd54a7ee drm/i915: Allocate error capture in nowait context
8081613c600f drm/i915/guc: Flush G2H work queue during reset
f7a536406581 drm/i915/guc: Release submit fence from an irq_work
1debca6b1bd8 drm/i915/guc: Move guc_blocked fence to struct guc_state
c8b2f80e4529 drm/i915/guc: Rework and simplify locking
3bf483be619f drm/i915/guc: Proper xarray usage for contexts_lookup
2fd6d9d96159 drm/i915/guc: Drop pin count check trick between sched_disable and
re-pin
9b10873534b2 drm/i915/guc: Move GuC priority fields in context under guc_active
0e84142a2b56 drm/i915/guc: Move fields protected by guc->contexts_lock into sub
structure
a0ff703dedb1 drm/i915/guc: Drop guc_active move everything into guc_state
16fdda30af6b drm/i915/guc: Add GuC kernel doc
516f3fcdd0dd drm/i915/guc: Drop static inline functions intel_guc_submission.c
Re: [Intel-gfx] [PATCH 1/2] drm/i915/buddy: add some pretty printing
On Wed, 2021-08-18 at 15:58 +0100, Matthew Auld wrote:
> Implement the debug hook for the buddy resource manager. For this we
> want to print out the status of the memory manager, including how much
> memory is still allocatable, what page sizes we have etc. This will be
> triggered when TTM is unable to fulfil an allocation request for device
> local-memory.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/i915_buddy.c | 45 +++
> drivers/gpu/drm/i915/i915_buddy.h | 8
> drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 20 -
> 3 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_buddy.c
> b/drivers/gpu/drm/i915/i915_buddy.c
> index 7b274c51cac0..240e881d9eb0 100644
> --- a/drivers/gpu/drm/i915/i915_buddy.c
> +++ b/drivers/gpu/drm/i915/i915_buddy.c
> @@ -4,6 +4,7 @@
> */
>
> #include
> +#include
>
> #include "i915_buddy.h"
>
> @@ -82,6 +83,7 @@ int i915_buddy_init(struct i915_buddy_mm *mm, u64
> size, u64 chunk_size)
> size = round_down(size, chunk_size);
>
> mm->size = size;
> + mm->avail = size;
> mm->chunk_size = chunk_size;
> mm->max_order = ilog2(size) - ilog2(chunk_size);
>
> @@ -155,6 +157,8 @@ void i915_buddy_fini(struct i915_buddy_mm *mm)
> i915_block_free(mm, mm->roots[i]);
> }
>
> + GEM_WARN_ON(mm->avail != mm->size);
> +
> kfree(mm->roots);
> kfree(mm->free_list);
> }
> @@ -230,6 +234,7 @@ void i915_buddy_free(struct i915_buddy_mm *mm,
> struct i915_buddy_block *block)
> {
> GEM_BUG_ON(!i915_buddy_block_is_allocated(block));
> + mm->avail += i915_buddy_block_size(mm, block);
> __i915_buddy_free(mm, block);
> }
>
> @@ -283,6 +288,7 @@ i915_buddy_alloc(struct i915_buddy_mm *mm, unsigned
> int order)
> }
>
> mark_allocated(block);
> + mm->avail -= i915_buddy_block_size(mm, block);
> kmemleak_update_trace(block);
> return block;
>
> @@ -368,6 +374,7 @@ int i915_buddy_alloc_range(struct i915_buddy_mm
> *mm,
> }
>
> mark_allocated(block);
> + mm->avail -= i915_buddy_block_size(mm, block);
> list_add_tail(>link, );
> continue;
> }
> @@ -402,6 +409,44 @@ int i915_buddy_alloc_range(struct i915_buddy_mm
> *mm,
> return err;
> }
>
> +void i915_buddy_block_print(struct i915_buddy_mm *mm,
> + struct i915_buddy_block *block,
> + struct drm_printer *p)
> +{
> + u64 start = i915_buddy_block_offset(block);
> + u64 size = i915_buddy_block_size(mm, block);
> +
> + drm_printf(p, "%#018llx-%#018llx: %llu\n", start, start + size,
> size);
> +}
> +
> +void i915_buddy_print(struct i915_buddy_mm *mm, struct drm_printer *p)
> +{
> + int order;
> +
> + drm_printf(p, "chunk_size: %lluKB, total: %lluMB, free:
> %lluMB\n",
> + mm->chunk_size >> 10, mm->size >> 20, mm->avail >>
> 20);
> +
> + for (order = mm->max_order; order >= 0; order--) {
> + struct i915_buddy_block *block;
> + u64 count = 0, free;
> +
> + list_for_each_entry(block, >free_list[order], link)
> {
> + GEM_BUG_ON(!i915_buddy_block_is_free(block));
> + count++;
> + }
> +
> + drm_printf(p, "order-%d ", order);
> +
> + free = count * (mm->chunk_size << order);
> + if (free < SZ_1M)
> + drm_printf(p, "free: %lluKB", free >> 10);
> + else
> + drm_printf(p, "free: %lluMB", free >> 20);
Use KiB and MiB instead of KB and MB? Also below.
> +
> + drm_printf(p, ", pages: %llu\n", count);
> + }
> +}
> +
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/i915_buddy.c"
> #endif
> diff --git a/drivers/gpu/drm/i915/i915_buddy.h
> b/drivers/gpu/drm/i915/i915_buddy.h
> index 3940d632f208..7077742112ac 100644
> --- a/drivers/gpu/drm/i915/i915_buddy.h
> +++ b/drivers/gpu/drm/i915/i915_buddy.h
> @@ -10,6 +10,8 @@
> #include
> #include
>
> +#include
> +
> struct i915_buddy_block {
> #define I915_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
> #define I915_BUDDY_HEADER_STATE GENMASK_ULL(11, 10)
> @@ -69,6 +71,7 @@ struct i915_buddy_mm {
> /* Must be at least PAGE_SIZE */
> u64 chunk_size;
> u64 size;
> + u64 avail;
> };
>
> static inline u64
> @@ -129,6 +132,11 @@ void i915_buddy_free(struct i915_buddy_mm *mm,
> struct i915_buddy_block *block);
>
> void i915_buddy_free_list(struct i915_buddy_mm *mm, struct list_head
> *objects);
>
> +void i915_buddy_print(struct i915_buddy_mm *mm, struct drm_printer
> *p);
> +void
[Intel-gfx] [PATCH 27/27] drm/i915/guc: Drop static inline functions intel_guc_submission.c
s/static inline/static/g + fix function argument alignment to make
checkpatch happy.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 116 +-
1 file changed, 57 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 7e0a32e729c2..ad4420100908 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -139,7 +139,7 @@ guc_create_virtual(struct intel_engine_cs **siblings,
unsigned int count);
#define SCHED_STATE_BLOCKED_SHIFT 7
#define SCHED_STATE_BLOCKEDBIT(SCHED_STATE_BLOCKED_SHIFT)
#define SCHED_STATE_BLOCKED_MASK (0xfff << SCHED_STATE_BLOCKED_SHIFT)
-static inline void init_sched_state(struct intel_context *ce)
+static void init_sched_state(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
@@ -156,14 +156,14 @@ static bool sched_state_is_init(struct intel_context *ce)
~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
}
-static inline bool
+static bool
context_wait_for_deregister_to_register(struct intel_context *ce)
{
return ce->guc_state.sched_state &
SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
}
-static inline void
+static void
set_context_wait_for_deregister_to_register(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
@@ -171,7 +171,7 @@ set_context_wait_for_deregister_to_register(struct
intel_context *ce)
SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
}
-static inline void
+static void
clr_context_wait_for_deregister_to_register(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
@@ -179,111 +179,111 @@ clr_context_wait_for_deregister_to_register(struct
intel_context *ce)
~SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
}
-static inline bool
+static bool
context_destroyed(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_DESTROYED;
}
-static inline void
+static void
set_context_destroyed(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
}
-static inline bool context_pending_disable(struct intel_context *ce)
+static bool context_pending_disable(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
}
-static inline void set_context_pending_disable(struct intel_context *ce)
+static void set_context_pending_disable(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_PENDING_DISABLE;
}
-static inline void clr_context_pending_disable(struct intel_context *ce)
+static void clr_context_pending_disable(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state &= ~SCHED_STATE_PENDING_DISABLE;
}
-static inline bool context_banned(struct intel_context *ce)
+static bool context_banned(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_BANNED;
}
-static inline void set_context_banned(struct intel_context *ce)
+static void set_context_banned(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_BANNED;
}
-static inline void clr_context_banned(struct intel_context *ce)
+static void clr_context_banned(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state &= ~SCHED_STATE_BANNED;
}
-static inline bool context_enabled(struct intel_context *ce)
+static bool context_enabled(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_ENABLED;
}
-static inline void set_context_enabled(struct intel_context *ce)
+static void set_context_enabled(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_ENABLED;
}
-static inline void clr_context_enabled(struct intel_context *ce)
+static void clr_context_enabled(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state &= ~SCHED_STATE_ENABLED;
}
-static inline bool context_pending_enable(struct intel_context *ce)
+static bool context_pending_enable(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_PENDING_ENABLE;
}
-static inline void set_context_pending_enable(struct intel_context *ce)
+static void set_context_pending_enable(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |= SCHED_STATE_PENDING_ENABLE;
}
-static inline void clr_context_pending_enable(struct intel_context *ce)
+static void
[Intel-gfx] [PATCH 25/27] drm/i915/guc: Drop guc_active move everything into guc_state
Now that we have locking hierarchy of sched_engine->lock ->
ce->guc_state everything from guc_active can be moved into guc_state and
protected the guc_state.lock.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 10 +--
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 88 +--
drivers/gpu/drm/i915/i915_trace.h | 2 +-
4 files changed, 49 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 87b84c1d5393..adfe49b53b1b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -394,9 +394,7 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(>guc_state.lock);
INIT_LIST_HEAD(>guc_state.fences);
-
- spin_lock_init(>guc_active.lock);
- INIT_LIST_HEAD(>guc_active.requests);
+ INIT_LIST_HEAD(>guc_state.requests);
ce->guc_id.id = GUC_INVALID_LRC_ID;
INIT_LIST_HEAD(>guc_id.link);
@@ -521,15 +519,15 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
- spin_lock_irqsave(>guc_active.lock, flags);
- list_for_each_entry_reverse(rq, >guc_active.requests,
+ spin_lock_irqsave(>guc_state.lock, flags);
+ list_for_each_entry_reverse(rq, >guc_state.requests,
sched.link) {
if (i915_request_completed(rq))
break;
active = rq;
}
- spin_unlock_irqrestore(>guc_active.lock, flags);
+ spin_unlock_irqrestore(>guc_state.lock, flags);
return active;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 7a1d1537cf67..66286ce36c84 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -172,11 +172,6 @@ struct intel_context {
struct i915_sw_fence blocked_fence;
/* GuC committed requests */
int number_committed_requests;
- } guc_state;
-
- struct {
- /** lock: protects everything in guc_active */
- spinlock_t lock;
/** requests: active requests on this context */
struct list_head requests;
/*
@@ -184,7 +179,7 @@ struct intel_context {
*/
u8 prio;
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
- } guc_active;
+ } guc_state;
struct {
/* GuC LRC descriptor ID */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index c4c018348ac0..4b9a2f3774d5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -827,9 +827,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
unsigned long flags;
spin_lock_irqsave(_engine->lock, flags);
- spin_lock(>guc_active.lock);
+ spin_lock(>guc_state.lock);
list_for_each_entry_safe_reverse(rq, rn,
->guc_active.requests,
+>guc_state.requests,
sched.link) {
if (i915_request_completed(rq))
continue;
@@ -848,7 +848,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
- spin_unlock(>guc_active.lock);
+ spin_unlock(>guc_state.lock);
spin_unlock_irqrestore(_engine->lock, flags);
}
@@ -945,10 +945,10 @@ static void guc_cancel_context_requests(struct
intel_context *ce)
/* Mark all executing requests as skipped. */
spin_lock_irqsave(_engine->lock, flags);
- spin_lock(>guc_active.lock);
- list_for_each_entry(rq, >guc_active.requests, sched.link)
+ spin_lock(>guc_state.lock);
+ list_for_each_entry(rq, >guc_state.requests, sched.link)
i915_request_put(i915_request_mark_eio(rq));
- spin_unlock(>guc_active.lock);
+ spin_unlock(>guc_state.lock);
spin_unlock_irqrestore(_engine->lock, flags);
}
@@ -1400,7 +1400,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->engine_submit_mask = adjust_engine_mask(engine->class,
engine->mask);
desc->hw_context_desc = ce->lrc.lrca;
- desc->priority = ce->guc_active.prio;
+ desc->priority = ce->guc_state.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
guc_context_policy_init(engine, desc);
@@ -1802,10 +1802,10
[Intel-gfx] [PATCH 22/27] drm/i915/guc: Drop pin count check trick between sched_disable and re-pin
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 49 ---
2 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d5d643b04d54..524a35a78bf4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -169,6 +169,8 @@ struct intel_context {
struct list_head fences;
/* GuC context blocked fence */
struct i915_sw_fence blocked_fence;
+ /* GuC committed requests */
+ int number_committed_requests;
} guc_state;
struct {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 5f77f25322ca..3e90985b0c1b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -248,6 +248,25 @@ static inline void decr_context_blocked(struct
intel_context *ce)
ce->guc_state.sched_state -= SCHED_STATE_BLOCKED;
}
+static inline bool context_has_committed_requests(struct intel_context *ce)
+{
+ return !!ce->guc_state.number_committed_requests;
+}
+
+static inline void incr_context_committed_requests(struct intel_context *ce)
+{
+ lockdep_assert_held(>guc_state.lock);
+ ++ce->guc_state.number_committed_requests;
+ GEM_BUG_ON(ce->guc_state.number_committed_requests < 0);
+}
+
+static inline void decr_context_committed_requests(struct intel_context *ce)
+{
+ lockdep_assert_held(>guc_state.lock);
+ --ce->guc_state.number_committed_requests;
+ GEM_BUG_ON(ce->guc_state.number_committed_requests < 0);
+}
+
static inline bool context_guc_id_invalid(struct intel_context *ce)
{
return ce->guc_id == GUC_INVALID_LRC_ID;
@@ -1751,14 +1770,11 @@ static void guc_context_sched_disable(struct
intel_context *ce)
spin_lock_irqsave(>guc_state.lock, flags);
/*
-* We have to check if the context has been disabled by another thread.
-* We also have to check if the context has been pinned again as another
-* pin operation is allowed to pass this function. Checking the pin
-* count, within ce->guc_state.lock, synchronizes this function with
-* guc_request_alloc ensuring a request doesn't slip through the
-* 'context_pending_disable' fence. Checking within the spin lock (can't
-* sleep) ensures another process doesn't pin this context and generate
-* a request before we set the 'context_pending_disable' flag here.
+* We have to check if the context has been disabled by another thread,
+* check if submssion has been disabled to seal a race with reset and
+* finally check if any more requests have been committed to the
+* context ensursing that a request doesn't slip through the
+* 'context_pending_disable' fence.
*/
enabled = context_enabled(ce);
if (unlikely(!enabled || submission_disabled(guc))) {
@@ -1767,7 +1783,8 @@ static void guc_context_sched_disable(struct
intel_context *ce)
spin_unlock_irqrestore(>guc_state.lock, flags);
goto unpin;
}
- if (unlikely(atomic_add_unless(>pin_count, -2, 2))) {
+ if (unlikely(context_has_committed_requests(ce))) {
+ intel_context_sched_disable_unpin(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
return;
}
@@ -1800,6 +1817,7 @@ static void __guc_context_destroy(struct intel_context
*ce)
ce->guc_prio_count[GUC_CLIENT_PRIORITY_HIGH] ||
ce->guc_prio_count[GUC_CLIENT_PRIORITY_KMD_NORMAL] ||
ce->guc_prio_count[GUC_CLIENT_PRIORITY_NORMAL]);
+ GEM_BUG_ON(ce->guc_state.number_committed_requests);
lrc_fini(ce);
intel_context_fini(ce);
@@ -2030,6 +2048,10 @@ static void remove_from_context(struct i915_request *rq)
spin_unlock_irq(>guc_active.lock);
+ spin_lock_irq(>guc_state.lock);
+ decr_context_committed_requests(ce);
+ spin_unlock_irq(>guc_state.lock);
+
atomic_dec(>guc_id_ref);
i915_request_notify_execute_cb_imm(rq);
}
@@ -2177,15 +2199,7 @@ static int guc_request_alloc(struct i915_request *rq)
* schedule enable or context registration if either G2H is pending
* respectfully. Once a G2H returns, the fence is released that is
* blocking these requests (see guc_signal_context_fence).
-*
-* We can safely check the below fields outside of the lock as it isn't
-*
[Intel-gfx] [PATCH 20/27] drm/i915/guc: Rework and simplify locking
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_engine.lock -> guc_state.lock.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 186 --
drivers/gpu/drm/i915/i915_trace.h | 6 +-
3 files changed, 89 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index c06171ee8792..d5d643b04d54 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -161,7 +161,7 @@ struct intel_context {
* sched_state: scheduling state of this context using GuC
* submission
*/
- u16 sched_state;
+ u32 sched_state;
/*
* fences: maintains of list of requests that have a submit
* fence related to GuC submission
@@ -178,9 +178,6 @@ struct intel_context {
struct list_head requests;
} guc_active;
- /* GuC scheduling state flags that do not require a lock. */
- atomic_t guc_sched_state_no_lock;
-
/* GuC LRC descriptor ID */
u16 guc_id;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 053f4485d6e9..509b298e7cf3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -72,86 +72,23 @@ guc_create_virtual(struct intel_engine_cs **siblings,
unsigned int count);
#define GUC_REQUEST_SIZE 64 /* bytes */
-/*
- * Below is a set of functions which control the GuC scheduling state which do
- * not require a lock as all state transitions are mutually exclusive. i.e. It
- * is not possible for the context pinning code and submission, for the same
- * context, to be executing simultaneously. We still need an atomic as it is
- * possible for some of the bits to changing at the same time though.
- */
-#define SCHED_STATE_NO_LOCK_ENABLEDBIT(0)
-#define SCHED_STATE_NO_LOCK_PENDING_ENABLE BIT(1)
-#define SCHED_STATE_NO_LOCK_REGISTERED BIT(2)
-static inline bool context_enabled(struct intel_context *ce)
-{
- return (atomic_read(>guc_sched_state_no_lock) &
- SCHED_STATE_NO_LOCK_ENABLED);
-}
-
-static inline void set_context_enabled(struct intel_context *ce)
-{
- atomic_or(SCHED_STATE_NO_LOCK_ENABLED, >guc_sched_state_no_lock);
-}
-
-static inline void clr_context_enabled(struct intel_context *ce)
-{
- atomic_and((u32)~SCHED_STATE_NO_LOCK_ENABLED,
- >guc_sched_state_no_lock);
-}
-
-static inline bool context_pending_enable(struct intel_context *ce)
-{
- return (atomic_read(>guc_sched_state_no_lock) &
- SCHED_STATE_NO_LOCK_PENDING_ENABLE);
-}
-
-static inline void set_context_pending_enable(struct intel_context *ce)
-{
- atomic_or(SCHED_STATE_NO_LOCK_PENDING_ENABLE,
- >guc_sched_state_no_lock);
-}
-
-static inline void clr_context_pending_enable(struct intel_context *ce)
-{
- atomic_and((u32)~SCHED_STATE_NO_LOCK_PENDING_ENABLE,
- >guc_sched_state_no_lock);
-}
-
-static inline bool context_registered(struct intel_context *ce)
-{
- return (atomic_read(>guc_sched_state_no_lock) &
- SCHED_STATE_NO_LOCK_REGISTERED);
-}
-
-static inline void set_context_registered(struct intel_context *ce)
-{
- atomic_or(SCHED_STATE_NO_LOCK_REGISTERED,
- >guc_sched_state_no_lock);
-}
-
-static inline void clr_context_registered(struct intel_context *ce)
-{
- atomic_and((u32)~SCHED_STATE_NO_LOCK_REGISTERED,
- >guc_sched_state_no_lock);
-}
-
/*
* Below is a set of functions which control the GuC scheduling state which
- * require a lock, aside from the special case where the functions are called
- * from guc_lrc_desc_pin(). In that case it isn't possible for any other code
- * path to be executing on the context.
+ * require a lock.
*/
#define SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTERBIT(0)
#define SCHED_STATE_DESTROYED BIT(1)
#define SCHED_STATE_PENDING_DISABLEBIT(2)
#define SCHED_STATE_BANNED BIT(3)
-#define SCHED_STATE_BLOCKED_SHIFT 4
+#define SCHED_STATE_ENABLEDBIT(4)
+#define SCHED_STATE_PENDING_ENABLE BIT(5)
+#define SCHED_STATE_REGISTERED BIT(6)
+#define SCHED_STATE_BLOCKED_SHIFT 7
#define SCHED_STATE_BLOCKEDBIT(SCHED_STATE_BLOCKED_SHIFT)
[Intel-gfx] [PATCH 24/27] drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure
To make ownership of locking clear move fields (guc_id, guc_id_ref,
guc_id_link) to sub structure guc_id in intel_context.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 18 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 106 +-
drivers/gpu/drm/i915/i915_trace.h | 4 +-
5 files changed, 70 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 0e48939ec85f..87b84c1d5393 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -398,8 +398,8 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(>guc_active.lock);
INIT_LIST_HEAD(>guc_active.requests);
- ce->guc_id = GUC_INVALID_LRC_ID;
- INIT_LIST_HEAD(>guc_id_link);
+ ce->guc_id.id = GUC_INVALID_LRC_ID;
+ INIT_LIST_HEAD(>guc_id.link);
/*
* Initialize fence to be complete as this is expected to be complete
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 9fb0480ccf3b..7a1d1537cf67 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -186,16 +186,18 @@ struct intel_context {
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_active;
- /* GuC LRC descriptor ID */
- u16 guc_id;
+ struct {
+ /* GuC LRC descriptor ID */
+ u16 id;
- /* GuC LRC descriptor reference count */
- atomic_t guc_id_ref;
+ /* GuC LRC descriptor reference count */
+ atomic_t ref;
- /*
-* GuC ID link - in list when unpinned but guc_id still valid in GuC
-*/
- struct list_head guc_id_link;
+ /*
+* GuC ID link - in list when unpinned but guc_id still valid
in GuC
+*/
+ struct list_head link;
+ } guc_id;
#ifdef CONFIG_DRM_I915_SELFTEST
/**
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 08f011f893b2..bf43bed905db 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -789,7 +789,7 @@ static int __igt_reset_engine(struct intel_gt *gt, bool
active)
if (err)
pr_err("[%s] Wait for request %lld:%lld
[0x%04X] failed: %d!\n",
engine->name, rq->fence.context,
- rq->fence.seqno,
rq->context->guc_id, err);
+ rq->fence.seqno,
rq->context->guc_id.id, err);
}
skip:
@@ -1098,7 +1098,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
if (err)
pr_err("[%s] Wait for request %lld:%lld
[0x%04X] failed: %d!\n",
engine->name, rq->fence.context,
- rq->fence.seqno,
rq->context->guc_id, err);
+ rq->fence.seqno,
rq->context->guc_id.id, err);
}
count++;
@@ -1108,7 +1108,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
pr_err("i915_reset_engine(%s:%s):
failed to reset request %lld:%lld [0x%04X]\n",
engine->name, test_name,
rq->fence.context,
- rq->fence.seqno,
rq->context->guc_id);
+ rq->fence.seqno,
rq->context->guc_id.id);
i915_request_put(rq);
GEM_TRACE_DUMP();
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index bb90bedb1305..c4c018348ac0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -269,12 +269,12 @@ static inline void decr_context_committed_requests(struct
intel_context *ce)
static inline bool context_guc_id_invalid(struct intel_context *ce)
{
- return ce->guc_id == GUC_INVALID_LRC_ID;
+ return ce->guc_id.id == GUC_INVALID_LRC_ID;
}
static inline void set_context_guc_id_invalid(struct intel_context *ce)
{
- ce->guc_id = GUC_INVALID_LRC_ID;
+ ce->guc_id.id = GUC_INVALID_LRC_ID;
}
static inline struct intel_guc *ce_to_guc(struct intel_context *ce)
@@ -466,14 +466,14
[Intel-gfx] [PATCH 21/27] drm/i915/guc: Proper xarray usage for contexts_lookup
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
(Daniel Vetter)
- Correct put / get accounting in xa_for_loops
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 103 +++---
1 file changed, 88 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 509b298e7cf3..5f77f25322ca 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -606,8 +606,18 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
unsigned long index, flags;
bool pending_disable, pending_enable, deregister, destroyed, banned;
+ xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
- spin_lock_irqsave(>guc_state.lock, flags);
+ /*
+* Corner case where the ref count on the object is zero but and
+* deregister G2H was lost. In this case we don't touch the ref
+* count and finish the destroy of the context.
+*/
+ bool do_put = kref_get_unless_zero(>ref);
+
+ xa_unlock(>context_lookup);
+
+ spin_lock(>guc_state.lock);
/*
* Once we are at this point submission_disabled() is guaranteed
@@ -623,7 +633,9 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
banned = context_banned(ce);
init_sched_state(ce);
- spin_unlock_irqrestore(>guc_state.lock, flags);
+ spin_unlock(>guc_state.lock);
+
+ GEM_BUG_ON(!do_put && !destroyed);
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
@@ -646,13 +658,19 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
}
intel_context_sched_disable_unpin(ce);
decr_outstanding_submission_g2h(guc);
- spin_lock_irqsave(>guc_state.lock, flags);
+
+ spin_lock(>guc_state.lock);
guc_blocked_fence_complete(ce);
- spin_unlock_irqrestore(>guc_state.lock, flags);
+ spin_unlock(>guc_state.lock);
intel_context_put(ce);
}
+
+ if (do_put)
+ intel_context_put(ce);
+ xa_lock(>context_lookup);
}
+ xa_unlock_irqrestore(>context_lookup, flags);
}
static inline bool
@@ -873,16 +891,29 @@ void intel_guc_submission_reset(struct intel_guc *guc,
bool stalled)
{
struct intel_context *ce;
unsigned long index;
+ unsigned long flags;
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
return;
}
- xa_for_each(>context_lookup, index, ce)
+ xa_lock_irqsave(>context_lookup, flags);
+ xa_for_each(>context_lookup, index, ce) {
+ if (!kref_get_unless_zero(>ref))
+ continue;
+
+ xa_unlock(>context_lookup);
+
if (intel_context_is_pinned(ce))
__guc_reset_context(ce, stalled);
+ intel_context_put(ce);
+
+ xa_lock(>context_lookup);
+ }
+ xa_unlock_irqrestore(>context_lookup, flags);
+
/* GuC is blown away, drop all references to contexts */
xa_destroy(>context_lookup);
}
@@ -957,11 +988,24 @@ void intel_guc_submission_cancel_requests(struct
intel_guc *guc)
{
struct intel_context *ce;
unsigned long index;
+ unsigned long flags;
+
+ xa_lock_irqsave(>context_lookup, flags);
+ xa_for_each(>context_lookup, index, ce) {
+ if (!kref_get_unless_zero(>ref))
+ continue;
+
+ xa_unlock(>context_lookup);
- xa_for_each(>context_lookup, index, ce)
if (intel_context_is_pinned(ce))
guc_cancel_context_requests(ce);
+ intel_context_put(ce);
+
+ xa_lock(>context_lookup);
+ }
+ xa_unlock_irqrestore(>context_lookup, flags);
+
guc_cancel_sched_engine_requests(guc->sched_engine);
/* GuC is blown away, drop all references to contexts */
@@ -2850,21 +2894,28 @@ void intel_guc_find_hung_context(struct intel_engine_cs
*engine)
struct intel_context *ce;
struct i915_request *rq;
unsigned long index;
+ unsigned long flags;
/* Reset called during driver load? GuC not yet initialised! */
if (unlikely(!guc_submission_initialized(guc)))
return;
+
[Intel-gfx] [PATCH 17/27] drm/i915/guc: Flush G2H work queue during reset
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 4cf5a565f08e..9a53bae367b1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -714,8 +714,6 @@ static void guc_flush_submissions(struct intel_guc *guc)
void intel_guc_submission_reset_prepare(struct intel_guc *guc)
{
- int i;
-
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
return;
@@ -731,20 +729,8 @@ void intel_guc_submission_reset_prepare(struct intel_guc
*guc)
guc_flush_submissions(guc);
- /*
-* Handle any outstanding G2Hs before reset. Call IRQ handler directly
-* each pass as interrupt have been disabled. We always scrub for
-* outstanding G2H as it is possible for outstanding_submission_g2h to
-* be incremented after the context state update.
-*/
- for (i = 0; i < 4 && atomic_read(>outstanding_submission_g2h);
++i) {
- intel_guc_to_host_event_handler(guc);
-#define wait_for_reset(guc, wait_var) \
- intel_guc_wait_for_pending_msg(guc, wait_var, false, (HZ / 20))
- do {
- wait_for_reset(guc, >outstanding_submission_g2h);
- } while (!list_empty(>ct.requests.incoming));
- }
+ flush_work(>ct.requests.worker);
+
scrub_guc_desc_for_outstanding_g2h(guc);
}
--
2.32.0
[Intel-gfx] [PATCH 23/27] drm/i915/guc: Move GuC priority fields in context under guc_active
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
Fixes: ee242ca704d3 ("drm/i915/guc: Implement GuC priority management")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 68 +++
drivers/gpu/drm/i915/i915_trace.h | 2 +-
3 files changed, 45 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 524a35a78bf4..9fb0480ccf3b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -112,6 +112,7 @@ struct intel_context {
#define CONTEXT_FORCE_SINGLE_SUBMISSION7
#define CONTEXT_NOPREEMPT 8
#define CONTEXT_LRCA_DIRTY 9
+#define CONTEXT_GUC_INIT 10
struct {
u64 timeout_us;
@@ -178,6 +179,11 @@ struct intel_context {
spinlock_t lock;
/** requests: active requests on this context */
struct list_head requests;
+ /*
+* GuC priority management
+*/
+ u8 prio;
+ u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_active;
/* GuC LRC descriptor ID */
@@ -191,12 +197,6 @@ struct intel_context {
*/
struct list_head guc_id_link;
- /*
-* GuC priority management
-*/
- u8 guc_prio;
- u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM];
-
#ifdef CONFIG_DRM_I915_SELFTEST
/**
* @drop_schedule_enable: Force drop of schedule enable G2H for selftest
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3e90985b0c1b..bb90bedb1305 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1369,8 +1369,6 @@ static void guc_context_policy_init(struct
intel_engine_cs *engine,
desc->preemption_timeout = engine->props.preempt_timeout_ms * 1000;
}
-static inline u8 map_i915_prio_to_guc_prio(int prio);
-
static int guc_lrc_desc_pin(struct intel_context *ce, bool loop)
{
struct intel_engine_cs *engine = ce->engine;
@@ -1378,8 +1376,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
struct intel_guc *guc = >gt->uc.guc;
u32 desc_idx = ce->guc_id;
struct guc_lrc_desc *desc;
- const struct i915_gem_context *ctx;
- int prio = I915_CONTEXT_DEFAULT_PRIORITY;
bool context_registered;
intel_wakeref_t wakeref;
int ret = 0;
@@ -1396,12 +1392,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
context_registered = lrc_desc_registered(guc, desc_idx);
- rcu_read_lock();
- ctx = rcu_dereference(ce->gem_context);
- if (ctx)
- prio = ctx->sched.priority;
- rcu_read_unlock();
-
reset_lrc_desc(guc, desc_idx);
set_lrc_desc_registered(guc, desc_idx, ce);
@@ -1410,8 +1400,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->engine_submit_mask = adjust_engine_mask(engine->class,
engine->mask);
desc->hw_context_desc = ce->lrc.lrca;
- ce->guc_prio = map_i915_prio_to_guc_prio(prio);
- desc->priority = ce->guc_prio;
+ desc->priority = ce->guc_active.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
guc_context_policy_init(engine, desc);
@@ -1813,10 +1802,10 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
static void __guc_context_destroy(struct intel_context *ce)
{
- GEM_BUG_ON(ce->guc_prio_count[GUC_CLIENT_PRIORITY_KMD_HIGH] ||
- ce->guc_prio_count[GUC_CLIENT_PRIORITY_HIGH] ||
- ce->guc_prio_count[GUC_CLIENT_PRIORITY_KMD_NORMAL] ||
- ce->guc_prio_count[GUC_CLIENT_PRIORITY_NORMAL]);
+ GEM_BUG_ON(ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_KMD_HIGH] ||
+ ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_HIGH] ||
+ ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_KMD_NORMAL] ||
+ ce->guc_active.prio_count[GUC_CLIENT_PRIORITY_NORMAL]);
GEM_BUG_ON(ce->guc_state.number_committed_requests);
lrc_fini(ce);
@@ -1926,14 +1915,17 @@ static void guc_context_set_prio(struct intel_guc *guc,
GEM_BUG_ON(prio < GUC_CLIENT_PRIORITY_KMD_HIGH ||
prio > GUC_CLIENT_PRIORITY_NORMAL);
+ lockdep_assert_held(>guc_active.lock);
- if (ce->guc_prio == prio || submission_disabled(guc) ||
- !context_registered(ce))
+ if (ce->guc_active.prio == prio || submission_disabled(guc) ||
+
[Intel-gfx] [PATCH 26/27] drm/i915/guc: Add GuC kernel doc
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 44 ++---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 19 +++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 97 ++-
drivers/gpu/drm/i915/i915_request.h | 18 ++--
4 files changed, 128 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 66286ce36c84..80bbdc7810f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -156,40 +156,52 @@ struct intel_context {
u8 wa_bb_page; /* if set, page num reserved for context workarounds */
struct {
- /** lock: protects everything in guc_state */
+ /** @lock: protects everything in guc_state */
spinlock_t lock;
/**
-* sched_state: scheduling state of this context using GuC
+* @sched_state: scheduling state of this context using GuC
* submission
*/
u32 sched_state;
/*
-* fences: maintains of list of requests that have a submit
-* fence related to GuC submission
+* @fences: maintains a list of requests are currently being
+* fenced until a GuC operation completes
*/
struct list_head fences;
- /* GuC context blocked fence */
+ /**
+* @blocked_fence: fence used to signal when the blocking of a
+* contexts submissions is complete.
+*/
struct i915_sw_fence blocked_fence;
- /* GuC committed requests */
+ /** @number_committed_requests: number of committed requests */
int number_committed_requests;
- /** requests: active requests on this context */
+ /** @requests: list of active requests on this context */
struct list_head requests;
- /*
-* GuC priority management
-*/
+ /** @prio: the contexts current guc priority */
u8 prio;
+ /**
+* @prio_count: a counter of the number requests inflight in
+* each priority bucket
+*/
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
} guc_state;
struct {
- /* GuC LRC descriptor ID */
+ /**
+* @id: unique handle which is used to communicate information
+* with the GuC about this context, protected by
+* guc->contexts_lock
+*/
u16 id;
-
- /* GuC LRC descriptor reference count */
+ /**
+* @ref: the number of references to the guc_id, when
+* transitioning in and out of zero protected by
+* guc->contexts_lock
+*/
atomic_t ref;
-
- /*
-* GuC ID link - in list when unpinned but guc_id still valid
in GuC
+ /**
+* @link: in guc->guc_id_list when the guc_id has no refs but is
+* still valid, protected by guc->contexts_lock
*/
struct list_head link;
} guc_id;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 2e27fe59786b..112dd29a63fe 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -41,6 +41,10 @@ struct intel_guc {
spinlock_t irq_lock;
unsigned int msg_enabled_mask;
+ /**
+* @outstanding_submission_g2h: number of outstanding G2H related to GuC
+* submission, used to determine if the GT is idle
+*/
atomic_t outstanding_submission_g2h;
struct {
@@ -49,12 +53,16 @@ struct intel_guc {
void (*disable)(struct intel_guc *guc);
} interrupts;
- /*
-* contexts_lock protects the pool of free guc ids and a linked list of
-* guc ids available to be stolen
+ /**
+* @contexts_lock: protects guc_ids, guc_id_list, ce->guc_id.id, and
+* ce->guc_id.ref when transitioning in and out of zero
*/
spinlock_t contexts_lock;
+ /** @guc_ids: used to allocate new guc_ids */
struct ida guc_ids;
+ /**
+* @guc_id_list: list of intel_context with valid guc_ids but no refs
+*/
struct list_head guc_id_list;
bool submission_supported;
@@ -70,7 +78,10 @@ struct intel_guc {
struct i915_vma
[Intel-gfx] [PATCH 13/27] drm/i915/guc: Take context ref when cancelling request
A context can get destroyed after cancelling a request so take a
reference to context when cancelling a request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e0e85e4ad512..85f96d325048 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1620,8 +1620,10 @@ static void guc_context_cancel_request(struct
intel_context *ce,
struct i915_request *rq)
{
if (i915_sw_fence_signaled(>submit)) {
- struct i915_sw_fence *fence = guc_context_block(ce);
+ struct i915_sw_fence *fence;
+ intel_context_get(ce);
+ fence = guc_context_block(ce);
i915_sw_fence_wait(fence);
if (!i915_request_completed(rq)) {
__i915_request_skip(rq);
@@ -1636,6 +1638,7 @@ static void guc_context_cancel_request(struct
intel_context *ce,
flush_work(_to_guc(ce)->ct.requests.worker);
guc_context_unblock(ce);
+ intel_context_put(ce);
}
}
--
2.32.0
[Intel-gfx] [PATCH 19/27] drm/i915/guc: Move guc_blocked fence to struct guc_state
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked_fence/g
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c| 5 +++--
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 745e84c72c90..0e48939ec85f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -405,8 +405,9 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
* Initialize fence to be complete as this is expected to be complete
* unless there is a pending schedule disable outstanding.
*/
- i915_sw_fence_init(>guc_blocked, sw_fence_dummy_notify);
- i915_sw_fence_commit(>guc_blocked);
+ i915_sw_fence_init(>guc_state.blocked_fence,
+ sw_fence_dummy_notify);
+ i915_sw_fence_commit(>guc_state.blocked_fence);
i915_active_init(>active,
__intel_context_active, __intel_context_retire, 0);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 3a73f3117873..c06171ee8792 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -167,6 +167,8 @@ struct intel_context {
* fence related to GuC submission
*/
struct list_head fences;
+ /* GuC context blocked fence */
+ struct i915_sw_fence blocked_fence;
} guc_state;
struct {
@@ -190,9 +192,6 @@ struct intel_context {
*/
struct list_head guc_id_link;
- /* GuC context blocked fence */
- struct i915_sw_fence guc_blocked;
-
/*
* GuC priority management
*/
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index deb2e821e441..053f4485d6e9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1490,24 +1490,24 @@ static void guc_blocked_fence_complete(struct
intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
- if (!i915_sw_fence_done(>guc_blocked))
- i915_sw_fence_complete(>guc_blocked);
+ if (!i915_sw_fence_done(>guc_state.blocked_fence))
+ i915_sw_fence_complete(>guc_state.blocked_fence);
}
static void guc_blocked_fence_reinit(struct intel_context *ce)
{
lockdep_assert_held(>guc_state.lock);
- GEM_BUG_ON(!i915_sw_fence_done(>guc_blocked));
+ GEM_BUG_ON(!i915_sw_fence_done(>guc_state.blocked_fence));
/*
* This fence is always complete unless a pending schedule disable is
* outstanding. We arm the fence here and complete it when we receive
* the pending schedule disable complete message.
*/
- i915_sw_fence_fini(>guc_blocked);
- i915_sw_fence_reinit(>guc_blocked);
- i915_sw_fence_await(>guc_blocked);
- i915_sw_fence_commit(>guc_blocked);
+ i915_sw_fence_fini(>guc_state.blocked_fence);
+ i915_sw_fence_reinit(>guc_state.blocked_fence);
+ i915_sw_fence_await(>guc_state.blocked_fence);
+ i915_sw_fence_commit(>guc_state.blocked_fence);
}
static u16 prep_context_pending_disable(struct intel_context *ce)
@@ -1547,7 +1547,7 @@ static struct i915_sw_fence *guc_context_block(struct
intel_context *ce)
if (enabled)
clr_context_enabled(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
- return >guc_blocked;
+ return >guc_state.blocked_fence;
}
/*
@@ -1563,7 +1563,7 @@ static struct i915_sw_fence *guc_context_block(struct
intel_context *ce)
with_intel_runtime_pm(runtime_pm, wakeref)
__guc_context_sched_disable(guc, ce, guc_id);
- return >guc_blocked;
+ return >guc_state.blocked_fence;
}
static void guc_context_unblock(struct intel_context *ce)
--
2.32.0
[Intel-gfx] [PATCH 07/27] Revert "drm/i915/gt: Propagate change in error status to children on unhold"
Propagating errors to dependent fences is wrong, don't do it. A selftest in the following exposed the propagating of an error to a dependent fence after an engine reset. This reverts commit 8e9f84cf5cac248a1c6a5daa4942879c8b765058. v2: (Daniel Vetter) - Use revert References: 3761baae908a (Revert "drm/i915: Propagate errors on awaiting already signaled fences") Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index de5f9c86b9a4..cafb0608ffb4 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -2140,10 +2140,6 @@ static void __execlists_unhold(struct i915_request *rq) if (p->flags & I915_DEPENDENCY_WEAK) continue; - /* Propagate any change in error status */ - if (rq->fence.error) - i915_request_set_error_once(w, rq->fence.error); - if (w->engine != rq->engine) continue; -- 2.32.0
[Intel-gfx] [PATCH 16/27] drm/i915: Allocate error capture in nowait context
Error captures can now be done in a work queue processing G2H messages.
These messages need to be completely done being processed in the reset
path, to avoid races in the missing G2H cleanup, which create a
dependency on memory allocations and dma fences (i915_requests).
Requests depend on resets, thus now we have a circular dependency. To
work around this, allocate the error capture in a nowait context.
v2:
(Daniel Vetter)
- Use GFP_NOWAIT instead GFP_ATOMIC
Fixes: dc0dad365c5e ("Fix for error capture after full GPU reset with GuC")
Fixes: 573ba126aef3 ("Capture error state on context reset")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 39 +--
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0f08bcfbe964..2819b69fbb72 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -49,8 +49,7 @@
#include "i915_memcpy.h"
#include "i915_scatterlist.h"
-#define ALLOW_FAIL (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
-#define ATOMIC_MAYFAIL (GFP_ATOMIC | __GFP_NOWARN)
+#define ATOMIC_MAYFAIL (GFP_NOWAIT | __GFP_NOWARN)
static void __sg_set_buf(struct scatterlist *sg,
void *addr, unsigned int len, loff_t it)
@@ -79,7 +78,7 @@ static bool __i915_error_grow(struct drm_i915_error_state_buf
*e, size_t len)
if (e->cur == e->end) {
struct scatterlist *sgl;
- sgl = (typeof(sgl))__get_free_page(ALLOW_FAIL);
+ sgl = (typeof(sgl))__get_free_page(ATOMIC_MAYFAIL);
if (!sgl) {
e->err = -ENOMEM;
return false;
@@ -99,10 +98,10 @@ static bool __i915_error_grow(struct
drm_i915_error_state_buf *e, size_t len)
}
e->size = ALIGN(len + 1, SZ_64K);
- e->buf = kmalloc(e->size, ALLOW_FAIL);
+ e->buf = kmalloc(e->size, ATOMIC_MAYFAIL);
if (!e->buf) {
e->size = PAGE_ALIGN(len + 1);
- e->buf = kmalloc(e->size, GFP_KERNEL);
+ e->buf = kmalloc(e->size, ATOMIC_MAYFAIL);
}
if (!e->buf) {
e->err = -ENOMEM;
@@ -243,12 +242,12 @@ static bool compress_init(struct i915_vma_compress *c)
{
struct z_stream_s *zstream = >zstream;
- if (pool_init(>pool, ALLOW_FAIL))
+ if (pool_init(>pool, ATOMIC_MAYFAIL))
return false;
zstream->workspace =
kmalloc(zlib_deflate_workspacesize(MAX_WBITS, MAX_MEM_LEVEL),
- ALLOW_FAIL);
+ ATOMIC_MAYFAIL);
if (!zstream->workspace) {
pool_fini(>pool);
return false;
@@ -256,7 +255,7 @@ static bool compress_init(struct i915_vma_compress *c)
c->tmp = NULL;
if (i915_has_memcpy_from_wc())
- c->tmp = pool_alloc(>pool, ALLOW_FAIL);
+ c->tmp = pool_alloc(>pool, ATOMIC_MAYFAIL);
return true;
}
@@ -280,7 +279,7 @@ static void *compress_next_page(struct i915_vma_compress *c,
if (dst->page_count >= dst->num_pages)
return ERR_PTR(-ENOSPC);
- page = pool_alloc(>pool, ALLOW_FAIL);
+ page = pool_alloc(>pool, ATOMIC_MAYFAIL);
if (!page)
return ERR_PTR(-ENOMEM);
@@ -376,7 +375,7 @@ struct i915_vma_compress {
static bool compress_init(struct i915_vma_compress *c)
{
- return pool_init(>pool, ALLOW_FAIL) == 0;
+ return pool_init(>pool, ATOMIC_MAYFAIL) == 0;
}
static bool compress_start(struct i915_vma_compress *c)
@@ -391,7 +390,7 @@ static int compress_page(struct i915_vma_compress *c,
{
void *ptr;
- ptr = pool_alloc(>pool, ALLOW_FAIL);
+ ptr = pool_alloc(>pool, ATOMIC_MAYFAIL);
if (!ptr)
return -ENOMEM;
@@ -997,7 +996,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
num_pages = min_t(u64, vma->size, vma->obj->base.size) >> PAGE_SHIFT;
num_pages = DIV_ROUND_UP(10 * num_pages, 8); /* worstcase zlib growth */
- dst = kmalloc(sizeof(*dst) + num_pages * sizeof(u32 *), ALLOW_FAIL);
+ dst = kmalloc(sizeof(*dst) + num_pages * sizeof(u32 *), ATOMIC_MAYFAIL);
if (!dst)
return NULL;
@@ -1433,7 +1432,7 @@ capture_engine(struct intel_engine_cs *engine,
struct i915_request *rq = NULL;
unsigned long flags;
- ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);
+ ee = intel_engine_coredump_alloc(engine, ATOMIC_MAYFAIL);
if (!ee)
return NULL;
@@ -1481,7 +1480,7 @@ gt_record_engines(struct intel_gt_coredump *gt,
struct intel_engine_coredump *ee;
/* Refill our page pool before entering atomic section */
- pool_refill(>pool, ALLOW_FAIL);
+ pool_refill(>pool, ATOMIC_MAYFAIL);
[Intel-gfx] [PATCH 12/27] drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors dropping various G2H and then issues a full GT reset
proving that the scrubbing of these G2H doesn't blow up.
v2:
(Daniel Vetter)
- Use ifdef instead of macros for selftests
v3:
(Checkpatch)
- A space after 'switch' statement
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 18 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 126 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
.../i915/selftests/intel_scheduler_helpers.c | 12 ++
.../i915/selftests/intel_scheduler_helpers.h | 2 +
6 files changed, 184 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e54351a170e2..3a73f3117873 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -198,6 +198,24 @@ struct intel_context {
*/
u8 guc_prio;
u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM];
+
+#ifdef CONFIG_DRM_I915_SELFTEST
+ /**
+* @drop_schedule_enable: Force drop of schedule enable G2H for selftest
+*/
+ bool drop_schedule_enable;
+
+ /**
+* @drop_schedule_disable: Force drop of schedule disable G2H for
+* selftest
+*/
+ bool drop_schedule_disable;
+
+ /**
+* @drop_deregister: Force drop of deregister G2H for selftest
+*/
+ bool drop_deregister;
+#endif
};
#endif /* __INTEL_CONTEXT_TYPES__ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e53a4ef7d442..e0e85e4ad512 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2635,6 +2635,13 @@ int intel_guc_deregister_done_process_msg(struct
intel_guc *guc,
trace_intel_context_deregister_done(ce);
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (unlikely(ce->drop_deregister)) {
+ ce->drop_deregister = false;
+ return 0;
+ }
+#endif
+
if (context_wait_for_deregister_to_register(ce)) {
struct intel_runtime_pm *runtime_pm =
>engine->gt->i915->runtime_pm;
@@ -2689,10 +2696,24 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
trace_intel_context_sched_done(ce);
if (context_pending_enable(ce)) {
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (unlikely(ce->drop_schedule_enable)) {
+ ce->drop_schedule_enable = false;
+ return 0;
+ }
+#endif
+
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
bool banned;
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (unlikely(ce->drop_schedule_disable)) {
+ ce->drop_schedule_disable = false;
+ return 0;
+ }
+#endif
+
/*
* Unpin must be done before __guc_signal_context_fence,
* otherwise a race exists between the requests getting
@@ -3069,3 +3090,7 @@ bool intel_guc_virtual_engine_has_heartbeat(const struct
intel_engine_cs *ve)
return false;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_guc.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
new file mode 100644
index ..264e2f705c17
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright �� 2021 Intel Corporation
+ */
+
+#include "selftests/intel_scheduler_helpers.h"
+
+static struct i915_request *nop_user_request(struct intel_context *ce,
+struct i915_request *from)
+{
+ struct i915_request *rq;
+ int ret;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return rq;
+
+ if (from) {
+ ret = i915_sw_fence_await_dma_fence(>submit,
+ >fence, 0,
+ I915_FENCE_GFP);
+ if (ret < 0) {
+ i915_request_put(rq);
+ return ERR_PTR(ret);
+ }
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ return rq;
+}
+
+static int intel_guc_scrub_ctbs(void *arg)
+{
+ struct intel_gt *gt = arg;
+ int ret = 0;
+ int i;
+
[Intel-gfx] [PATCH 15/27] drm/i915/guc: Reset LRC descriptor if register returns -ENODEV
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index fa87470ea576..4cf5a565f08e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1407,10 +1407,12 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
} else {
with_intel_runtime_pm(runtime_pm, wakeref)
ret = register_context(ce, loop);
- if (unlikely(ret == -EBUSY))
+ if (unlikely(ret == -EBUSY)) {
+ reset_lrc_desc(guc, desc_idx);
+ } else if (unlikely(ret == -ENODEV)) {
reset_lrc_desc(guc, desc_idx);
- else if (unlikely(ret == -ENODEV))
ret = 0;/* Will get registered later */
+ }
}
return ret;
--
2.32.0
[Intel-gfx] [PATCH 11/27] drm/i915/selftests: Fix memory corruption in live_lrc_isolation
GuC submission has exposed an existing memory corruption in
live_lrc_isolation. We believe that some writes to the watchdog offsets
in the LRC (0x178 & 0x17c) can result in trashing of portions of the
address space. With GuC submission there are additional objects which
can move the context redzone into the space that is trashed. To
workaround this avoid poisoning the watchdog.
v2:
(Daniel Vetter)
- Add VLK ref in code to workaround
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 29 +-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index b0977a3b699b..cdc6ae48a1e1 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1074,6 +1074,32 @@ record_registers(struct intel_context *ce,
goto err_after;
}
+static u32 safe_offset(u32 offset, u32 reg)
+{
+ /* XXX skip testing of watchdog - VLK-22772 */
+ if (offset == 0x178 || offset == 0x17c)
+ reg = 0;
+
+ return reg;
+}
+
+static int get_offset_mask(struct intel_engine_cs *engine)
+{
+ if (GRAPHICS_VER(engine->i915) < 12)
+ return 0xfff;
+
+ switch (engine->class) {
+ default:
+ case RENDER_CLASS:
+ return 0x07ff;
+ case COPY_ENGINE_CLASS:
+ return 0x0fff;
+ case VIDEO_DECODE_CLASS:
+ case VIDEO_ENHANCEMENT_CLASS:
+ return 0x3fff;
+ }
+}
+
static struct i915_vma *load_context(struct intel_context *ce, u32 poison)
{
struct i915_vma *batch;
@@ -1117,7 +1143,8 @@ static struct i915_vma *load_context(struct intel_context
*ce, u32 poison)
len = (len + 1) / 2;
*cs++ = MI_LOAD_REGISTER_IMM(len);
while (len--) {
- *cs++ = hw[dw];
+ *cs++ = safe_offset(hw[dw] &
get_offset_mask(ce->engine),
+ hw[dw]);
*cs++ = poison;
dw += 2;
}
--
2.32.0
[Intel-gfx] [PATCH 18/27] drm/i915/guc: Release submit fence from an irq_work
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went holding ce->guc_state.lock and the releasing of the can
acquire sched_engine->lock.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
drivers/gpu/drm/i915/i915_request.h | 5 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9a53bae367b1..deb2e821e441 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2025,6 +2025,14 @@ static const struct intel_context_ops guc_context_ops = {
.create_virtual = guc_create_virtual,
};
+static void submit_work_cb(struct irq_work *wrk)
+{
+ struct i915_request *rq = container_of(wrk, typeof(*rq), submit_work);
+
+ might_lock(>engine->sched_engine->lock);
+ i915_sw_fence_complete(>submit);
+}
+
static void __guc_signal_context_fence(struct intel_context *ce)
{
struct i915_request *rq;
@@ -2034,8 +2042,12 @@ static void __guc_signal_context_fence(struct
intel_context *ce)
if (!list_empty(>guc_state.fences))
trace_intel_context_fence_release(ce);
+ /*
+* Use an IRQ to ensure locking order of sched_engine->lock ->
+* ce->guc_state.lock is preserved.
+*/
list_for_each_entry(rq, >guc_state.fences, guc_fence_link)
- i915_sw_fence_complete(>submit);
+ irq_work_queue(>submit_work);
INIT_LIST_HEAD(>guc_state.fences);
}
@@ -2145,6 +2157,7 @@ static int guc_request_alloc(struct i915_request *rq)
spin_lock_irqsave(>guc_state.lock, flags);
if (context_wait_for_deregister_to_register(ce) ||
context_pending_disable(ce)) {
+ init_irq_work(>submit_work, submit_work_cb);
i915_sw_fence_await(>submit);
list_add_tail(>guc_fence_link, >guc_state.fences);
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 1bc1349ba3c2..d818cfbfc41d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -218,6 +218,11 @@ struct i915_request {
};
struct llist_head execute_cb;
struct i915_sw_fence semaphore;
+ /**
+* @submit_work: complete submit fence from an IRQ if needed for
+* locking hierarchy reasons.
+*/
+ struct irq_work submit_work;
/*
* A list of everyone we wait upon, and everyone who waits upon us.
--
2.32.0
[Intel-gfx] [PATCH 14/27] drm/i915/guc: Don't touch guc_state.sched_state without a lock
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
Part of this is removing a dead code path from guc_lrc_desc_pin where a
context could be deregistered when the aforementioned function was
called from the submission path. Remove this dead code and add a
GEM_BUG_ON if this path is ever attempted to be used.
v2:
(kernel test robo )
- Add __maybe_unused to sched_state_is_init()
Signed-off-by: Matthew Brost
Reported-by: kernel test robot
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 58 ++-
1 file changed, 32 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 85f96d325048..fa87470ea576 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -150,11 +150,23 @@ static inline void clr_context_registered(struct
intel_context *ce)
#define SCHED_STATE_BLOCKED_MASK (0xfff << SCHED_STATE_BLOCKED_SHIFT)
static inline void init_sched_state(struct intel_context *ce)
{
- /* Only should be called from guc_lrc_desc_pin() */
+ lockdep_assert_held(>guc_state.lock);
atomic_set(>guc_sched_state_no_lock, 0);
ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
}
+__maybe_unused
+static bool sched_state_is_init(struct intel_context *ce)
+{
+ /*
+* XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED after
+* suspend.
+*/
+ return !(atomic_read(>guc_sched_state_no_lock) &
+~SCHED_STATE_NO_LOCK_REGISTERED) &&
+ !(ce->guc_state.sched_state &= ~SCHED_STATE_BLOCKED_MASK);
+}
+
static inline bool
context_wait_for_deregister_to_register(struct intel_context *ce)
{
@@ -165,7 +177,7 @@ context_wait_for_deregister_to_register(struct
intel_context *ce)
static inline void
set_context_wait_for_deregister_to_register(struct intel_context *ce)
{
- /* Only should be called from guc_lrc_desc_pin() without lock */
+ lockdep_assert_held(>guc_state.lock);
ce->guc_state.sched_state |=
SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER;
}
@@ -605,9 +617,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
bool pending_disable, pending_enable, deregister, destroyed, banned;
xa_for_each(>context_lookup, index, ce) {
- /* Flush context */
spin_lock_irqsave(>guc_state.lock, flags);
- spin_unlock_irqrestore(>guc_state.lock, flags);
/*
* Once we are at this point submission_disabled() is guaranteed
@@ -623,6 +633,8 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
banned = context_banned(ce);
init_sched_state(ce);
+ spin_unlock_irqrestore(>guc_state.lock, flags);
+
if (pending_enable || destroyed || deregister) {
decr_outstanding_submission_g2h(guc);
if (deregister)
@@ -1325,6 +1337,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
int ret = 0;
GEM_BUG_ON(!engine->mask);
+ GEM_BUG_ON(!sched_state_is_init(ce));
/*
* Ensure LRC + CT vmas are is same region as write barrier is done
@@ -1353,7 +1366,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->priority = ce->guc_prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
guc_context_policy_init(engine, desc);
- init_sched_state(ce);
/*
* The context_lookup xarray is used to determine if the hardware
@@ -1364,26 +1376,23 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
* registering this context.
*/
if (context_registered) {
+ bool disabled;
+ unsigned long flags;
+
trace_intel_context_steal_guc_id(ce);
- if (!loop) {
+ GEM_BUG_ON(!loop);
+
+ /* Seal race with Reset */
+ spin_lock_irqsave(>guc_state.lock, flags);
+ disabled = submission_disabled(guc);
+ if (likely(!disabled)) {
set_context_wait_for_deregister_to_register(ce);
intel_context_get(ce);
- } else {
- bool disabled;
- unsigned long flags;
-
- /* Seal race with Reset */
- spin_lock_irqsave(>guc_state.lock, flags);
- disabled = submission_disabled(guc);
- if (likely(!disabled)) {
- set_context_wait_for_deregister_to_register(ce);
- intel_context_get(ce);
- }
-
[Intel-gfx] [PATCH 09/27] drm/i915/guc: Kick tasklet after queuing a request
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 8f7a11e65ef5..d61f906105ef 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1050,6 +1050,7 @@ static inline void queue_request(struct i915_sched_engine
*sched_engine,
list_add_tail(>sched.link,
i915_sched_lookup_priolist(sched_engine, prio));
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ tasklet_hi_schedule(_engine->tasklet);
}
static int guc_bypass_tasklet_submit(struct intel_guc *guc,
--
2.32.0
[Intel-gfx] [PATCH 05/27] drm/i915/guc: Process all G2H message at once in work queue
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Cc: Daniel Vetter
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 22b4733b55e2..20c710a74498 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1042,9 +1042,9 @@ static void ct_incoming_request_worker_func(struct
work_struct *w)
container_of(w, struct intel_guc_ct, requests.worker);
bool done;
- done = ct_process_incoming_requests(ct);
- if (!done)
- queue_work(system_unbound_wq, >requests.worker);
+ do {
+ done = ct_process_incoming_requests(ct);
+ } while (!done);
}
static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg
*request)
--
2.32.0
[Intel-gfx] [PATCH 00/27] Clean up GuC CI failures, simplify locking, and kernel DOC
Daniel Vetter pointed out that locking in the GuC submission code was overly complicated, let's clean this up a bit before introducing more features in the GuC submission backend. Also fix some CI failures, port fixes from our internal tree, and add a few more selftests for coverage. Lastly, add some kernel DOC explaining how the GuC submission backend works. v2: Fix logic error in 'Workaround reset G2H is received after schedule done G2H', don't propagate errors to dependent fences in execlists submissiom, resolve checkpatch issues, resend to correct lists v3: Fix issue kicking tasklet, drop guc_active, fix ref counting in xarray, add guc_id sub structure, drop inline fuctions, and various other cleanup suggested by Daniel Signed-off-by: Matthew Brost Matthew Brost (27): drm/i915/guc: Fix blocked context accounting drm/i915/guc: Fix outstanding G2H accounting drm/i915/guc: Unwind context requests in reverse order drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context drm/i915/guc: Process all G2H message at once in work queue drm/i915/guc: Workaround reset G2H is received after schedule done G2H Revert "drm/i915/gt: Propagate change in error status to children on unhold" drm/i915/selftests: Add a cancel request selftest that triggers a reset drm/i915/guc: Kick tasklet after queuing a request drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered drm/i915/selftests: Fix memory corruption in live_lrc_isolation drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H drm/i915/guc: Take context ref when cancelling request drm/i915/guc: Don't touch guc_state.sched_state without a lock drm/i915/guc: Reset LRC descriptor if register returns -ENODEV drm/i915: Allocate error capture in nowait context drm/i915/guc: Flush G2H work queue during reset drm/i915/guc: Release submit fence from an irq_work drm/i915/guc: Move guc_blocked fence to struct guc_state drm/i915/guc: Rework and simplify locking drm/i915/guc: Proper xarray usage for contexts_lookup drm/i915/guc: Drop pin count check trick between sched_disable and re-pin drm/i915/guc: Move GuC priority fields in context under guc_active drm/i915/guc: Move fields protected by guc->contexts_lock into sub structure drm/i915/guc: Drop guc_active move everything into guc_state drm/i915/guc: Add GuC kernel doc drm/i915/guc: Drop static inline functions intel_guc_submission.c drivers/gpu/drm/i915/gt/intel_context.c | 19 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 81 +- .../drm/i915/gt/intel_execlists_submission.c | 4 - drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 29 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 19 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 955 +++--- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 126 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 39 +- drivers/gpu/drm/i915/i915_request.h | 23 +- drivers/gpu/drm/i915/i915_trace.h | 12 +- .../drm/i915/selftests/i915_live_selftests.h | 1 + drivers/gpu/drm/i915/selftests/i915_request.c | 100 ++ .../i915/selftests/intel_scheduler_helpers.c | 12 + .../i915/selftests/intel_scheduler_helpers.h | 2 + 16 files changed, 968 insertions(+), 466 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c -- 2.32.0
[Intel-gfx] [PATCH 01/27] drm/i915/guc: Fix blocked context accounting
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniel Vetter
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 87d8dc8f51b9..69faa39da178 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -152,7 +152,7 @@ static inline void init_sched_state(struct intel_context
*ce)
{
/* Only should be called from guc_lrc_desc_pin() */
atomic_set(>guc_sched_state_no_lock, 0);
- ce->guc_state.sched_state = 0;
+ ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
}
static inline bool
--
2.32.0
[Intel-gfx] [PATCH 06/27] drm/i915/guc: Workaround reset G2H is received after schedule done G2H
If the context is reset as a result of the request cancelation the
context reset G2H is received after schedule disable done G2H which is
likely the wrong order. The schedule disable done G2H release the
waiting request cancelation code which resubmits the context. This races
with the context reset G2H which also wants to resubmit the context but
in this case it really should be a NOP as request cancelation code owns
the resubmit. Use some clever tricks of checking the context state to
seal this race until if / when the GuC firmware is fixed.
v2:
(Checkpatch)
- Fix typos
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 43 ---
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e4a099f8f820..8f7a11e65ef5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -832,17 +832,35 @@ __unwind_incomplete_requests(struct intel_context *ce)
static void __guc_reset_context(struct intel_context *ce, bool stalled)
{
struct i915_request *rq;
+ unsigned long flags;
u32 head;
+ bool skip = false;
intel_context_get(ce);
/*
-* GuC will implicitly mark the context as non-schedulable
-* when it sends the reset notification. Make sure our state
-* reflects this change. The context will be marked enabled
-* on resubmission.
+* GuC will implicitly mark the context as non-schedulable when it sends
+* the reset notification. Make sure our state reflects this change. The
+* context will be marked enabled on resubmission.
+*
+* XXX: If the context is reset as a result of the request cancellation
+* this G2H is received after the schedule disable complete G2H which is
+* likely wrong as this creates a race between the request cancellation
+* code re-submitting the context and this G2H handler. This likely
+* should be fixed in the GuC but until if / when that gets fixed we
+* need to workaround this. Convert this function to a NOP if a pending
+* enable is in flight as this indicates that a request cancellation has
+* occurred.
*/
- clr_context_enabled(ce);
+ spin_lock_irqsave(>guc_state.lock, flags);
+ if (likely(!context_pending_enable(ce))) {
+ clr_context_enabled(ce);
+ } else {
+ skip = true;
+ }
+ spin_unlock_irqrestore(>guc_state.lock, flags);
+ if (unlikely(skip))
+ goto out_put;
rq = intel_context_find_active_request(ce);
if (!rq) {
@@ -861,6 +879,7 @@ static void __guc_reset_context(struct intel_context *ce,
bool stalled)
out_replay:
guc_reset_state(ce, head, stalled);
__unwind_incomplete_requests(ce);
+out_put:
intel_context_put(ce);
}
@@ -1605,6 +1624,13 @@ static void guc_context_cancel_request(struct
intel_context *ce,
guc_reset_state(ce, intel_ring_wrap(ce->ring, rq->head),
true);
}
+
+ /*
+* XXX: Racey if context is reset, see comment in
+* __guc_reset_context().
+*/
+ flush_work(_to_guc(ce)->ct.requests.worker);
+
guc_context_unblock(ce);
}
}
@@ -2719,7 +2745,12 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
- if (likely(!intel_context_is_banned(ce))) {
+ /*
+* XXX: Racey if request cancellation has occurred, see comment in
+* __guc_reset_context().
+*/
+ if (likely(!intel_context_is_banned(ce) &&
+ !context_blocked(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
}
--
2.32.0
[Intel-gfx] [PATCH 10/27] drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d61f906105ef..e53a4ef7d442 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1586,6 +1586,9 @@ static void guc_context_unblock(struct intel_context *ce)
spin_lock_irqsave(>guc_state.lock, flags);
if (unlikely(submission_disabled(guc) ||
+intel_context_is_banned(ce) ||
+context_guc_id_invalid(ce) ||
+!lrc_desc_registered(guc, ce->guc_id) ||
!intel_context_is_pinned(ce) ||
context_pending_disable(ce) ||
context_blocked(ce) > 1)) {
--
2.32.0
[Intel-gfx] [PATCH 08/27] drm/i915/selftests: Add a cancel request selftest that triggers a reset
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completely successfully.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 100 ++
1 file changed, 100 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index d67710d10615..e2c5db77f087 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -772,6 +772,98 @@ static int __cancel_completed(struct intel_engine_cs
*engine)
return err;
}
+static int __cancel_reset(struct intel_engine_cs *engine)
+{
+ struct intel_context *ce;
+ struct igt_spinner spin;
+ struct i915_request *rq, *nop;
+ unsigned long preempt_timeout_ms;
+ int err = 0;
+
+ preempt_timeout_ms = engine->props.preempt_timeout_ms;
+ engine->props.preempt_timeout_ms = 100;
+
+ if (igt_spinner_init(, engine->gt))
+ goto out_restore;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ goto out_spin;
+ }
+
+ rq = igt_spinner_create_request(, ce, MI_NOOP);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_ce;
+ }
+
+ pr_debug("%s: Cancelling active request\n", engine->name);
+ i915_request_get(rq);
+ i915_request_add(rq);
+ if (!igt_wait_for_spinner(, rq)) {
+ struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
+
+ pr_err("Failed to start spinner on %s\n", engine->name);
+ intel_engine_dump(engine, , "%s\n", engine->name);
+ err = -ETIME;
+ goto out_rq;
+ }
+
+ nop = intel_context_create_request(ce);
+ if (IS_ERR(nop))
+ goto out_nop;
+ i915_request_get(nop);
+ i915_request_add(nop);
+
+ i915_request_cancel(rq, -EINTR);
+
+ if (i915_request_wait(rq, 0, HZ) < 0) {
+ struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
+
+ pr_err("%s: Failed to cancel hung request\n", engine->name);
+ intel_engine_dump(engine, , "%s\n", engine->name);
+ err = -ETIME;
+ goto out_nop;
+ }
+
+ if (rq->fence.error != -EINTR) {
+ pr_err("%s: fence not cancelled (%u)\n",
+ engine->name, rq->fence.error);
+ err = -EINVAL;
+ goto out_nop;
+ }
+
+ if (i915_request_wait(nop, 0, HZ) < 0) {
+ struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
+
+ pr_err("%s: Failed to complete nop request\n", engine->name);
+ intel_engine_dump(engine, , "%s\n", engine->name);
+ err = -ETIME;
+ goto out_nop;
+ }
+
+ if (nop->fence.error != 0) {
+ pr_err("%s: Nop request errored (%u)\n",
+ engine->name, nop->fence.error);
+ err = -EINVAL;
+ }
+
+out_nop:
+ i915_request_put(nop);
+out_rq:
+ i915_request_put(rq);
+out_ce:
+ intel_context_put(ce);
+out_spin:
+ igt_spinner_fini();
+out_restore:
+ engine->props.preempt_timeout_ms = preempt_timeout_ms;
+ if (err)
+ pr_err("%s: %s error %d\n", __func__, engine->name, err);
+ return err;
+}
+
static int live_cancel_request(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -804,6 +896,14 @@ static int live_cancel_request(void *arg)
return err;
if (err2)
return err2;
+
+ /* Expects reset so call outside of igt_live_test_* */
+ err = __cancel_reset(engine);
+ if (err)
+ return err;
+
+ if (igt_flush_test(i915))
+ return -EIO;
}
return 0;
--
2.32.0
[Intel-gfx] [PATCH 02/27] drm/i915/guc: Fix outstanding G2H accounting
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate a G2H response thus the counter should be incremented.
Also always use helper when decrementing this value.
Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer")
Signed-off-by: Matthew Brost
Cc:
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ++-
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 69faa39da178..32c414aa9009 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -352,6 +352,12 @@ static inline void set_lrc_desc_registered(struct
intel_guc *guc, u32 id,
xa_unlock_irqrestore(>context_lookup, flags);
}
+static void decr_outstanding_submission_g2h(struct intel_guc *guc)
+{
+ if (atomic_dec_and_test(>outstanding_submission_g2h))
+ wake_up_all(>ct.wq);
+}
+
static int guc_submission_send_busy_loop(struct intel_guc *guc,
const u32 *action,
u32 len,
@@ -360,11 +366,13 @@ static int guc_submission_send_busy_loop(struct intel_guc
*guc,
{
int err;
- err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
-
- if (!err && g2h_len_dw)
+ if (g2h_len_dw)
atomic_inc(>outstanding_submission_g2h);
+ err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
+ if (err == -EBUSY && g2h_len_dw)
+ decr_outstanding_submission_g2h(guc);
+
return err;
}
@@ -616,7 +624,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
init_sched_state(ce);
if (pending_enable || destroyed || deregister) {
- atomic_dec(>outstanding_submission_g2h);
+ decr_outstanding_submission_g2h(guc);
if (deregister)
guc_signal_context_fence(ce);
if (destroyed) {
@@ -635,7 +643,7 @@ static void scrub_guc_desc_for_outstanding_g2h(struct
intel_guc *guc)
intel_engine_signal_breadcrumbs(ce->engine);
}
intel_context_sched_disable_unpin(ce);
- atomic_dec(>outstanding_submission_g2h);
+ decr_outstanding_submission_g2h(guc);
spin_lock_irqsave(>guc_state.lock, flags);
guc_blocked_fence_complete(ce);
spin_unlock_irqrestore(>guc_state.lock, flags);
@@ -2583,12 +2591,6 @@ g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
return ce;
}
-static void decr_outstanding_submission_g2h(struct intel_guc *guc)
-{
- if (atomic_dec_and_test(>outstanding_submission_g2h))
- wake_up_all(>ct.wq);
-}
-
int intel_guc_deregister_done_process_msg(struct intel_guc *guc,
const u32 *msg,
u32 len)
--
2.32.0
[Intel-gfx] [PATCH 03/27] drm/i915/guc: Unwind context requests in reverse order
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 32c414aa9009..9ca0ba4ea85a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -805,9 +805,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
spin_lock_irqsave(_engine->lock, flags);
spin_lock(>guc_active.lock);
- list_for_each_entry_safe(rq, rn,
->guc_active.requests,
-sched.link) {
+ list_for_each_entry_safe_reverse(rq, rn,
+>guc_active.requests,
+sched.link) {
if (i915_request_completed(rq))
continue;
@@ -824,7 +824,7 @@ __unwind_incomplete_requests(struct intel_context *ce)
}
GEM_BUG_ON(i915_sched_engine_is_empty(sched_engine));
- list_add_tail(>sched.link, pl);
+ list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
spin_lock(>guc_active.lock);
--
2.32.0
[Intel-gfx] [PATCH 04/27] drm/i915/guc: Don't drop ce->guc_active.lock when unwinding context
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9ca0ba4ea85a..e4a099f8f820 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -812,8 +812,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
continue;
list_del_init(>sched.link);
- spin_unlock(>guc_active.lock);
-
__i915_request_unsubmit(rq);
/* Push the request back into the queue for later resubmission.
*/
@@ -826,8 +824,6 @@ __unwind_incomplete_requests(struct intel_context *ce)
list_add(>sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
-
- spin_lock(>guc_active.lock);
}
spin_unlock(>guc_active.lock);
spin_unlock_irqrestore(_engine->lock, flags);
--
2.32.0
