Re: [Intel-gfx] [PATCH 13/17] drm/i915/dp: select 128b/132b channel encoding for UHBR rates
On Thu, 19 Aug 2021, Ville Syrjälä wrote: > 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, >>&rate_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 >= ? Yes, whoops, thanks! > >> +DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B; >> drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2); >> >> intel_dp->DP |= DP_PORT_EN; >> -- >> 2.20.1 -- Jani Nikula, Intel Open Source Graphics Center
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, &ct->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(&rq->sched.link);
> > - spin_unlock(&ce->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(&rq->sched.link, pl);
> > set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
> > -
> > - spin_lock(&ce->guc_active.lock);
> > }
> > spin_unlock(&ce->guc_active.lock);
> > spin_unlock_irqrestore(&sched_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(&sched_engine->lock, flags);
spin_lock(&ce->guc_active.lock);
- list_for_each_entry_safe(rq, rn,
-&ce->guc_active.requests,
-sched.link) {
+ list_for_each_entry_safe_reverse(rq, rn,
+&ce->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(&rq->sched.link, pl);
+ list_add(&rq->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(&ce->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, &rq->fence.flags);
spin_lock(&ce->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(&rq->sched.link);
- spin_unlock(&ce->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(&rq->sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
-
- spin_lock(&ce->guc_active.lock);
}
spin_unlock(&ce->guc_active.lock);
spin_unlock_irqrestore(&sched_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(&sched_engine->lock, flags);
> > spin_lock(&ce->guc_active.lock);
> > - list_for_each_entry_safe(rq, rn,
> > -&ce->guc_active.requests,
> > -sched.link) {
> > + list_for_each_entry_safe_reverse(rq, rn,
> > +&ce->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(&rq->sched.link, pl);
> > + list_add(&rq->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(&ce->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, &rq->fence.flags);
> > spin_lock(&ce->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(&sched_engine->lock, flags);
spin_lock(&ce->guc_active.lock);
- list_for_each_entry_safe(rq, rn,
-&ce->guc_active.requests,
-sched.link) {
+ list_for_each_entry_safe_reverse(rq, rn,
+&ce->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(&rq->sched.link, pl);
+ list_add(&rq->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, &rq->fence.flags);
spin_lock(&ce->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(&obj),
.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(&cork, 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(&cork);
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]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20857/shard-tglb5/igt@kms_big...@yf-tiled-64bpp-
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(&i915->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]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20856/shard-tglb3/igt@gem_mmap
[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
CI_D
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(&guc->context_lookup, flags);
> > }
> > +static void decr_outstanding_submission_g2h(struct intel_guc *guc)
> > +{
> > + if (atomic_dec_and_test(&guc->outstanding_submission_g2h))
> > + wake_up_all(&guc->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(&guc->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(&guc->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(&guc->outstanding_submission_g2h);
> > + decr_outstanding_submission_g2h(guc);
> > spin_lock_irqsave(&ce->guc_state.lock, flags);
> > guc_blocked_fence_complete(ce);
> > spin_unlock_irqrestore(&ce->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(&guc->outstanding_submission_g2h))
> > - wake_up_all(&guc->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(&guc->context_lookup, flags);
}
+static void decr_outstanding_submission_g2h(struct intel_guc *guc)
+{
+ if (atomic_dec_and_test(&guc->outstanding_submission_g2h))
+ wake_up_all(&guc->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(&guc->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(&guc->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(&guc->outstanding_submission_g2h);
+ decr_outstanding_submission_g2h(guc);
spin_lock_irqsave(&ce->guc_state.lock, flags);
guc_blocked_fence_complete(ce);
spin_unlock_irqrestore(&ce->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(&guc->outstanding_submission_g2h))
- wake_up_all(&guc->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(&dig_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, &hdcp_1_x);
> > -if (ret) {
> > -drm_dbg_kms(&i915->drm,
> > - "[%s:%d] failed to read RxInfo ret=%d\n",
> > - connector->base.name, connector->base.base.id,
> >
[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(&dig_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, &hdcp_1_x);
- if (ret) {
- drm_dbg_kms(&i915->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 = in
[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(&dig_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(&hdcp->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, &dev_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 = &dig_port->dp;
- struct intel_hdcp *hdcp = &dp->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(&hdcp->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 = &dig_port->dp;
+ struct intel_hdcp *hdcp = &dp->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(&hdcp->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, > &rate_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(&intel_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(&intel_dp->aux,
> + DP_128B132B_SUPPORTED_LINK_RATES,
> &uhbr_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 = &pipe_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;
> - limi
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]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20853/shard-apl1/igt@kms_big...@x-tiled-max-hw-stride-64bpp-ro
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,
> > table->t
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 806ad688274
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(&intel_dp->aux,
- DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
!val) {
- drm_dbg_kms(&i915->drm, "Error in reading link service irq
vector\n");
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
!val)
return;
- }
if (drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
- drm_dbg_kms(&i915->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: - shard-a
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]: https://intel-gfx-ci.01.org/tree/drm-tip/
[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: contex
[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 (&dev->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 (&dev->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 (&helper->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 --> &helper->lock --> &dev->master_rwsem
> >> Possible unsafe locking scenario:
> >> CPU0CPU1
> >>
> >>lock(&dev->master_rwsem);
> >> lock(&helper->lock);
> >> lock(&dev->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
>
[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 = &connector->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,
- &data, sizeof(data));
+ &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 =
&to_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,
- &data, sizeof(data));
+ &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 (&dev->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 (&dev->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 (&helper->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 --> &helper->lock --> &dev->master_rwsem
Possible unsafe locking scenario:
CPU0CPU1
lock(&dev->master_rwsem);
lock(&helper->lock);
lock(&dev->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 d
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 = &fbc->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(&i915->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, &mr->total, &mr->avail);
+ intel_memory_region_debug(mr, &p);
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",
+ &mr->total, &mr->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(&block->link, &allocated);
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, &mm->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_bu
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]: https://intel
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(&plane->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(&plane->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(&i915->drm, &obj->base, size); > > i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, > > flags); > > i915_gem_object_init_memory_region(obj, mem); > > - i915_gem_object_make_unshrinkable(obj); > > INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | > > __GFP_NOWARN); > > mutex_init(&obj->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, > >&ctx, 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 sch
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(&i915->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, &mr->total, &mr->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, &p);
> + else
> + seq_printf(m, "total:%pa, available:%pa
> bytes\n",
> + &mr->total, &mr->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(&i915->drm, &obj->base, size); > i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, > flags); > i915_gem_object_init_memory_region(obj, mem); > - i915_gem_object_make_unshrinkable(obj); > INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | > __GFP_NOWARN); > mutex_init(&obj->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, > &ctx, 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 'gen11_f
[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(&block->link, &allocated);
> 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, &mm->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 i9
