[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Implement PSF GV point support (rev3)
== Series Details == Series: drm/i915: Implement PSF GV point support (rev3) URL : https://patchwork.freedesktop.org/series/90361/ State : failure == Summary == Applying: drm/i915: Implement PSF GV point support error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Implement PSF GV point support When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use DRIVER_NAME for tracing unattached requests
On Thu, May 20, 2021 at 4:28 PM Daniel Vetter wrote:
>
> On Thu, May 20, 2021 at 08:35:14AM +0100, Matthew Auld wrote:
> > From: Chris Wilson
> >
> > The first tracepoint for a request is trace_dma_fence_init called before
> > we have associated the request with a device. The tracepoint uses
> > fence->ops->get_driver_name() as a pretty name, and as we try to report
> > the device name this oopses as it is then NULL. Support the early
> > tracepoint by reporting the DRIVER_NAME instead of the actual device
> > name.
> >
> > Note that rq->engine remains during the course of request recycling
> > (SLAB_TYPESAFE_BY_RCU). For the physical engines, the pointer remains
> > valid, however a virtual engine may be destroyed after the request is
> > retired. If we process a preempt-to-busy completed request along the
> > virtual engine, we should make sure we mark the request as no longer
> > belonging to the virtual engine to remove the dangling pointers from the
> > tracepoint.
>
> Why can't we assign the request beforehand? The idea behind these
> tracepoints is that they actually match up, if trace_dma_fence_init is
> different, then we're breaking that.
Ok I looked a bit more and pondered this a bit, and the initial
tracepoint is called from dma_fence_init, where we haven't yet set up
rq->engine properly. So that part makes sense, but should have a
bigger comment that explains this a bit more and why we can't solve
this in a neater way. Probably should also drop the unlikely(), this
isn't a performance critical path, ever.
The other changes thgouh feel like they should be split out into a
separate path, since they solve a conceptually totally different
issue: SLAB_TYPESAFE_BY_RCU recycling. And I'm honestly not sure about
that one whether it's even correct, there's another patch floating
around that sprinkles rcu_read_lock around some of these accesssors,
and that would be a breakage of dma_fence interaces where outside of
i915 rcu isn't required for this stuff. So imo should be split out,
and come with a wider analysis of what's going on there and why and
how exactly i915 works.
In generally SLAB_TYPESAFE_BY_RCU is extremely dangerous and I'm
frankly not sure we have the perf data (outside of contrived
microbenchmarks) showing that it's needed and justifies all the costs
it's encurring.
-Daniel
> -Daniel
>
> >
> > Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring
> > seqno")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Chintan M Patel
> > Cc: Andi Shyti
> > Cc: # v5.7+
> > Signed-off-by: Matthew Auld
> > ---
> > .../drm/i915/gt/intel_execlists_submission.c | 20 ++-
> > drivers/gpu/drm/i915/i915_request.c | 7 ++-
> > 2 files changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index de124870af44..75604e927d34 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3249,6 +3249,18 @@ static struct list_head *virtual_queue(struct
> > virtual_engine *ve)
> > return &ve->base.execlists.default_priolist.requests;
> > }
> >
> > +static void
> > +virtual_submit_completed(struct virtual_engine *ve, struct i915_request
> > *rq)
> > +{
> > + GEM_BUG_ON(!__i915_request_is_complete(rq));
> > + GEM_BUG_ON(rq->engine != &ve->base);
> > +
> > + __i915_request_submit(rq);
> > +
> > + /* Remove the dangling pointer to the stale virtual engine */
> > + WRITE_ONCE(rq->engine, ve->siblings[0]);
> > +}
> > +
> > static void rcu_virtual_context_destroy(struct work_struct *wrk)
> > {
> > struct virtual_engine *ve =
> > @@ -3265,8 +3277,7 @@ static void rcu_virtual_context_destroy(struct
> > work_struct *wrk)
> >
> > old = fetch_and_zero(&ve->request);
> > if (old) {
> > - GEM_BUG_ON(!__i915_request_is_complete(old));
> > - __i915_request_submit(old);
> > + virtual_submit_completed(ve, old);
> > i915_request_put(old);
> > }
> >
> > @@ -3538,13 +3549,12 @@ static void virtual_submit_request(struct
> > i915_request *rq)
> >
> > /* By the time we resubmit a request, it may be completed */
> > if (__i915_request_is_complete(rq)) {
> > - __i915_request_submit(rq);
> > + virtual_submit_completed(ve, rq);
> > goto unlock;
> > }
> >
> > if (ve->request) { /* background completion from preempt-to-busy */
> > - GEM_BUG_ON(!__i915_request_is_complete(ve->request));
> > - __i915_request_submit(ve->request);
> > + virtual_submit_completed(ve, ve->request);
> > i915_request_put(ve->request);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i9
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Introduce i915_sched_engine object
On Thu, May 27, 2021 at 4:19 PM Matthew Brost wrote: > > On Thu, May 27, 2021 at 10:41:10AM +0100, Tvrtko Ursulin wrote: > > > > On 26/05/2021 21:03, Matthew Brost wrote: > > > Introduce i915_sched_engine object which is lower level data structure > > > that i915_scheduler / generic code can operate on without touching > > > execlist specific structures. This allows additional submission backends > > > to be added without breaking the layering. > > > > > > This is a bit of detour to integrating the i915 with the DRM scheduler > > > but this object will still exist when the DRM scheduler lands in the > > > i915. It will however look a bit different. It will encapsulate the > > > drm_gpu_scheduler object plus and common variables (to the backends) > > > related to scheduling. Regardless this is a step in the right direction. > > > > It looks like pretty much the same concept Chris implemented in upstream(*) > > before they got removed. Both series move the scheduling lists into a new > > object, be it i915_sched, or i915_sched_engine. There probably are some > > differences but without looking much deeper it is hard to say if they are > > important. > > > > Were you aware of this series and were there any technical objections to it? > > > > I haven't dug to deep into the series but yes, I am aware of this series. I > merged my series to internal while Chris had this inflight upstream. They do > have similar concepts of i915_sched_engine object. Imo both of them are a detour since it's not drm/scheduler, but also we need one and this one here is the one we have so I'm not seeing the point of repainting that bikeshed in different colors. Imo much better if we just land this and then head as straight as possible towards drm/scheduler as the interface. Now a bit of polish here might be good, but in entirely different ways: - I think splitting the patch into the purely mechanical code movement and addition of the new callbacks would be good. Should slice really well I hope, so not much work. - Proper kerneldoc for at least anything new around datastructures. That means a) check the header is pulled in somewhere suitable in i915.rst b) minimal fixes for any warnings it throws c) then do right in anything new. Especially with datastructure stuff like locking/lifetime rules or rules around callbacks and these big ticket items are important to document and cross reference, and I think the pain for doing a)&b) for these is worth it. > > Because there do appear to be some extra advantages in the dropped work, > > like consolidating finding of active request and moving some other bits to > > be backend agnostic. > > > > After briefly looking at this series most of Chris's changes are not relevent > if > we move to DRM scheduler. All of the the below series [1] and internal is > based > this code not Chris's. I don't see the point revisiting Chris's old patches > when > the goal is to merge GuC submission quickly, rework it is place as needed, and > the long term goal is to move to the DRM scheduler. Agreed. Cheers, Daniel > > Matt > > [1] https://patchwork.freedesktop.org/series/89844/ > > > Regards, > > > > Tvrtko > > > > > > *) Approx list: > > > > 564c84ac5dee drm/i915: Move finding the current active request to the > > scheduler > > f06f5161eba3 drm/i915: Move submit_request to i915_sched_engine > > 38a40d211075 drm/i915/gt: Only kick the scheduler on timeslice/preemption > > change > > 4f08e41b51e2 drm/i915: Move tasklet from execlists to sched > > 5d814ae56fdd drm/i915: Move scheduler queue > > 4d4da5ab8b3c drm/i915: Move common active lists from engine to > > i915_scheduler > > 4a5c90b6f7a8 drm/i915: Wrap access to intel_engine.active > > 34cab8ee986f drm/i915/gt: Pull all execlists scheduler initialisation > > together > > c968d4d87cf4 drm/i915: Extract the ability to defer and rerun a request > > later > > 746cafc44205 drm/i915: Extract request suspension from the execlists > > 3d473f1476d8 drm/i915: Extract request rewinding from execlists > > d353a704a6db drm/i915: Extract request submission from execlists > > ea848ef93075 drm/i915: Replace engine->schedule() with a known request > > operation > > > > > > > > Cc: Daniel Vetter > > > Cc: Daniele Ceraolo Spurio > > > Signed-off-by: Matthew Brost > > > --- > > > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +- > > > drivers/gpu/drm/i915/gt/intel_engine.h| 16 - > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 77 ++-- > > > .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 +- > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 10 +- > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 42 +-- > > > drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- > > > .../drm/i915/gt/intel_execlists_submission.c | 350 +++--- > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 13 +- > > > drivers/gpu/drm/i915/gt/mock_engine.c | 17 +- > > > drivers/gpu/drm/i915/gt/selftest_exec
Re: [Intel-gfx] [PATCH 16/29] drm/i915/gem: Add an intermediate proto_context struct
On Thu, May 27, 2021 at 11:26:37AM -0500, Jason Ekstrand wrote:
> The current context uAPI allows for two methods of setting context
> parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> former is allowed to be called at any time while the later happens as
> part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
> settable via the other. While some params are fairly simple and setting
> them on a live context is harmless such the context priority, others are
> far trickier such as the VM or the set of engines. In order to swap out
> the VM, for instance, we have to delay until all current in-flight work
> is complete, swap in the new VM, and then continue. This leads to a
> plethora of potential race conditions we'd really rather avoid.
>
> Unfortunately, both methods of setting the VM and engine set are in
^the
At least my English parser jumped there a bit and got confused :-)
> active use today so we can't simply disallow setting the VM or engine
> set vial SET_CONTEXT_PARAM. In order to work around this wart, this
> commit adds a proto-context struct which contains all the context create
> parameters.
>
> Signed-off-by: Jason Ekstrand
I also looked at my review from the previous round and I think we have a
few opens there that haven't been addressed here. Would be nice to check
that out too and my reply there if you're disagreeing and want to paint
the shed differently :-)
I've found a few other things needing polish below on top of the earlier
bits.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
> .../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
> 3 files changed, 153 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index fc471243aa769..10bff488444b6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -191,6 +191,97 @@ static int validate_priority(struct drm_i915_private
> *i915,
> return 0;
> }
>
> +static void proto_context_close(struct i915_gem_proto_context *pc)
> +{
> + if (pc->vm)
> + i915_vm_put(pc->vm);
> + kfree(pc);
> +}
> +
> +static int proto_context_set_persistence(struct drm_i915_private *i915,
> + struct i915_gem_proto_context *pc,
> + bool persist)
> +{
> + if (persist) {
> + /*
> + * Only contexts that are short-lived [that will expire or be
> + * reset] are allowed to survive past termination. We require
> + * hangcheck to ensure that the persistent requests are healthy.
> + */
> + if (!i915->params.enable_hangcheck)
> + return -EINVAL;
> +
> + __set_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);
> + } else {
> + /* To cancel a context we use "preempt-to-idle" */
> + if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> + return -ENODEV;
> +
> + /*
> + * If the cancel fails, we then need to reset, cleanly!
> + *
> + * If the per-engine reset fails, all hope is lost! We resort
> + * to a full GPU reset in that unlikely case, but realistically
> + * if the engine could not reset, the full reset does not fare
> + * much better. The damage has been done.
> + *
> + * However, if we cannot reset an engine by itself, we cannot
> + * cleanup a hanging persistent context without causing
> + * colateral damage, and we should not pretend we can by
> + * exposing the interface.
> + */
> + if (!intel_has_reset_engine(&i915->gt))
> + return -ENODEV;
> +
> + __clear_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);
> + }
> +
> + return 0;
> +}
> +
> +static struct i915_gem_proto_context *
> +proto_context_create(struct drm_i915_private *i915, unsigned int flags)
> +{
> + struct i915_gem_proto_context *pc, *err;
> +
> + pc = kzalloc(sizeof(*pc), GFP_KERNEL);
> + if (!pc)
> + return ERR_PTR(-ENOMEM);
> +
> + if (HAS_FULL_PPGTT(i915)) {
> + struct i915_ppgtt *ppgtt;
> +
> + ppgtt = i915_ppgtt_create(&i915->gt);
> + if (IS_ERR(ppgtt)) {
> + drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
> + PTR_ERR(ppgtt));
> + err = ERR_CAST(ppgtt);
> + goto proto_close;
> + }
> + pc->vm = &ppgtt->vm;
> + }
> +
> + pc->user_flags = 0;
> + __set_bit(UCONTEXT_BANNABLE, &pc->user_flags);
> + __set_
Re: [Intel-gfx] [PATCH 18/29] drm/i915/gem: Optionally set SSEU in intel_context_set_gem
On Thu, May 27, 2021 at 11:26:39AM -0500, Jason Ekstrand wrote:
> For now this is a no-op because everyone passes in a null SSEU but it
> lets us get some of the error handling and selftest refactoring plumbed
> through.
>
> Signed-off-by: Jason Ekstrand
I've reviewed this one already in the previous round, did you change
anything that means I should re-review this here?
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
> .../gpu/drm/i915/gem/selftests/mock_context.c | 6 ++-
> 2 files changed, 36 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index f8f3f514b4265..d247fb223aac7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -320,9 +320,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
> } while (1);
> }
>
> -static void intel_context_set_gem(struct intel_context *ce,
> - struct i915_gem_context *ctx)
> +static int intel_context_set_gem(struct intel_context *ce,
> + struct i915_gem_context *ctx,
> + struct intel_sseu sseu)
> {
> + int ret = 0;
> +
> GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
> RCU_INIT_POINTER(ce->gem_context, ctx);
>
> @@ -349,6 +352,12 @@ static void intel_context_set_gem(struct intel_context
> *ce,
>
> intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
> }
> +
> + /* A valid SSEU has no zero fields */
> + if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
> + ret = intel_context_reconfigure_sseu(ce, sseu);
> +
> + return ret;
> }
>
> static void __free_engines(struct i915_gem_engines *e, unsigned int count)
> @@ -416,7 +425,8 @@ static struct i915_gem_engines *alloc_engines(unsigned
> int count)
> return e;
> }
>
> -static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
> +static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
> + struct intel_sseu rcs_sseu)
> {
> const struct intel_gt *gt = &ctx->i915->gt;
> struct intel_engine_cs *engine;
> @@ -429,6 +439,8 @@ static struct i915_gem_engines *default_engines(struct
> i915_gem_context *ctx)
>
> for_each_engine(engine, gt, id) {
> struct intel_context *ce;
> + struct intel_sseu sseu = {};
> + int ret;
>
> if (engine->legacy_idx == INVALID_ENGINE)
> continue;
> @@ -442,10 +454,18 @@ static struct i915_gem_engines *default_engines(struct
> i915_gem_context *ctx)
> goto free_engines;
> }
>
> - intel_context_set_gem(ce, ctx);
> -
> e->engines[engine->legacy_idx] = ce;
> e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
> +
> + if (engine->class == RENDER_CLASS)
> + sseu = rcs_sseu;
> +
> + ret = intel_context_set_gem(ce, ctx, sseu);
> + if (ret) {
> + err = ERR_PTR(ret);
> + goto free_engines;
> + }
> +
> }
>
> return e;
> @@ -759,6 +779,7 @@ __create_context(struct drm_i915_private *i915,
> {
> struct i915_gem_context *ctx;
> struct i915_gem_engines *e;
> + struct intel_sseu null_sseu = {};
> int err;
> int i;
>
> @@ -776,7 +797,7 @@ __create_context(struct drm_i915_private *i915,
> INIT_LIST_HEAD(&ctx->stale.engines);
>
> mutex_init(&ctx->engines_mutex);
> - e = default_engines(ctx);
> + e = default_engines(ctx, null_sseu);
> if (IS_ERR(e)) {
> err = PTR_ERR(e);
> goto err_free;
> @@ -1543,6 +1564,7 @@ set_engines__load_balance(struct i915_user_extension
> __user *base, void *data)
> struct intel_engine_cs *stack[16];
> struct intel_engine_cs **siblings;
> struct intel_context *ce;
> + struct intel_sseu null_sseu = {};
> u16 num_siblings, idx;
> unsigned int n;
> int err;
> @@ -1615,7 +1637,7 @@ set_engines__load_balance(struct i915_user_extension
> __user *base, void *data)
> goto out_siblings;
> }
>
> - intel_context_set_gem(ce, set->ctx);
> + intel_context_set_gem(ce, set->ctx, null_sseu);
>
> if (cmpxchg(&set->engines->engines[idx], NULL, ce)) {
> intel_context_put(ce);
> @@ -1723,6 +1745,7 @@ set_engines(struct i915_gem_context *ctx,
> struct drm_i915_private *i915 = ctx->i915;
> struct i915_context_param_engines __user *user =
> u64_to_user_ptr(args->value);
> + struct intel_sseu null_sseu = {};
> struct set_engines set = { .ctx = ctx };
> unsigned int num_engines, n;
> u64 extensions;
> @@ -1732,7 +17
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Extend QGV point restrict mask to 0x3
== Series Details == Series: series starting with [1/2] drm/i915: Extend QGV point restrict mask to 0x3 URL : https://patchwork.freedesktop.org/series/90776/ State : warning == Summary == $ dim checkpatch origin/drm-tip a12e5c83304a drm/i915: Extend QGV point restrict mask to 0x3 603bd832dcc5 drm/i915: Implement PSF GV point support -:65: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #65: FILE: drivers/gpu/drm/i915/display/intel_bw.c:59: +static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, + struct intel_psf_gv_point *points) -:94: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #94: FILE: drivers/gpu/drm/i915/display/intel_bw.c:93: + drm_err(&dev_priv->drm, "Failed to disable qgv points (%d) points: 0x%x\n", ret, points_mask); -:119: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a quoted newline #119: FILE: drivers/gpu/drm/i915/display/intel_bw.c:150: + "PSF GV %d: CLK=%d \n", total: 0 errors, 2 warnings, 1 checks, 248 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/29] drm/i915/gem: Use the proto-context to handle create parameters (v2)
On Thu, May 27, 2021 at 11:26:42AM -0500, Jason Ekstrand wrote:
> This means that the proto-context needs to grow support for engine
> configuration information as well as setparam logic. Fortunately, we'll
> be deleting a lot of setparam logic on the primary context shortly so it
> will hopefully balance out.
>
> There's an extra bit of fun here when it comes to setting SSEU and the
> way it interacts with PARAM_ENGINES. Unfortunately, thanks to
> SET_CONTEXT_PARAM and not being allowed to pick the order in which we
> handle certain parameters, we have think about those interactions.
>
> v2 (Daniel Vetter):
> - Add a proto_context_free_user_engines helper
> - Comment on SSEU in the commit message
> - Use proto_context_set_persistence in set_proto_ctx_param
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 552 +-
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 58 ++
> 2 files changed, 588 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index cf7c281977a3e..d68c111bc824a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -191,10 +191,24 @@ static int validate_priority(struct drm_i915_private
> *i915,
> return 0;
> }
>
> +static void proto_context_free_user_engines(struct i915_gem_proto_context
> *pc)
> +{
> + int i;
> +
> + if (pc->user_engines) {
> + for (i = 0; i < pc->num_user_engines; i++)
> + kfree(pc->user_engines[i].siblings);
> + kfree(pc->user_engines);
> + }
> + pc->user_engines = NULL;
> + pc->num_user_engines = -1;
> +}
> +
> static void proto_context_close(struct i915_gem_proto_context *pc)
> {
> if (pc->vm)
> i915_vm_put(pc->vm);
> + proto_context_free_user_engines(pc);
> kfree(pc);
> }
>
> @@ -211,7 +225,7 @@ static int proto_context_set_persistence(struct
> drm_i915_private *i915,
> if (!i915->params.enable_hangcheck)
> return -EINVAL;
>
> - __set_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);
> + pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
> } else {
> /* To cancel a context we use "preempt-to-idle" */
> if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> @@ -233,7 +247,7 @@ static int proto_context_set_persistence(struct
> drm_i915_private *i915,
> if (!intel_has_reset_engine(&i915->gt))
> return -ENODEV;
>
> - __clear_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);
> + pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
Squashed into wrong patch I think. Also the one right above.
> }
>
> return 0;
> @@ -248,6 +262,9 @@ proto_context_create(struct drm_i915_private *i915,
> unsigned int flags)
> if (!pc)
> return ERR_PTR(-ENOMEM);
>
> + pc->num_user_engines = -1;
> + pc->user_engines = NULL;
If you go with my proto_context_reset_user_engines() suggestion below you
could use that here too. It's overkill, but it makes the code a bit
clearer in what it does I think.
> +
> if (HAS_FULL_PPGTT(i915)) {
> struct i915_ppgtt *ppgtt;
>
> @@ -261,9 +278,8 @@ proto_context_create(struct drm_i915_private *i915,
> unsigned int flags)
> pc->vm = &ppgtt->vm;
> }
>
> - pc->user_flags = 0;
> - __set_bit(UCONTEXT_BANNABLE, &pc->user_flags);
> - __set_bit(UCONTEXT_RECOVERABLE, &pc->user_flags);
> + pc->user_flags = BIT(UCONTEXT_BANNABLE) |
> + BIT(UCONTEXT_RECOVERABLE);
Same here.
> proto_context_set_persistence(i915, pc, true);
> pc->sched.priority = I915_PRIORITY_NORMAL;
>
> @@ -282,6 +298,429 @@ proto_context_create(struct drm_i915_private *i915,
> unsigned int flags)
> return err;
> }
>
> +static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
> + struct i915_gem_proto_context *pc,
> + const struct drm_i915_gem_context_param *args)
> +{
> + struct i915_address_space *vm;
> +
> + if (args->size)
> + return -EINVAL;
> +
> + if (!pc->vm)
I got confused by this and then realized it's checking for
HAS_FULL_PPGTT(). I wonder whether we should lock this down more with
runtime checks, or at least have a comment that ctx->vm is only set for
HAS_FULL_PPGTT.
If you concur I'd do the kerneldoc warning that this is tied to full
ppgtt, switch this check to HAS_FULL_PPGTT() and maybe do a
WARN_ON(!!ctx->vm == HAS_FULL_PPGTT());
in the context destroy (not proto context destroy). Or drop this
suggestion if you feel like this is all obvious.
> + return -ENODEV;
> +
> + if (upper_32_bits(args->value))
> + return -ENOENT;
> +
> + vm = i915_gem_vm_lookup(
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Extend QGV point restrict mask to 0x3
== Series Details == Series: series starting with [1/2] drm/i915: Extend QGV point restrict mask to 0x3 URL : https://patchwork.freedesktop.org/series/90776/ State : success == Summary == CI Bug Log - changes from CI_DRM_10151 -> Patchwork_20236 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/index.html Known issues Here are the changes found in Patchwork_20236 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][1] ([i915#2283]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:NOTRUN -> [INCOMPLETE][2] ([i915#2782] / [i915#2940] / [i915#3462]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bsw-nick/igt@i915_selftest@l...@execlists.html - fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][3] ([i915#3462]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bsw-nick/igt@kms_chamel...@dp-crc-fast.html * igt@kms_psr@cursor_plane_move: - fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html * igt@prime_vgem@basic-fence-flip: - fi-bsw-nick:NOTRUN -> [SKIP][6] ([fdo#109271]) +45 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bsw-nick/igt@prime_v...@basic-fence-flip.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#1436]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bsw-nick/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][8] ([i915#1888]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html Warnings * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [DMESG-FAIL][10] ([i915#3462]) -> [INCOMPLETE][11] ([i915#3462]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html - fi-bsw-kefka: [DMESG-FAIL][12] ([i915#3462]) -> [INCOMPLETE][13] ([i915#2782] / [i915#2940] / [i915#3462]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html - fi-tgl-u2: [DMESG-FAIL][14] ([i915#3462]) -> [INCOMPLETE][15] ([i915#3462]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-tgl-u2/igt@i915_selftest@l...@execlists.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-tgl-u2/igt@i915_selftest@l...@execlists.html - fi-cml-s: [DMESG-FAIL][16] ([i915#3462]) -> [INCOMPLETE][17] ([i915#3462]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-cml-s/igt@i915_selftest@l...@execlists.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-cml-s/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-skl-6600u: [FAIL][18] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][19] ([i915#1436] / [i915#3363]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-skl-6600u/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-skl-6600u/igt@run...@aborted.html - fi-cfl-8109u: [FAIL][20] ([i915#2426] / [i915#3363]) -> [FAIL][21] ([i915#3363]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-cfl-8109u/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-cfl-8109u/igt@run...@aborted.html - fi-glk-dsi: [FAIL][22] ([i915#2426] / [i915#3363] / [k.org#202321]) -> [FAIL][23] ([i915#3363] / [k.org#202321]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/fi-glk-dsi/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/fi-glk-dsi/igt@run...@aborted.html - fi-bdw-5557u: [FAIL][24] ([i915#1602] / [i915#2029]) -> [FAIL][25] ([i915#3462]) [24]: https://intel-gfx-ci.01.org/tree/drm-ti
Re: [Intel-gfx] [PATCH 24/29] drm/i915/gem: Delay context creation
On Thu, May 27, 2021 at 11:26:45AM -0500, Jason Ekstrand wrote:
> The current context uAPI allows for two methods of setting context
> parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> former is allowed to be called at any time while the later happens as
> part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
> settable via the other. While some params are fairly simple and setting
> them on a live context is harmless such the context priority, others are
such _as_ the
> far trickier such as the VM or the set of engines. In order to swap out
> the VM, for instance, we have to delay until all current in-flight work
> is complete, swap in the new VM, and then continue. This leads to a
> plethora of potential race conditions we'd really rather avoid.
>
> In previous patches, we added a i915_gem_proto_context struct which is
> capable of storing and tracking all such create parameters. This commit
> delays the creation of the actual context until after the client is done
> configuring it with SET_CONTEXT_PARAM. From the perspective of the
> client, it has the same u32 context ID the whole time. From the
> perspective of i915, however, it's an i915_gem_proto_context right up
> until the point where we attempt to do something which the proto-context
> can't handle at which point the real context gets created.
s/ at which point/. Then/
At least feels a bit like a run-on sentence :-)
> This is accomplished via a little xarray dance. When GEM_CONTEXT_CREATE
> is called, we create a proto-context, reserve a slot in context_xa but
> leave it NULL, the proto-context in the corresponding slot in
> proto_context_xa. Then, whenever we go to look up a context, we first
> check context_xa. If it's there, we return the i915_gem_context and
> we're done. If it's not, we look in proto_context_xa and, if we find it
> there, we create the actual context and kill the proto-context.
>
> In order for this dance to work properly, everything which ever touches
> a proto-context is guarded by drm_i915_file_private::proto_context_lock,
> including context creation. Yes, this means context creation now takes
> a giant global lock but it can't really be helped and that should never
> be on any driver's fast-path anyway.
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 211 ++
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 54 +
> .../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
> drivers/gpu/drm/i915/i915_drv.h | 24 +-
> 5 files changed, 239 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 8288af0d33245..f7c83730ee07f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -298,6 +298,42 @@ proto_context_create(struct drm_i915_private *i915,
> unsigned int flags)
> return err;
> }
>
> +static int proto_context_register_locked(struct drm_i915_file_private *fpriv,
> + struct i915_gem_proto_context *pc,
> + u32 *id)
> +{
> + int ret;
> + void *old;
> +
> + lockdep_assert_held(&fpriv->proto_context_lock);
> +
> + ret = xa_alloc(&fpriv->context_xa, id, NULL, xa_limit_32b, GFP_KERNEL);
> + if (ret)
> + return ret;
> +
> + old = xa_store(&fpriv->proto_context_xa, *id, pc, GFP_KERNEL);
> + if (xa_is_err(old)) {
> + xa_erase(&fpriv->context_xa, *id);
> + return xa_err(old);
> + }
> + GEM_BUG_ON(old);
I'd go with WARN_ON here. We just leak, and BUG_ON kills the box.
GEM_BUG_ON is for the additional gem consistency checks which are too
expensive to have enabled in production. Registering a proto context isn't
one of these things.
> +
> + return 0;
> +}
> +
> +static int proto_context_register(struct drm_i915_file_private *fpriv,
> + struct i915_gem_proto_context *pc,
> + u32 *id)
> +{
> + int ret;
> +
> + mutex_lock(&fpriv->proto_context_lock);
> + ret = proto_context_register_locked(fpriv, pc, id);
> + mutex_unlock(&fpriv->proto_context_lock);
> +
> + return ret;
> +}
> +
> static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
> struct i915_gem_proto_context *pc,
> const struct drm_i915_gem_context_param *args)
> @@ -1448,12 +1484,12 @@ void i915_gem_init__contexts(struct drm_i915_private
> *i915)
> init_contexts(&i915->gem.contexts);
> }
>
> -static int gem_context_register(struct i915_gem_context *ctx,
> - struct drm_i915_file_private *fpriv,
> - u32 *id)
> +static void gem_context_register(struct i915_gem_context *ctx,
>
Re: [Intel-gfx] [PATCH 1/1] drm/i915/hdcp: Simplify code in intel_hdcp_auth_downstream()
On Fri, 28 May 2021, "Leizhen (ThunderTown)" wrote:
> On 2021/5/27 18:04, Jani Nikula wrote:
>> On Thu, 27 May 2021, Zhen Lei wrote:
>>> If intel_hdcp_validate_v_prime() has been successful within the allowed
>>> number of tries, we can directly call drm_dbg_kms() and "goto out" without
>>> jumping out of the loop and repeatedly judging whether the operation is
>>> successful. This can help us reduce an unnecessary if judgment. And it's
>>> a little clearer to read.
>>
>> Generally I think the "happy day scenario" should be at the topmost
>> indentation level and not buried in the ifs with a goto exit.
>
> for (xxx) {
>if (a == b)
>return found;
> }
>
> At least this way of writing is common.
Yes, if the loop is abstracted to a separate function.
BR,
Jani.
>
>
>>
>> BR,
>> Jani.
>>
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Zhen Lei
>>> ---
>>> drivers/gpu/drm/i915/display/intel_hdcp.c | 24 ++-
>>> 1 file changed, 10 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
>>> b/drivers/gpu/drm/i915/display/intel_hdcp.c
>>> index d8570e14fe60..c32a854eda66 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
>>> @@ -663,13 +663,13 @@ int intel_hdcp_auth_downstream(struct intel_connector
>>> *connector)
>>>
>>> ret = shim->read_ksv_fifo(dig_port, num_downstream, ksv_fifo);
>>> if (ret)
>>> - goto err;
>>> + goto out;
>>>
>>> if (drm_hdcp_check_ksvs_revoked(&dev_priv->drm, ksv_fifo,
>>> num_downstream) > 0) {
>>> drm_err(&dev_priv->drm, "Revoked Ksv(s) in ksv_fifo\n");
>>> ret = -EPERM;
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> /*
>>> @@ -680,20 +680,16 @@ int intel_hdcp_auth_downstream(struct intel_connector
>>> *connector)
>>> ret = intel_hdcp_validate_v_prime(connector, shim,
>>> ksv_fifo, num_downstream,
>>> bstatus);
>>> - if (!ret)
>>> - break;
>>> - }
>>> -
>>> - if (i == tries) {
>>> - drm_dbg_kms(&dev_priv->drm,
>>> - "V Prime validation failed.(%d)\n", ret);
>>> - goto err;
>>> + if (!ret) {
>>> + drm_dbg_kms(&dev_priv->drm,
>>> + "HDCP is enabled (%d downstream devices)\n",
>>> + num_downstream);
>>> + goto out;
>>> + }
>>> }
>>>
>>> - drm_dbg_kms(&dev_priv->drm, "HDCP is enabled (%d downstream devices)\n",
>>> - num_downstream);
>>> - ret = 0;
>>> -err:
>>> + drm_dbg_kms(&dev_priv->drm, "V Prime validation failed.(%d)\n", ret);
>>> +out:
>>> kfree(ksv_fifo);
>>> return ret;
>>> }
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/display: Add support of MOD_Y_TILED during fb init
Adding Y_TILED modifier which is needed to support DRM_FORMAT_NV12
during framebuffer initialization.
Signed-off-by: Sodhi, Vunny
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index caf0414..a9b1b62 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11610,8 +11610,10 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
if (tiling == I915_TILING_X) {
mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
} else if (tiling == I915_TILING_Y) {
+ mode_cmd->modifier[0] = I915_FORMAT_MOD_Y_TILED;
+ } else {
drm_dbg_kms(&dev_priv->drm,
- "No Y tiling for legacy addfb\n");
+ "Unsupported tiling for legacy addfb\n");
goto err;
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 00/15] Move LMEM (VRAM) management over to TTM
This is an initial patch series to move discrete memory management over to TTM. It will be followed up shortly with adding more functionality. The buddy allocator is temporarily removed along with its selftests and It is replaced with the TTM range manager and some selftests are adjusted to account for introduced fragmentation. Work is ongoing to reintroduce the buddy allocator as a TTM resource manager. A new memcpy ttm move is introduced that uses kmap_local() functionality rather than vmap(). Among other things stated in the patch commit message it helps us deal with page-pased LMEM memory. It is generic enough to replace the ttm memcpy move with some additional work if so desired. On x86 it also enables prefetching reads from write-combined memory. Finally the old i915 gem object LMEM backend is replaced with a i915 gem object TTM backend and some additional i915 gem object ops are introduced to support the added functionality. Currently it is used only to support management and eviction of the LMEM region, but work is underway to extend the support to system memory. In this way we use TTM the way it was originally intended, having the GPU binding taken care of by driver code. Intention is to follow up with - System memory support - Pipelined accelerated moves / migration - Re-added buddy allocator in the TTM framework v2: - Add patches to move pagefaulting over to TTM - Break out TTM changes to separate patches - Address various review comments as detailed in the affected patches v3: - Drop TTM pagefaulting patches for now due changing approach due to a NAK. - Address feedback on TTM patches - Move the new TTM memcpy functionality into TTM. - Move fast WC memcpy to drm - Various fixes all over the place as shown in patch commit messages. v4: - Re-add TTM pagefaulting patches. - Addressed review feedback mainly from Matthew Auld - Fixed the mock ttm device code that was using an incorrect approach. v5: - Cleanups in the TTM pagefaulting patches. - Just add the WC memcpy to DRM without removing from i915 (Suggested by Daniel Vetter). - Various minor fixes as reported in patch log messages. v6: - Fix a merge conflict causing build error. v7: - Fix the WC memcpy compilation and perform a fallback memcpy in addition to warning in interrupt (Suggested by Christian König) - Renistate check for ttm_tt_is_populated() on swapout. Cc: Christian König Maarten Lankhorst (3): drm/i915: Disable mmap ioctl for gen12+ drm/vma: Add a driver_private member to vma_node. drm/i915: Use ttm mmap handling for ttm bo's. Thomas Hellström (12): drm/i915: Untangle the vma pages_mutex drm/i915: Don't free shared locks while shared drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages drm/i915/ttm Initialize the ttm device and memory managers drm/i915/ttm: Embed a ttm buffer object in the i915 gem object drm/ttm: Add a generic TTM memcpy move for page-based iomem drm: Add a prefetching memcpy_from_wc drm/ttm: Use drm_memcpy_from_wc for TTM bo moves drm/ttm: Document and optimize ttm_bo_pipeline_gutting() drm/ttm, drm/amdgpu: Allow the driver some control over swapping drm/i915/ttm: Introduce a TTM i915 gem object backend drm/i915/lmem: Verify checks for lmem residency Documentation/gpu/drm-mm.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 + drivers/gpu/drm/drm_cache.c | 147 drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_gem.c | 9 - drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 71 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 - drivers/gpu/drm/i915/gem/i915_gem_mman.c | 90 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 149 +++- drivers/gpu/drm/i915/gem/i915_gem_object.h| 19 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 52 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 126 +-- drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 - drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 647 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 48 ++ drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 90 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 +- drivers/gpu/drm/i915/gt/intel_gt.c| 2 - drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +- drivers/gpu/drm/i915/gt/in
[Intel-gfx] [PATCH v7 01/15] drm/i915: Untangle the vma pages_mutex
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index b319fd3f91cc..0f227f28b280 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -800,32 +800,37 @@ static bool try_qad_pin(struct i915_vma *vma, unsigned
int flags)
static int vma_get_pages(struct i915_vma *vma)
{
int err = 0;
+ bool pinned_pages = false;
if (atomic_add_unless(&vma->pages_count, 1, 0))
return 0;
+ if (vma->obj) {
+ err = i915_gem_object_pin_pages(vma->obj);
+ if (err)
+ return err;
+ pinned_pages = true;
+ }
+
/* Allocations ahoy! */
- if (mutex_lock_interruptible(&vma->pages_mutex))
- return -EINTR;
+ if (mutex_lock_interruptible(&vma->pages_mutex)) {
+ err = -EINTR;
+ goto unpin;
+ }
if (!atomic_read(&vma->pages_count)) {
- if (vma->obj) {
- err = i915_gem_object_pin_pages(vma->obj);
- if (err)
- goto unlock;
- }
-
err = vma->ops->set_pages(vma);
- if (err) {
- if (vma->obj)
- i915_gem_object_unpin_pages(vma->obj);
+ if (err)
goto unlock;
- }
+ pinned_pages = false;
}
atomic_inc(&vma->pages_count);
unlock:
mutex_unlock(&vma->pages_mutex);
+unpin:
+ if (pinned_pages)
+ __i915_gem_object_unpin_pages(vma->obj);
return err;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 02/15] drm/i915: Don't free shared locks while shared
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add an additional refcount, for GGTT we take additional
measures to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
v2: Try harder to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown.
v3: Use a pointer to the vm to indicate that an object shares a reservation
object from that vm, rather than a pointer to the reservation object itself.
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 28 +++-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 5 +++
7 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 28144410df86..2be6109d0093 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -252,6 +252,9 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
if (obj->mm.n_placements > 1)
kfree(obj->mm.placements);
+ if (obj->shares_resv_from)
+ i915_vm_resv_put(obj->shares_resv_from);
+
/* But keep the pointer alive for RCU-protected lookups */
call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
cond_resched();
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 0727d0c76aa0..0415f99b6b95 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -149,6 +149,10 @@ struct drm_i915_gem_object {
* when i915_gem_ww_ctx_backoff() or i915_gem_ww_ctx_fini() are called.
*/
struct list_head obj_link;
+ /**
+* @shared_resv_from: The object shares the resv from this vm.
+*/
+ struct i915_address_space *shares_resv_from;
union {
struct rcu_head rcu;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 35069ca5d7de..10c23a749a95 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -746,7 +746,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
mutex_unlock(&ggtt->vm.mutex);
i915_address_space_fini(&ggtt->vm);
- dma_resv_fini(&ggtt->vm.resv);
arch_phys_wc_del(ggtt->mtrr);
@@ -768,6 +767,19 @@ void i915_ggtt_driver_release(struct drm_i915_private
*i915)
ggtt_cleanup_hw(ggtt);
}
+/**
+ * i915_ggtt_driver_late_release - Cleanup of GGTT that needs to be done after
+ * all free objects have been drained.
+ * @i915: i915 device
+ */
+void i915_ggtt_driver_late_release(struct drm_i915_private *i915)
+{
+ struct i915_ggtt *ggtt = &i915->ggtt;
+
+ GEM_WARN_ON(kref_read(&ggtt->vm.resv_ref) != 1);
+ dma_resv_fini(&ggtt->vm._resv);
+}
+
static unsigned int gen6_get_total_gtt_size(u16 snb_gmch_ctl)
{
snb_gmch_ctl >>= SNB_GMCH_GGMS_SHIFT;
@@ -829,6 +841,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
return -ENOMEM;
}
+ kref_init(&ggtt->vm.resv_ref);
ret = setup_scratch_page(&ggtt->vm);
if (ret) {
drm_err(&i915->drm, "Scratch setup failed\n");
@@ -1135,7 +1148,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
ggtt->vm.gt = gt;
ggtt->vm.i915 = i915;
ggtt->vm.dma = i915->drm.dev;
- dma_resv_init(&ggtt->vm.resv);
+ dma_resv_init(&ggtt->vm._resv);
if (INTEL_GEN(i915) <= 5)
ret = i915_gmch_probe(ggtt);
@@ -1144,7 +1157,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
else
ret = gen8_gmch_probe(ggtt);
if (ret) {
- dma_resv_fini(&ggtt->vm.resv);
+ dma_resv_fini(&ggtt->vm._resv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 9b98f9d9faa3..94849567143d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -22,8 +22,11 @@ struct drm_i915_gem_object *alloc_pt_lmem(struct
i915_address_space *vm, int sz)
* object underneath, with the idea that one object_lock() will lock
* t
[Intel-gfx] [PATCH v7 03/15] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/i915_scatterlist.h | 16
4 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index ccede73c6465..616c3a2f1baf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -209,7 +209,7 @@ static int i915_gem_object_get_pages_dmabuf(struct
drm_i915_gem_object *obj)
if (IS_ERR(pages))
return PTR_ERR(pages);
- sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 51a05e62875d..be72ad0634ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -207,7 +207,7 @@ static int i915_gem_object_shmem_to_phys(struct
drm_i915_gem_object *obj)
err_xfer:
if (!IS_ERR_OR_NULL(pages)) {
- unsigned int sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ unsigned int sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index a657b99ec760..602f0ed983ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -173,7 +173,7 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
goto err;
}
- sg_page_sizes = i915_sg_page_sizes(st->sgl);
+ sg_page_sizes = i915_sg_dma_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 9cb26a224034..b96baad66a3a 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -101,15 +101,23 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
(((__iter).curr += PAGE_SIZE) >= (__iter).max) ? \
(__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0 : 0)
-static inline unsigned int i915_sg_page_sizes(struct scatterlist *sg)
+/**
+ * i915_sg_dma_sizes - Record the dma segment sizes of a scatterlist
+ * @sg: The scatterlist
+ *
+ * Return: An unsigned int with segment sizes logically or'ed together.
+ * A caller can use this information to determine what hardware page table
+ * entry sizes can be used to map the memory represented by the scatterlist.
+ */
+static inline unsigned int i915_sg_dma_sizes(struct scatterlist *sg)
{
unsigned int page_sizes;
page_sizes = 0;
- while (sg) {
+ while (sg && sg_dma_len(sg)) {
GEM_BUG_ON(sg->offset);
- GEM_BUG_ON(!IS_ALIGNED(sg->length, PAGE_SIZE));
- page_sizes |= sg->length;
+ GEM_BUG_ON(!IS_ALIGNED(sg_dma_len(sg), PAGE_SIZE));
+ page_sizes |= sg_dma_len(sg);
sg = __sg_next(sg);
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 05/15] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other backends.
To make this a bit more storage efficient for the other backends,
we'd have to use a pointer for the gem object which would require
a lot of changes in the driver. We postpone that for later.
Signed-off-by: Thomas Hellström
Acked-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 7 +++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2be6109d0093..5706d471692d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -62,6 +62,13 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key, unsigned flags)
{
+ /*
+* A gem object is embedded both in a struct ttm_buffer_object :/ and
+* in a drm_i915_gem_object. Make sure they are aliased.
+*/
+ BUILD_BUG_ON(offsetof(typeof(*obj), base) !=
+offsetof(typeof(*obj), __do_not_access.base));
+
spin_lock_init(&obj->vma.lock);
INIT_LIST_HEAD(&obj->vma.list);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index f5b46d11e6e6..d047ea126029 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include "i915_active.h"
@@ -99,7 +100,16 @@ struct i915_gem_object_page_iter {
};
struct drm_i915_gem_object {
- struct drm_gem_object base;
+ /*
+* We might have reason to revisit the below since it wastes
+* a lot of space for non-ttm gem objects.
+* In any case, always use the accessors for the ttm_buffer_object
+* when accessing it.
+*/
+ union {
+ struct drm_gem_object base;
+ struct ttm_buffer_object __do_not_access;
+ };
const struct drm_i915_gem_object_ops *ops;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 08/15] drm/ttm: Use drm_memcpy_from_wc for TTM bo moves
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König #v4
--
v4:
- Clarify when we try drm_memcpy_from_wc_dbm (Reported by Matthew Auld)
- Be paranoid about when drm_memcpy_from_wc_dbm may fail (Reported by
Matthew Auld)
v5:
- Rebase on change to drm_memcpy_from_wc (Suggested by Daniel Vetter)
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6ac7744a1a5c..a46f705ba78b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -118,22 +119,8 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
dst_ops->map_local(dst_iter, &dst_map, i);
src_ops->map_local(src_iter, &src_map, i);
- if (!src_map.is_iomem && !dst_map.is_iomem) {
- memcpy(dst_map.vaddr, src_map.vaddr, PAGE_SIZE);
- } else if (!src_map.is_iomem) {
- dma_buf_map_memcpy_to(&dst_map, src_map.vaddr,
- PAGE_SIZE);
- } else if (!dst_map.is_iomem) {
- memcpy_fromio(dst_map.vaddr, src_map.vaddr_iomem,
- PAGE_SIZE);
- } else {
- int j;
- u32 __iomem *src = src_map.vaddr_iomem;
- u32 __iomem *dst = dst_map.vaddr_iomem;
-
- for (j = 0; j < (PAGE_SIZE / sizeof(u32)); ++j)
- iowrite32(ioread32(src++), dst++);
- }
+ drm_memcpy_from_wc(&dst_map, &src_map, PAGE_SIZE);
+
if (src_ops->unmap_local)
src_ops->unmap_local(src_iter, &src_map);
if (dst_ops->unmap_local)
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 04/15] drm/i915/ttm Initialize the ttm device and memory managers
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lmem_get_pages() (Reported by Matthew Auld)
- Break out and modify usage of i915_sg_dma_sizes() (Reported by Mattew Auld)
- Break out TTM changes to a separate patch (Reported by Christian König)
v3:
- Fix the same error unwind in mock_region_get_pages()
(Reported by Matthew Auld)
- Don't rely on new TTM functionality, but create a mock TTM device,
(Reported by Christian König)
v4:
- Use mock_gem_device rather than creating a separate ttm_device per
region.
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 59 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 120 ---
drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 -
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 -
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 27 +-
drivers/gpu/drm/i915/i915_buddy.c | 435 --
drivers/gpu/drm/i915/i915_buddy.h | 131 ---
drivers/gpu/drm/i915/i915_drv.c | 8 +
drivers/gpu/drm/i915/i915_drv.h | 8 +-
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_globals.c | 1 -
drivers/gpu/drm/i915/i915_globals.h | 1 -
drivers/gpu/drm/i915/i915_scatterlist.c | 70 ++
drivers/gpu/drm/i915/i915_scatterlist.h | 4 +
drivers/gpu/drm/i915/intel_memory_region.c| 180 ++--
drivers/gpu/drm/i915/intel_memory_region.h| 44 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 220 +
drivers/gpu/drm/i915/intel_region_ttm.h | 32 +
drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 --
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
.../drm/i915/selftests/intel_memory_region.c | 133 +--
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 +
drivers/gpu/drm/i915/selftests/mock_region.c | 70 +-
30 files changed, 631 insertions(+), 1754 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.c
create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.h
delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 93f4d059fc89..61ff5c178714 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -27,6 +27,7 @@ config DRM_I915
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
select VMAP_PFN
+ select DRM_TTM
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6947495bf34b..4f22cac1c49b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -50,6 +50,7 @@ i915-y += i915_drv.o \
intel_memory_region.o \
intel_pch.o \
intel_pm.o \
+ intel_region_ttm.o \
intel_runtime_pm.o \
intel_sideband.o \
intel_step.o \
@@ -160,7 +161,6 @@ gem-y += \
i915-y += \
$(gem-y) \
i915_active.o \
- i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
i915_gem_gtt.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index f44bdd08f7cb..3b4aa28a076d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -4,16 +4,71 @@
*/
#include "intel_memory_region.h"
+#include "intel_region_ttm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
+static void lmem_put_pages(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
+{
+ intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node);
+ obj->mm.dirty = false;
+ sg_free_table(pages);
+ kfree(pages);
+}
+
+static int lmem_get_pages(struct drm_i915_gem_object *obj)
+{
+ unsigned int flags;
+ struct sg_table *pages;
+
+ flags = I915_ALLOC_MIN_PAGE_SIZE;
+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
+ flags |= I915_ALLOC_CONTIGUOUS;
+
+ obj->mm.st_mm_node = intel_region_ttm_node_alloc(obj->mm.region,
+
[Intel-gfx] [PATCH v7 07/15] drm: Add a prefetching memcpy_from_wc
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to use a fast prefetching memcpy and
otherwise falls back to ordinary memcopies, taking the iomem tagging
into account.
The code is largely copied from i915_memcpy_from_wc.
Cc: Daniel Vetter
Cc: Christian König
Suggested-by: Daniel Vetter
Signed-off-by: Thomas Hellström
---
v7:
- Perform a memcpy even if warning with in_interrupt(). Suggested by
Christian König.
- Fix compilation failure on !X86 (Reported by kernel test robot
l...@intel.com)
---
Documentation/gpu/drm-mm.rst | 2 +-
drivers/gpu/drm/drm_cache.c | 147 +++
drivers/gpu/drm/drm_drv.c| 2 +
include/drm/drm_cache.h | 7 ++
4 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 21be6deadc12..c66058c5bce7 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -469,7 +469,7 @@ DRM MM Range Allocator Function References
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
-DRM Cache Handling
+DRM Cache Handling and Fast WC memcpy()
==
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 79a50ef1250f..b887d7dec8b8 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -28,6 +28,7 @@
* Authors: Thomas Hellström
*/
+#include
#include
#include
#include
@@ -35,6 +36,9 @@
#include
+/* A small bounce buffer that fits on the stack. */
+#define MEMCPY_BOUNCE_SIZE 128
+
#if defined(CONFIG_X86)
#include
@@ -209,3 +213,146 @@ bool drm_need_swiotlb(int dma_bits)
return max_iomem > ((u64)1 << dma_bits);
}
EXPORT_SYMBOL(drm_need_swiotlb);
+
+static void memcpy_fallback(struct dma_buf_map *dst,
+ const struct dma_buf_map *src,
+ unsigned long len)
+{
+ if (!dst->is_iomem && !src->is_iomem) {
+ memcpy(dst->vaddr, src->vaddr, len);
+ } else if (!src->is_iomem) {
+ dma_buf_map_memcpy_to(dst, src->vaddr, len);
+ } else if (!dst->is_iomem) {
+ memcpy_fromio(dst->vaddr, src->vaddr_iomem, len);
+ } else {
+ /*
+* Bounce size is not performance tuned, but using a
+* bounce buffer like this is significantly faster than
+* resorting to ioreadxx() + iowritexx().
+*/
+ char bounce[MEMCPY_BOUNCE_SIZE];
+ void __iomem *_src = src->vaddr_iomem;
+ void __iomem *_dst = dst->vaddr_iomem;
+
+ while (len >= MEMCPY_BOUNCE_SIZE) {
+ memcpy_fromio(bounce, _src, MEMCPY_BOUNCE_SIZE);
+ memcpy_toio(_dst, bounce, MEMCPY_BOUNCE_SIZE);
+ _src += MEMCPY_BOUNCE_SIZE;
+ _dst += MEMCPY_BOUNCE_SIZE;
+ len -= MEMCPY_BOUNCE_SIZE;
+ }
+ if (len) {
+ memcpy_fromio(bounce, _src, MEMCPY_BOUNCE_SIZE);
+ memcpy_toio(_dst, bounce, MEMCPY_BOUNCE_SIZE);
+ }
+ }
+}
+
+#ifdef CONFIG_X86
+
+static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
+
+static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
+{
+ kernel_fpu_begin();
+
+ while (len >= 4) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movntdqa 16(%0), %%xmm1\n"
+ "movntdqa 32(%0), %%xmm2\n"
+ "movntdqa 48(%0), %%xmm3\n"
+ "movaps %%xmm0, (%1)\n"
+ "movaps %%xmm1, 16(%1)\n"
+ "movaps %%xmm2, 32(%1)\n"
+ "movaps %%xmm3, 48(%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 64;
+ dst += 64;
+ len -= 4;
+ }
+ while (len--) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movaps %%xmm0, (%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 16;
+ dst += 16;
+ }
+
+ kernel_fpu_end();
+}
+
+/*
+ * __drm_memcpy_from_wc copies @len bytes from @src to @dst using
+ * non-temporal instructions where available. Note that all arguments
+ * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
+ * of 16.
+ */
+static void __drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
+{
+ if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
+ memcpy(dst, src, len);
+ else if (likely(len))
+ __memcpy_ntdqa(dst, src, len >> 4);
+}
+
+/**
+ * drm_memcpy_from_wc - Perform the fastest available memcpy from a
[Intel-gfx] [PATCH v7 10/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped out,
in which case the drivers normal eviction_valuable path is run.
Reviewed-by: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Thomas Hellström
Acked-by: Christian König
---
v3:
- Don't export ttm_tt_unpopulate
- Fix confusion reading the locked pointer instead of the value
pointed to in ttm_bo_evict_swapout_allowable (Reported by
Maarten Lankhorst)
v5:
- Use memset() rather than = {} (Suggested by Christian König)
- Remove check for ttm_tt_is_populated in the swapout code in the hope
it will be fixed elsewhere (Suggested by Christian König)
v7:
- Re-add the check for ttm_tt_is_populated in the swapout code.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +++
drivers/gpu/drm/ttm/ttm_bo.c| 46 -
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 80437b6ba5f3..5116065748a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1328,6 +1328,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
struct dma_fence *f;
int i;
+ /* Swapout? */
+ if (bo->mem.mem_type == TTM_PL_SYSTEM)
+ return true;
+
if (bo->type == ttm_bo_type_kernel &&
!amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)))
return false;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index be0406466460..98c41bf6a07d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
+ dma_resv_assert_held(bo->base.resv);
+ if (bo->mem.mem_type == TTM_PL_SYSTEM)
+ return true;
+
/* Don't evict this BO if it's outside of the
* requested placement range
*/
@@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
- struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
+ struct ttm_operation_ctx *ctx,
+ const struct ttm_place *place,
+ bool *locked, bool *busy)
{
bool ret = false;
@@ -576,6 +582,14 @@ static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
*busy = !ret;
}
+ if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) {
+ ret = false;
+ if (*locked) {
+ dma_resv_unlock(bo->base.resv);
+ *locked = false;
+ }
+ }
+
return ret;
}
@@ -630,20 +644,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
list_for_each_entry(bo, &man->lru[i], lru) {
bool busy;
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked,
- &busy)) {
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
+ &locked, &busy)) {
if (busy && !busy_bo && ticket !=
dma_resv_locking_ctx(bo->base.resv))
busy_bo = bo;
continue;
}
- if (place && !bdev->funcs->eviction_valuable(bo,
- place)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
if (!ttm_bo_get_unless_zero(bo)) {
if (locked)
dma_resv_unlock(bo->base.resv);
@@ -1140,10 +1148,19 @@ EXPORT_SYMBOL(ttm_bo_wait);
int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
gfp_t gfp_flags)
{
+ struct ttm_place place;
bool locked;
int re
[Intel-gfx] [PATCH v7 09/15] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the call to ttm_tt_create() fails.
Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict().
Cc: Christian König
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
---
v4:
- Clarify why we mark bo for clearing after ttm_bo_pipeline_gutting()
(Reported by Matthew Auld)
v5:
- Make ttm_tt_mark_for_clear() inline (Suggested by Christian König)
---
drivers/gpu/drm/ttm/ttm_bo.c | 20 +--
drivers/gpu/drm/ttm/ttm_bo_util.c | 55 ---
include/drm/ttm/ttm_tt.h | 13
3 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 51a94fd63bd7..be0406466460 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bdev->funcs->evict_flags(bo, &placement);
if (!placement.num_placement && !placement.num_busy_placement) {
- ttm_bo_wait(bo, false, false);
+ ret = ttm_bo_wait(bo, true, false);
+ if (ret)
+ return ret;
- ttm_bo_cleanup_memtype_use(bo);
- return ttm_tt_create(bo, false);
+ /*
+* Since we've already synced, this frees backing store
+* immediately.
+*/
+ return ttm_bo_pipeline_gutting(bo);
}
ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx);
@@ -976,13 +981,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
* Remove the backing store if no placement is given.
*/
- if (!placement->num_placement && !placement->num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement->num_placement && !placement->num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
/*
* Check whether we need to move buffer.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index a46f705ba78b..99819c68d8d2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -565,26 +565,73 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
*bo,
}
EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
+/**
+ * ttm_bo_pipeline_gutting - purge the contents of a bo
+ * @bo: The buffer object
+ *
+ * Purge the contents of a bo, async if the bo is not idle.
+ * After a successful call, the bo is left unpopulated in
+ * system placement. The function may wait uninterruptible
+ * for idle on OOM.
+ *
+ * Return: 0 if successful, negative error code on failure.
+ */
int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
+ struct ttm_tt *ttm;
int ret;
- ret = ttm_buffer_object_transfer(bo, &ghost);
+ /* If already idle, no need for ghost object dance. */
+ ret = ttm_bo_wait(bo, false, true);
+ if (ret != -EBUSY) {
+ if (!bo->ttm) {
+ /* See comment below about clearing. */
+ ret = ttm_tt_create(bo, true);
+ if (ret)
+ return ret;
+ } else {
+ ttm_tt_unpopulate(bo->bdev, bo->ttm);
+ if (bo->type == ttm_bo_type_device)
+ ttm_tt_mark_for_clear(bo->ttm);
+ }
+ ttm_resource_free(bo, &bo->mem);
+ ttm_resource_alloc(bo, &sys_mem, &bo->mem);
+
+ return 0;
+ }
+
+ /*
+* We need an unpopulated ttm_tt after giving our current one,
+* if any, to the ghost object. And we can't afford to fail
+* creating one *after* the operation. If the bo subsequently gets
+* resurrected, make sure it's cleared (if ttm_bo_type_device)
+* to avoid leaking sensitive information to user-space.
+*/
+
+ ttm = bo->ttm;
+ bo->ttm = NULL;
+ ret = ttm_tt_create(bo, true);
+ swap(bo->ttm, ttm);
if (ret)
return ret;
+ ret = ttm_buffer_object_transfer(bo, &ghost);
+ if (ret) {
+ ttm_tt_destroy(bo->bdev, ttm);
+ return ret;
+ }
+
ret = dma_resv_copy_fences(&ghost->base._resv, bo->base.resv);
/* Last resort, wait for the BO to be idle when we are OOM */
if (ret)
ttm_bo_wait(bo,
[Intel-gfx] [PATCH v7 11/15] drm/i915/ttm: Introduce a TTM i915 gem object backend
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects) is not
visible to i915 GEM yet. The plan is to move the i915 gem system region
over to the TTM system memory type in upcoming patches.
We set up GPU bindings directly both from LMEM and from the system region,
as there is no need to use the legacy TTM_TT memory type. We reserve
that for future porting of GGTT bindings to TTM.
Remove the old lmem backend.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Break out needed TTM functionality to a separate patch (Reported by
Christian König).
- Fix an unhandled error (Reported by Matthew Auld and Maarten Lankhorst)
- Remove a stray leftover sg_table allocation (Reported by Matthew Auld)
- Use ttm_tt_unpopulate() rather than ttm_tt_destroy() in the purge path
as some TTM functionality relies on having a ttm_tt present for !is_iomem.
v3:
- Use ttm_bo_type_device for userspace visible objects so that TTM can
allocate an address space offset for mmap'ing.
- Fix up the destruction path (Reported by Matthew Auld)
- Use ttm_bo_validate() for purging (Reported by Christian König)
- Create ttm_tts write-combined as they are currently for eviction only and
we want to maintain consistent write-combined caching for bos that are
not in system only. (Suggested by Daniel Vetter)
- Make struct ttm_placements static.
- Add the ttm device funcs/ops to i915_gem_ttm.h for the region code.
- Rename new->dst and old->src. Check for swapin in the move callback.
v4:
- Adapt to small interface change in ttm_move_memcpy.
- Use a function to pull out the ttm driver from the backend.
v6:
- Remove the ttm device verify_access assignment. The member is gone
upstream.
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 84 ---
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_object.c| 125 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 9 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 540 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 48 ++
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 5 +-
drivers/gpu/drm/i915/intel_memory_region.c| 1 -
drivers/gpu/drm/i915/intel_memory_region.h| 1 -
drivers/gpu/drm/i915/intel_region_ttm.c | 8 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 11 +-
16 files changed, 730 insertions(+), 153 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f22cac1c49b..f57dfc74d6ce 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,6 +155,7 @@ gem-y += \
gem/i915_gem_stolen.o \
gem/i915_gem_throttle.o \
gem/i915_gem_tiling.o \
+ gem/i915_gem_ttm.o \
gem/i915_gem_userptr.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 548ddf39d853..93bf63bbaff1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -85,13 +85,10 @@ i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
return -E2BIG;
/*
-* For now resort to CPU based clearing for device local-memory, in the
-* near future this will use the blitter engine for accelerated, GPU
-* based clearing.
+* I915_BO_ALLOC_USER will make sure the object is cleared before
+* any user access.
*/
- flags = 0;
- if (mr->type == INTEL_MEMORY_LOCAL)
- flags = I915_BO_ALLOC_CPU_CLEAR;
+ flags = I915_BO_ALLOC_USER;
ret = mr->ops->init_object(mr, obj, size, flags);
if (ret)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 3b4aa28a076d..2b8cd15de1d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -4,74 +4,10 @@
*/
#include "intel_memory_region.h"
-#include "intel_region_ttm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
-static void lmem_put_pages(struct drm_i915_gem_object *obj,
- struct sg_table *pages)
-{
- intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node);
- obj->mm.dirty = false;
- sg_free_
[Intel-gfx] [PATCH v7 06/15] drm/ttm: Add a generic TTM memcpy move for page-based iomem
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional global
TLB flushes of ioremap() and consuming ioremap space, elimination of a
critical point of failure and with a slight change of semantics we could
also push the memcpy out async for testing and async driver development
purposes.
A special linear iomem iterator is introduced internally to mimic the
old ioremap behaviour for code-paths that can't immediately be ported
over. This adds to the code size and should be considered a temporary
solution.
Looking at the code we have a lot of checks for iomap tagged pointers.
Ideally we should extend the core memremap functions to also accept
uncached memory and kmap_local functionality. Then we could strip a
lot of code.
Cc: Christian König
Signed-off-by: Thomas Hellström
---
v3:
- Split up in various TTM files and addressed review comments by
Christian König. Tested and fixed legacy iomap memcpy path on i915.
v4:
- Fix an uninitialized variable
Reported by: kernel test robot
Reported by: Dan Carpenter
- Minor change to the ttm_move_memcpy() interface.
- Gracefully handle lack of memremap() support on memcpy
(Reported by Matthew Auld)
- Minor style fix (Reported by Matthew Auld)
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 280 ++---
drivers/gpu/drm/ttm/ttm_module.c | 35
drivers/gpu/drm/ttm/ttm_resource.c | 193
drivers/gpu/drm/ttm/ttm_tt.c | 42 +
include/drm/ttm/ttm_bo_driver.h| 28 +++
include/drm/ttm/ttm_caching.h | 2 +
include/drm/ttm/ttm_kmap_iter.h| 61 +++
include/drm/ttm/ttm_resource.h | 61 +++
include/drm/ttm/ttm_tt.h | 16 ++
9 files changed, 536 insertions(+), 182 deletions(-)
create mode 100644 include/drm/ttm/ttm_kmap_iter.h
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ae8b61460724..6ac7744a1a5c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device *bdev,
mem->bus.addr = NULL;
}
-static int ttm_resource_ioremap(struct ttm_device *bdev,
- struct ttm_resource *mem,
- void **virtual)
+/**
+ * ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
+ * @bo: The struct ttm_buffer_object.
+ * @new_mem: The struct ttm_resource we're moving to (copy destination).
+ * @new_iter: A struct ttm_kmap_iter representing the destination resource.
+ * @src_iter: A struct ttm_kmap_iter representing the source resource.
+ *
+ * This function is intended to be able to move out async under a
+ * dma-fence if desired.
+ */
+void ttm_move_memcpy(struct ttm_buffer_object *bo,
+pgoff_t num_pages,
+struct ttm_kmap_iter *dst_iter,
+struct ttm_kmap_iter *src_iter)
{
- int ret;
- void *addr;
-
- *virtual = NULL;
- ret = ttm_mem_io_reserve(bdev, mem);
- if (ret || !mem->bus.is_iomem)
- return ret;
+ const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
+ const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
+ struct ttm_tt *ttm = bo->ttm;
+ struct dma_buf_map src_map, dst_map;
+ pgoff_t i;
- if (mem->bus.addr) {
- addr = mem->bus.addr;
- } else {
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ /* Single TTM move. NOP */
+ if (dst_ops->maps_tt && src_ops->maps_tt)
+ return;
- if (mem->bus.caching == ttm_write_combined)
- addr = ioremap_wc(mem->bus.offset, bus_size);
-#ifdef CONFIG_X86
- else if (mem->bus.caching == ttm_cached)
- addr = ioremap_cache(mem->bus.offset, bus_size);
-#endif
- else
- addr = ioremap(mem->bus.offset, bus_size);
- if (!addr) {
- ttm_mem_io_free(bdev, mem);
- return -ENOMEM;
+ /* Don't move nonexistent data. Clear destination instead. */
+ if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
+ if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+ return;
+
+ for (i = 0; i < num_pages; ++i) {
+ dst_ops->map_local(dst_iter, &dst_map, i);
+ if (dst_map.is_iomem)
+ memset_io(dst_map.vaddr_iomem, 0, PAGE_SIZE);
+ else
+ memset(dst_map.vaddr, 0, PAGE_SIZE);
+
[Intel-gfx] [PATCH v7 13/15] drm/i915: Disable mmap ioctl for gen12+
From: Maarten Lankhorst
The platform should exclusively use mmap_offset, one less path to worry
about for discrete.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index f6fe5cb01438..fd1c9714f8d8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -56,10 +56,17 @@ int
i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
+ struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_mmap *args = data;
struct drm_i915_gem_object *obj;
unsigned long addr;
+ /* mmap ioctl is disallowed for all platforms after TGL-LP. This also
+* covers all platforms with local memory.
+*/
+ if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
+ return -EOPNOTSUPP;
+
if (args->flags & ~(I915_MMAP_WC))
return -EINVAL;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 12/15] drm/i915/lmem: Verify checks for lmem residency
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by Mattew Auld)
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 42 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 18 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++
4 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index caf0414e0b50..f947295d7e53 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11756,7 +11756,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 2b8cd15de1d9..d539dffa1554 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,10 +23,50 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
}
+/**
+ * i915_gem_object_validates_to_lmem - Whether the object is resident in
+ * lmem when pages are present.
+ * @obj: The object to check.
+ *
+ * Migratable objects residency may change from under us if the object is
+ * not pinned or locked. This function is intended to be used to check whether
+ * the object can only reside in lmem when pages are present.
+ *
+ * Return: Whether the object is always resident in lmem when pages are
+ * present.
+ */
+bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+ return !i915_gem_object_migratable(obj) &&
+ mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
+}
+
+/**
+ * i915_gem_object_is_lmem - Whether the object is resident in
+ * lmem
+ * @obj: The object to check.
+ *
+ * Even if an object is allowed to migrate and change memory region,
+ * this function checks whether it will always be present in lmem when
+ * valid *or* if that's not the case, whether it's currently resident in lmem.
+ * For migratable and evictable objects, the latter only makes sense when
+ * the object is locked.
+ *
+ * Return: Whether the object migratable but resident in lmem, or not
+ * migratable and will be present in lmem when valid.
+ */
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
- struct intel_memory_region *mr = obj->mm.region;
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+#ifdef CONFIG_LOCKDEP
+ if (i915_gem_object_migratable(obj) &&
+ i915_gem_object_evictable(obj))
+ assert_object_held(obj);
+#endif
return mr && (mr->type == INTEL_MEMORY_LOCAL ||
mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 16eac5ea9238..cf18c430d51f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -457,6 +457,24 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object
*obj)
return pin_count == 0;
}
+/**
+ * i915_gem_object_migratable - Whether the object is migratable out of the
+ * current region.
+ * @obj: Pointer to the object.
+ *
+ * Return: Whether the object is allowed to be resident in other
+ * regions than the current while pages are present.
+ */
+bool i915_gem_object_migratable(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+ if (!mr)
+ return false;
+
+ return obj->mm.n_placements > 1;
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ae5930e307d5..a3ad8cf4eefd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -596,6 +596,10 @@ void __i915_gem_free_object(struct drm_i915_gem_object
*obj);
bool i915_gem_object_evictable(struct drm_i915_gem_object *obj);
+bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
+
+bool i915_gem_objec
[Intel-gfx] [PATCH v7 15/15] drm/i915: Use ttm mmap handling for ttm bo's.
From: Maarten Lankhorst
Use the ttm handlers for servicing page faults, and vm_access.
We do our own validation of read-only access, otherwise use the
ttm handlers as much as possible.
Because the ttm handlers expect the vma_node at vma->base, we slightly
need to massage the mmap handlers to look at vma_node->driver_private
to fetch the bo, if it's NULL, we assume i915's normal mmap_offset uapi
is used.
This is the easiest way to achieve compatibility without changing ttm's
semantics.
Signed-off-by: Maarten Lankhorst
- Fixed some minor style issues. (Thomas Hellström)
- Added a mutex Destroy (Thomas Hellström)
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 83
drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 121 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 90 ++---
drivers/gpu/drm/i915/selftests/igt_mmap.c | 25 +++-
drivers/gpu/drm/i915/selftests/igt_mmap.h | 12 +-
8 files changed, 251 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fd1c9714f8d8..d1de97e4adfd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -19,6 +19,7 @@
#include "i915_gem_mman.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
+#include "i915_gem_ttm.h"
#include "i915_vma.h"
static inline bool
@@ -622,6 +623,8 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
struct i915_mmap_offset *mmo;
int err;
+ GEM_BUG_ON(obj->ops->mmap_offset || obj->ops->mmap_ops);
+
mmo = lookup_mmo(obj, mmap_type);
if (mmo)
goto out;
@@ -664,40 +667,47 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
}
static int
-__assign_mmap_offset(struct drm_file *file,
-u32 handle,
+__assign_mmap_offset(struct drm_i915_gem_object *obj,
enum i915_mmap_type mmap_type,
-u64 *offset)
+u64 *offset, struct drm_file *file)
{
- struct drm_i915_gem_object *obj;
struct i915_mmap_offset *mmo;
- int err;
- obj = i915_gem_object_lookup(file, handle);
- if (!obj)
- return -ENOENT;
+ if (i915_gem_object_never_mmap(obj))
+ return -ENODEV;
- if (i915_gem_object_never_mmap(obj)) {
- err = -ENODEV;
- goto out;
+ if (obj->ops->mmap_offset) {
+ *offset = obj->ops->mmap_offset(obj);
+ return 0;
}
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i915_gem_object_has_struct_page(obj) &&
- !i915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM)) {
- err = -ENODEV;
- goto out;
- }
+ !i915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM))
+ return -ENODEV;
mmo = mmap_offset_attach(obj, mmap_type, file);
- if (IS_ERR(mmo)) {
- err = PTR_ERR(mmo);
- goto out;
- }
+ if (IS_ERR(mmo))
+ return PTR_ERR(mmo);
*offset = drm_vma_node_offset_addr(&mmo->vma_node);
- err = 0;
-out:
+ return 0;
+}
+
+static int
+__assign_mmap_offset_handle(struct drm_file *file,
+ u32 handle,
+ enum i915_mmap_type mmap_type,
+ u64 *offset)
+{
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ obj = i915_gem_object_lookup(file, handle);
+ if (!obj)
+ return -ENOENT;
+
+ err = __assign_mmap_offset(obj, mmap_type, offset, file);
i915_gem_object_put(obj);
return err;
}
@@ -717,7 +727,7 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
else
mmap_type = I915_MMAP_TYPE_GTT;
- return __assign_mmap_offset(file, handle, mmap_type, offset);
+ return __assign_mmap_offset_handle(file, handle, mmap_type, offset);
}
/**
@@ -785,7 +795,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void
*data,
return -EINVAL;
}
- return __assign_mmap_offset(file, args->handle, type, &args->offset);
+ return __assign_mmap_offset_handle(file, args->handle, type,
&args->offset);
}
static void vm_open(struct vm_area_struct *vma)
@@ -889,8 +899,18 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
* destroyed and will be invalid when the vma manager lock
* is released.
*/
- mmo = container_of(node, struct i915_mmap_offset, vma_node);
- obj = i915_gem_object_get_rcu(mmo->obj);
+ if (!node->driver_private) {
+ mmo = container_of(node, struct i915_mma
[Intel-gfx] [PATCH v7 14/15] drm/vma: Add a driver_private member to vma_node.
From: Maarten Lankhorst
This allows drivers to distinguish between different types of vma_node's.
The readonly flag was unused and is thus removed.
This is a temporary solution, until i915 is converted completely to
use ttm for bo's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
Acked-by: Daniel Vetter #irc
---
drivers/gpu/drm/drm_gem.c | 9 -
include/drm/drm_vma_manager.h | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9989425e9875..e710e79069f6 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1149,15 +1149,6 @@ int drm_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return -EACCES;
}
- if (node->readonly) {
- if (vma->vm_flags & VM_WRITE) {
- drm_gem_object_put(obj);
- return -EINVAL;
- }
-
- vma->vm_flags &= ~VM_MAYWRITE;
- }
-
ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT,
vma);
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 76ac5e97a559..4f8c35206f7c 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -53,7 +53,7 @@ struct drm_vma_offset_node {
rwlock_t vm_lock;
struct drm_mm_node vm_node;
struct rb_root vm_files;
- bool readonly:1;
+ void *driver_private;
};
struct drm_vma_offset_manager {
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Add support of MOD_Y_TILED during fb init
== Series Details == Series: drm/i915/display: Add support of MOD_Y_TILED during fb init URL : https://patchwork.freedesktop.org/series/90785/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10152 -> Patchwork_20237 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20237 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20237, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20237: ### IGT changes ### Possible regressions * igt@kms_addfb_basic@addfb25-bad-modifier: - fi-icl-y: [PASS][1] -> [FAIL][2] +38 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-icl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-icl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html * igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] +38 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-kbl-7500u/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-kbl-7500u/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html * igt@kms_addfb_basic@addfb25-modifier-no-flag: - fi-cfl-guc: [PASS][5] -> [FAIL][6] +38 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cfl-guc/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-cfl-guc/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html - fi-ilk-650: [PASS][7] -> [FAIL][8] +37 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-ilk-650/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-ilk-650/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html * igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy: - fi-tgl-u2: [PASS][9] -> [FAIL][10] +39 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-tgl-u2/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-tgl-u2/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-cml-s: [PASS][11] -> [FAIL][12] +39 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cml-s/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-cml-s/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_addfb_basic@bad-pitch-1024: - fi-bxt-dsi: [PASS][13] -> [FAIL][14] +38 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-bxt-dsi/igt@kms_addfb_ba...@bad-pitch-1024.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-bxt-dsi/igt@kms_addfb_ba...@bad-pitch-1024.html * igt@kms_addfb_basic@bad-pitch-128: - fi-cml-u2: [PASS][15] -> [FAIL][16] +39 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cml-u2/igt@kms_addfb_ba...@bad-pitch-128.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-cml-u2/igt@kms_addfb_ba...@bad-pitch-128.html * igt@kms_addfb_basic@bad-pitch-63: - fi-kbl-7567u: [PASS][17] -> [FAIL][18] +36 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-kbl-7567u/igt@kms_addfb_ba...@bad-pitch-63.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-kbl-7567u/igt@kms_addfb_ba...@bad-pitch-63.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - fi-snb-2520m: [PASS][19] -> [FAIL][20] +37 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-snb-2520m/igt@kms_addfb_ba...@basic-y-tiled-legacy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-snb-2520m/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@bo-too-small-due-to-tiling: - fi-icl-u2: [PASS][21] -> [FAIL][22] +39 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-icl-u2/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20237/fi-icl-u2/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html * igt@kms_addfb_basic@invalid-get-prop-any: - fi-skl-6600u: [PASS][23] -> [FAIL][24] +39 si
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90681/ State : warning == Summary == $ dim checkpatch origin/drm-tip 784db4b4d61c drm/i915: Untangle the vma pages_mutex 57182bbc1668 drm/i915: Don't free shared locks while shared 1a6c10a2a951 drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages de5421fafbfc drm/i915/ttm Initialize the ttm device and memory managers -:480: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #480: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1531 lines checked 851f1c6c1b99 drm/i915/ttm: Embed a ttm buffer object in the i915 gem object 6ac29bd06dfe drm/ttm: Add a generic TTM memcpy move for page-based iomem -:384: CHECK:ARCH_DEFINES: architecture specific defines should be avoided #384: FILE: drivers/gpu/drm/ttm/ttm_module.c:56: +#if defined(__i386__) || defined(__x86_64__) -:727: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #727: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 840 lines checked 6048fd3028d8 drm: Add a prefetching memcpy_from_wc a297381da04d drm/ttm: Use drm_memcpy_from_wc for TTM bo moves 9882bd03d3c0 drm/ttm: Document and optimize ttm_bo_pipeline_gutting() a823dad43aea drm/ttm, drm/amdgpu: Allow the driver some control over swapping fd5d88ee0ada drm/i915/ttm: Introduce a TTM i915 gem object backend -:449: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #449: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1042 lines checked f61f3ba4771f drm/i915/lmem: Verify checks for lmem residency a0b8cfe41a79 drm/i915: Disable mmap ioctl for gen12+ 55f40bf04154 drm/vma: Add a driver_private member to vma_node. 9f4d36e7db77 drm/i915: Use ttm mmap handling for ttm bo's. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90681/ 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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdg
Re: [Intel-gfx] [PATCH v7 06/15] drm/ttm: Add a generic TTM memcpy move for page-based iomem
Am 31.05.21 um 14:19 schrieb Thomas Hellström:
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional global
TLB flushes of ioremap() and consuming ioremap space, elimination of a
critical point of failure and with a slight change of semantics we could
also push the memcpy out async for testing and async driver development
purposes.
A special linear iomem iterator is introduced internally to mimic the
old ioremap behaviour for code-paths that can't immediately be ported
over. This adds to the code size and should be considered a temporary
solution.
Looking at the code we have a lot of checks for iomap tagged pointers.
Ideally we should extend the core memremap functions to also accept
uncached memory and kmap_local functionality. Then we could strip a
lot of code.
Cc: Christian König
Signed-off-by: Thomas Hellström
---
v3:
- Split up in various TTM files and addressed review comments by
Christian König. Tested and fixed legacy iomap memcpy path on i915.
v4:
- Fix an uninitialized variable
Reported by: kernel test robot
Reported by: Dan Carpenter
- Minor change to the ttm_move_memcpy() interface.
- Gracefully handle lack of memremap() support on memcpy
(Reported by Matthew Auld)
- Minor style fix (Reported by Matthew Auld)
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 280 ++---
drivers/gpu/drm/ttm/ttm_module.c | 35
drivers/gpu/drm/ttm/ttm_resource.c | 193
drivers/gpu/drm/ttm/ttm_tt.c | 42 +
include/drm/ttm/ttm_bo_driver.h| 28 +++
include/drm/ttm/ttm_caching.h | 2 +
include/drm/ttm/ttm_kmap_iter.h| 61 +++
include/drm/ttm/ttm_resource.h | 61 +++
include/drm/ttm/ttm_tt.h | 16 ++
9 files changed, 536 insertions(+), 182 deletions(-)
create mode 100644 include/drm/ttm/ttm_kmap_iter.h
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ae8b61460724..6ac7744a1a5c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device *bdev,
mem->bus.addr = NULL;
}
-static int ttm_resource_ioremap(struct ttm_device *bdev,
- struct ttm_resource *mem,
- void **virtual)
+/**
+ * ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
+ * @bo: The struct ttm_buffer_object.
+ * @new_mem: The struct ttm_resource we're moving to (copy destination).
+ * @new_iter: A struct ttm_kmap_iter representing the destination resource.
+ * @src_iter: A struct ttm_kmap_iter representing the source resource.
+ *
+ * This function is intended to be able to move out async under a
+ * dma-fence if desired.
+ */
+void ttm_move_memcpy(struct ttm_buffer_object *bo,
+pgoff_t num_pages,
Can we switch to uint32_t for num_pages for TTM in general?
That allows to copy 16TiB when you have 4KiB pages which should be
enough for quite a while and I had some really bad bugs because people
tend to do << PAGE_SHIFT and forget that it is only 32bit sometimes.
Apart from that feel free to stick my rb on the patch.
Christian.
+struct ttm_kmap_iter *dst_iter,
+struct ttm_kmap_iter *src_iter)
{
- int ret;
- void *addr;
-
- *virtual = NULL;
- ret = ttm_mem_io_reserve(bdev, mem);
- if (ret || !mem->bus.is_iomem)
- return ret;
+ const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
+ const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
+ struct ttm_tt *ttm = bo->ttm;
+ struct dma_buf_map src_map, dst_map;
+ pgoff_t i;
- if (mem->bus.addr) {
- addr = mem->bus.addr;
- } else {
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ /* Single TTM move. NOP */
+ if (dst_ops->maps_tt && src_ops->maps_tt)
+ return;
- if (mem->bus.caching == ttm_write_combined)
- addr = ioremap_wc(mem->bus.offset, bus_size);
-#ifdef CONFIG_X86
- else if (mem->bus.caching == ttm_cached)
- addr = ioremap_cache(mem->bus.offset, bus_size);
-#endif
- else
- addr = ioremap(mem->bus.offset, bus_size);
- if (!addr) {
- ttm_mem_io_free(bdev, mem);
- return -ENOMEM;
+ /* Don't move nonexistent data. Clear destination instead. */
+ if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
+ if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG
Re: [Intel-gfx] [PATCH v7 07/15] drm: Add a prefetching memcpy_from_wc
Am 31.05.21 um 14:19 schrieb Thomas Hellström:
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to use a fast prefetching memcpy and
otherwise falls back to ordinary memcopies, taking the iomem tagging
into account.
The code is largely copied from i915_memcpy_from_wc.
Cc: Daniel Vetter
Cc: Christian König
Suggested-by: Daniel Vetter
Signed-off-by: Thomas Hellström
Acked-by: Christian König
---
v7:
- Perform a memcpy even if warning with in_interrupt(). Suggested by
Christian König.
- Fix compilation failure on !X86 (Reported by kernel test robot
l...@intel.com)
---
Documentation/gpu/drm-mm.rst | 2 +-
drivers/gpu/drm/drm_cache.c | 147 +++
drivers/gpu/drm/drm_drv.c| 2 +
include/drm/drm_cache.h | 7 ++
4 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 21be6deadc12..c66058c5bce7 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -469,7 +469,7 @@ DRM MM Range Allocator Function References
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
-DRM Cache Handling
+DRM Cache Handling and Fast WC memcpy()
==
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 79a50ef1250f..b887d7dec8b8 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -28,6 +28,7 @@
* Authors: Thomas Hellström
*/
+#include
#include
#include
#include
@@ -35,6 +36,9 @@
#include
+/* A small bounce buffer that fits on the stack. */
+#define MEMCPY_BOUNCE_SIZE 128
+
#if defined(CONFIG_X86)
#include
@@ -209,3 +213,146 @@ bool drm_need_swiotlb(int dma_bits)
return max_iomem > ((u64)1 << dma_bits);
}
EXPORT_SYMBOL(drm_need_swiotlb);
+
+static void memcpy_fallback(struct dma_buf_map *dst,
+ const struct dma_buf_map *src,
+ unsigned long len)
+{
+ if (!dst->is_iomem && !src->is_iomem) {
+ memcpy(dst->vaddr, src->vaddr, len);
+ } else if (!src->is_iomem) {
+ dma_buf_map_memcpy_to(dst, src->vaddr, len);
+ } else if (!dst->is_iomem) {
+ memcpy_fromio(dst->vaddr, src->vaddr_iomem, len);
+ } else {
+ /*
+* Bounce size is not performance tuned, but using a
+* bounce buffer like this is significantly faster than
+* resorting to ioreadxx() + iowritexx().
+*/
+ char bounce[MEMCPY_BOUNCE_SIZE];
+ void __iomem *_src = src->vaddr_iomem;
+ void __iomem *_dst = dst->vaddr_iomem;
+
+ while (len >= MEMCPY_BOUNCE_SIZE) {
+ memcpy_fromio(bounce, _src, MEMCPY_BOUNCE_SIZE);
+ memcpy_toio(_dst, bounce, MEMCPY_BOUNCE_SIZE);
+ _src += MEMCPY_BOUNCE_SIZE;
+ _dst += MEMCPY_BOUNCE_SIZE;
+ len -= MEMCPY_BOUNCE_SIZE;
+ }
+ if (len) {
+ memcpy_fromio(bounce, _src, MEMCPY_BOUNCE_SIZE);
+ memcpy_toio(_dst, bounce, MEMCPY_BOUNCE_SIZE);
+ }
+ }
+}
+
+#ifdef CONFIG_X86
+
+static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
+
+static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
+{
+ kernel_fpu_begin();
+
+ while (len >= 4) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movntdqa 16(%0), %%xmm1\n"
+ "movntdqa 32(%0), %%xmm2\n"
+ "movntdqa 48(%0), %%xmm3\n"
+ "movaps %%xmm0, (%1)\n"
+ "movaps %%xmm1, 16(%1)\n"
+ "movaps %%xmm2, 32(%1)\n"
+ "movaps %%xmm3, 48(%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 64;
+ dst += 64;
+ len -= 4;
+ }
+ while (len--) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movaps %%xmm0, (%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 16;
+ dst += 16;
+ }
+
+ kernel_fpu_end();
+}
+
+/*
+ * __drm_memcpy_from_wc copies @len bytes from @src to @dst using
+ * non-temporal instructions where available. Note that all arguments
+ * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
+ * of 16.
+ */
+static void __drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
+{
+ if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
+ memcpy(dst, src, len);
+ else if (likely(len))
+
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Extend QGV point restrict mask to 0x3
== Series Details == Series: series starting with [1/2] drm/i915: Extend QGV point restrict mask to 0x3 URL : https://patchwork.freedesktop.org/series/90776/ State : success == Summary == CI Bug Log - changes from CI_DRM_10151_full -> Patchwork_20236_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20236_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#3160]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-skl2/igt@gem_cre...@create-clear.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-skl10/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][4] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-apl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-glk6/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-glk2/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][10] -> [SKIP][11] ([fdo#109271]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-kbl2/igt@gem_exec_fair@basic-p...@vecs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-snb: NOTRUN -> [INCOMPLETE][13] ([i915#2055] / [i915#3468]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-snb5/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-skl: [PASS][14] -> [INCOMPLETE][15] ([i915#198] / [i915#3468]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-skl3/igt@gem_mmap_...@cpuset-basic-small-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-skl2/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-kbl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([i915#2910] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-tglb6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-tglb8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#3468]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-tglb8/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-tglb2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html - shard-apl: [PASS][21] -> [INCOMPLETE][22] ([i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10151/shard-apl3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-apl3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-glk: NOTRUN -> [INCOMPLETE][23] ([i915#3468]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20236/shard-glk8/igt@gem_mmap_...@fault-concurrent-x.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-skl: NOTR
[Intel-gfx] ✓ Fi.CI.BAT: success for Move LMEM (VRAM) management over to TTM (rev3)
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev3)
URL : https://patchwork.freedesktop.org/series/90681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10152 -> Patchwork_20238
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20238:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_tiled_fence_blits@basic:
- {fi-rkl-11500t}:[FAIL][1] ([i915#3277]) -> [FAIL][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-rkl-11500t/igt@gem_tiled_fence_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-rkl-11500t/igt@gem_tiled_fence_bl...@basic.html
* igt@kms_busy@basic:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][3] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-rkl-11500t/igt@kms_b...@basic.html
* igt@prime_self_import@basic-with_two_bos:
- {fi-rkl-11500t}:[PASS][4] -> [FAIL][5] +4 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-rkl-11500t/igt@prime_self_import@basic-with_two_bos.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-rkl-11500t/igt@prime_self_import@basic-with_two_bos.html
* igt@prime_vgem@basic-fence-flip:
- {fi-rkl-11500t}:[PASS][6] -> [SKIP][7] +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-rkl-11500t/igt@prime_v...@basic-fence-flip.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-rkl-11500t/igt@prime_v...@basic-fence-flip.html
* igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:[SKIP][8] ([i915#3291]) -> [SKIP][9] +2 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-rkl-11500t/igt@prime_v...@basic-read.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-rkl-11500t/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- {fi-rkl-11500t}:[SKIP][10] ([i915#3301]) -> [SKIP][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-rkl-11500t/igt@prime_v...@basic-userptr.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-rkl-11500t/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_20238 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][12] -> [DMESG-WARN][13] ([i915#2203] /
[i915#2868])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2: [PASS][14] -> [FAIL][15] ([i915#2416])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-guc: [DMESG-FAIL][16] ([i915#2291] / [i915#541]) ->
[PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-kbl-guc/igt@i915_selftest@live@gt_heartbeat.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-kbl-guc/igt@i915_selftest@live@gt_heartbeat.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [DMESG-FAIL][18] ([i915#3462]) -> [INCOMPLETE][19]
([i915#3462])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2: [DMESG-FAIL][20] ([i915#3462]) -> [INCOMPLETE][21]
([i915#3462])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-kbl-x1275: [FAIL][22] ([i915#1436] / [i915#3363]) -> [FAIL][23]
([i915#1436] / [i915#2426] / [i915#3363])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-kbl-x1275/igt@run...@aborted.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/fi-kbl-x1275/igt@run...@aborted.html
- fi-cfl-8109u: [FAIL][24] ([i915#2426] / [i915#3363]) -> [FAIL][25]
([i915#3363])
[24]:
https://
Re: [Intel-gfx] [PATCH v7 06/15] drm/ttm: Add a generic TTM memcpy move for page-based iomem
On 5/31/21 2:36 PM, Christian König wrote: Am 31.05.21 um 14:19 schrieb Thomas Hellström: The internal ttm_bo_util memcpy uses ioremap functionality, and while it probably might be possible to use it for copying in- and out of sglist represented io memory, using io_mem_reserve() / io_mem_free() callbacks, that would cause problems with fault(). Instead, implement a method mapping page-by-page using kmap_local() semantics. As an additional benefit we then avoid the occasional global TLB flushes of ioremap() and consuming ioremap space, elimination of a critical point of failure and with a slight change of semantics we could also push the memcpy out async for testing and async driver development purposes. A special linear iomem iterator is introduced internally to mimic the old ioremap behaviour for code-paths that can't immediately be ported over. This adds to the code size and should be considered a temporary solution. Looking at the code we have a lot of checks for iomap tagged pointers. Ideally we should extend the core memremap functions to also accept uncached memory and kmap_local functionality. Then we could strip a lot of code. Cc: Christian König Signed-off-by: Thomas Hellström --- v3: - Split up in various TTM files and addressed review comments by Christian König. Tested and fixed legacy iomap memcpy path on i915. v4: - Fix an uninitialized variable Reported by: kernel test robot Reported by: Dan Carpenter - Minor change to the ttm_move_memcpy() interface. - Gracefully handle lack of memremap() support on memcpy (Reported by Matthew Auld) - Minor style fix (Reported by Matthew Auld) --- drivers/gpu/drm/ttm/ttm_bo_util.c | 280 ++--- drivers/gpu/drm/ttm/ttm_module.c | 35 drivers/gpu/drm/ttm/ttm_resource.c | 193 drivers/gpu/drm/ttm/ttm_tt.c | 42 + include/drm/ttm/ttm_bo_driver.h | 28 +++ include/drm/ttm/ttm_caching.h | 2 + include/drm/ttm/ttm_kmap_iter.h | 61 +++ include/drm/ttm/ttm_resource.h | 61 +++ include/drm/ttm/ttm_tt.h | 16 ++ 9 files changed, 536 insertions(+), 182 deletions(-) create mode 100644 include/drm/ttm/ttm_kmap_iter.h diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index ae8b61460724..6ac7744a1a5c 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device *bdev, mem->bus.addr = NULL; } -static int ttm_resource_ioremap(struct ttm_device *bdev, - struct ttm_resource *mem, - void **virtual) +/** + * ttm_move_memcpy - Helper to perform a memcpy ttm move operation. + * @bo: The struct ttm_buffer_object. + * @new_mem: The struct ttm_resource we're moving to (copy destination). + * @new_iter: A struct ttm_kmap_iter representing the destination resource. + * @src_iter: A struct ttm_kmap_iter representing the source resource. + * + * This function is intended to be able to move out async under a + * dma-fence if desired. + */ +void ttm_move_memcpy(struct ttm_buffer_object *bo, + pgoff_t num_pages, Can we switch to uint32_t for num_pages for TTM in general? That allows to copy 16TiB when you have 4KiB pages which should be enough for quite a while and I had some really bad bugs because people tend to do << PAGE_SHIFT and forget that it is only 32bit sometimes. I can do that, although IIRC we've had some discussions internally that 16TiB isn't enough for our bos in general, so at some point a request from us might to be to see what we can do to bump that across TTM for 64-bit? Matthew, you looked at this a couple of weeks ago? Apart from that feel free to stick my rb on the patch. Thanks! /Thomas Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/29] drm/i915/gem: Don't allow changing the engine set on running contexts (v2)
On Thu, May 27, 2021 at 11:26:47AM -0500, Jason Ekstrand wrote:
> When the APIs were added to manage the engine set on a GEM context
> directly from userspace, the questionable choice was made to allow
> changing the engine set on a context at any time. This is horribly racy
> and there's absolutely no reason why any userspace would want to do this
> outside of trying to exercise interesting race conditions. By removing
> support for CONTEXT_PARAM_ENGINES from ctx_setparam, we make it
> impossible to change the engine set after the context has been fully
> created.
>
> This doesn't yet let us delete all the deferred engine clean-up code as
> that's still used for handling the case where the client dies or calls
> GEM_CONTEXT_DESTROY while work is in flight. However, moving to an API
> where the engine set is effectively immutable gives us more options to
> potentially clean that code up a bit going forward. It also removes a
> whole class of ways in which a client can hurt itself or try to get
> around kernel context banning.
On this I do kinda wonder why we don't refcount drm_file and then gc all
these tricks. Iirc drm_file disappearing at a bad time is a large reasons
for all these tricks we need for context/request/engine cleanup.
But yeah definitely needs a pile more analysis.
>
> v2 (Jason Ekstrand):
> - Expand the commit mesage
I already gave you an r-b assuming you type some commit message ...
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 303
> 1 file changed, 303 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index a528c8f3354a0..e6a6ead477ff4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1819,305 +1819,6 @@ static int set_sseu(struct i915_gem_context *ctx,
> return ret;
> }
>
> -struct set_engines {
> - struct i915_gem_context *ctx;
> - struct i915_gem_engines *engines;
> -};
> -
> -static int
> -set_engines__load_balance(struct i915_user_extension __user *base, void
> *data)
> -{
> - struct i915_context_engines_load_balance __user *ext =
> - container_of_user(base, typeof(*ext), base);
> - const struct set_engines *set = data;
> - struct drm_i915_private *i915 = set->ctx->i915;
> - struct intel_engine_cs *stack[16];
> - struct intel_engine_cs **siblings;
> - struct intel_context *ce;
> - struct intel_sseu null_sseu = {};
> - u16 num_siblings, idx;
> - unsigned int n;
> - int err;
> -
> - if (!HAS_EXECLISTS(i915))
> - return -ENODEV;
> -
> - if (intel_uc_uses_guc_submission(&i915->gt.uc))
> - return -ENODEV; /* not implement yet */
> -
> - if (get_user(idx, &ext->engine_index))
> - return -EFAULT;
> -
> - if (idx >= set->engines->num_engines) {
> - drm_dbg(&i915->drm, "Invalid placement value, %d >= %d\n",
> - idx, set->engines->num_engines);
> - return -EINVAL;
> - }
> -
> - idx = array_index_nospec(idx, set->engines->num_engines);
> - if (set->engines->engines[idx]) {
> - drm_dbg(&i915->drm,
> - "Invalid placement[%d], already occupied\n", idx);
> - return -EEXIST;
> - }
> -
> - if (get_user(num_siblings, &ext->num_siblings))
> - return -EFAULT;
> -
> - err = check_user_mbz(&ext->flags);
> - if (err)
> - return err;
> -
> - err = check_user_mbz(&ext->mbz64);
> - if (err)
> - return err;
> -
> - siblings = stack;
> - if (num_siblings > ARRAY_SIZE(stack)) {
> - siblings = kmalloc_array(num_siblings,
> - sizeof(*siblings),
> - GFP_KERNEL);
> - if (!siblings)
> - return -ENOMEM;
> - }
> -
> - for (n = 0; n < num_siblings; n++) {
> - struct i915_engine_class_instance ci;
> -
> - if (copy_from_user(&ci, &ext->engines[n], sizeof(ci))) {
> - err = -EFAULT;
> - goto out_siblings;
> - }
> -
> - siblings[n] = intel_engine_lookup_user(i915,
> -ci.engine_class,
> -ci.engine_instance);
> - if (!siblings[n]) {
> - drm_dbg(&i915->drm,
> - "Invalid sibling[%d]: { class:%d, inst:%d }\n",
> - n, ci.engine_class, ci.engine_instance);
> - err = -EINVAL;
> - goto out_siblings;
> - }
> - }
> -
> - ce = intel_execlists_create_virtual(siblings, n);
> - if (IS_ERR(ce)) {
> - err = PTR_ERR(ce);
> - g
Re: [Intel-gfx] [PATCH] drm/i915/display: Add support of MOD_Y_TILED during fb init
On Mon, May 31, 2021 at 07:32:17PM +0800, Sodhi, Vunny wrote:
> Adding Y_TILED modifier which is needed to support DRM_FORMAT_NV12
> during framebuffer initialization.
>
> Signed-off-by: Sodhi, Vunny
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index caf0414..a9b1b62 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11610,8 +11610,10 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> if (tiling == I915_TILING_X) {
> mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
> } else if (tiling == I915_TILING_Y) {
> + mode_cmd->modifier[0] = I915_FORMAT_MOD_Y_TILED;
> + } else {
This is just the legacy bo tiling->modifier path, which is not needed by
any old userspace, and all modern userspace should just use modifiers.
> drm_dbg_kms(&dev_priv->drm,
> - "No Y tiling for legacy addfb\n");
> + "Unsupported tiling for legacy addfb\n");
> goto err;
> }
> }
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/29] drm/i915/gem: Don't allow changing the VM on running contexts (v2)
On Thu, May 27, 2021 at 11:26:46AM -0500, Jason Ekstrand wrote:
> When the APIs were added to manage VMs more directly from userspace, the
> questionable choice was made to allow changing out the VM on a context
> at any time. This is horribly racy and there's absolutely no reason why
> any userspace would want to do this outside of testing that exact race.
> By removing support for CONTEXT_PARAM_VM from ctx_setparam, we make it
> impossible to change out the VM after the context has been fully
> created. This lets us delete a bunch of deferred task code as well as a
> duplicated (and slightly different) copy of the code which programs the
> PPGTT registers.
>
> v2 (Jason Ekstrand):
> - Expand the commit message
>
> Signed-off-by: Jason Ekstrand
Already scored an Reviewed-by: Daniel Vetter
now that the commit message is there.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 262 --
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
> .../drm/i915/gem/selftests/i915_gem_context.c | 119
> .../drm/i915/selftests/i915_mock_selftests.h | 1 -
> 4 files changed, 1 insertion(+), 383 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index f7c83730ee07f..a528c8f3354a0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1633,120 +1633,6 @@ int i915_gem_vm_destroy_ioctl(struct drm_device *dev,
> void *data,
> return 0;
> }
>
> -struct context_barrier_task {
> - struct i915_active base;
> - void (*task)(void *data);
> - void *data;
> -};
> -
> -static void cb_retire(struct i915_active *base)
> -{
> - struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
> -
> - if (cb->task)
> - cb->task(cb->data);
> -
> - i915_active_fini(&cb->base);
> - kfree(cb);
> -}
> -
> -I915_SELFTEST_DECLARE(static intel_engine_mask_t
> context_barrier_inject_fault);
> -static int context_barrier_task(struct i915_gem_context *ctx,
> - intel_engine_mask_t engines,
> - bool (*skip)(struct intel_context *ce, void
> *data),
> - int (*pin)(struct intel_context *ce, struct
> i915_gem_ww_ctx *ww, void *data),
> - int (*emit)(struct i915_request *rq, void
> *data),
> - void (*task)(void *data),
> - void *data)
> -{
> - struct context_barrier_task *cb;
> - struct i915_gem_engines_iter it;
> - struct i915_gem_engines *e;
> - struct i915_gem_ww_ctx ww;
> - struct intel_context *ce;
> - int err = 0;
> -
> - GEM_BUG_ON(!task);
> -
> - cb = kmalloc(sizeof(*cb), GFP_KERNEL);
> - if (!cb)
> - return -ENOMEM;
> -
> - i915_active_init(&cb->base, NULL, cb_retire, 0);
> - err = i915_active_acquire(&cb->base);
> - if (err) {
> - kfree(cb);
> - return err;
> - }
> -
> - e = __context_engines_await(ctx, NULL);
> - if (!e) {
> - i915_active_release(&cb->base);
> - return -ENOENT;
> - }
> -
> - for_each_gem_engine(ce, e, it) {
> - struct i915_request *rq;
> -
> - if (I915_SELFTEST_ONLY(context_barrier_inject_fault &
> -ce->engine->mask)) {
> - err = -ENXIO;
> - break;
> - }
> -
> - if (!(ce->engine->mask & engines))
> - continue;
> -
> - if (skip && skip(ce, data))
> - continue;
> -
> - i915_gem_ww_ctx_init(&ww, true);
> -retry:
> - err = intel_context_pin_ww(ce, &ww);
> - if (err)
> - goto err;
> -
> - if (pin)
> - err = pin(ce, &ww, data);
> - if (err)
> - goto err_unpin;
> -
> - rq = i915_request_create(ce);
> - if (IS_ERR(rq)) {
> - err = PTR_ERR(rq);
> - goto err_unpin;
> - }
> -
> - err = 0;
> - if (emit)
> - err = emit(rq, data);
> - if (err == 0)
> - err = i915_active_add_request(&cb->base, rq);
> -
> - i915_request_add(rq);
> -err_unpin:
> - intel_context_unpin(ce);
> -err:
> - if (err == -EDEADLK) {
> - err = i915_gem_ww_ctx_backoff(&ww);
> - if (!err)
> - goto retry;
> - }
> - i915_gem_ww_ctx_fini(&ww);
> -
> - if (err)
> - break;
> - }
> - i915_sw_fence_complete(&e->fence);
> -
> - cb->task = err ? NULL : task; /* caller needs to unwind instead */
> - cb->data = data;
> -
> - i91
[Intel-gfx] [PATCH] drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2.
We need to make the BSW workaround actually work. We correctly fixed
the mutex nesting, but forgot to kill the worker.
The worker is killed by clearing async_flags, and just running bind_vma
synchronously. This still needs the stash, because we cannot allocate
and pin with vm->mutex already held.
Changes since v1:
- Fix null pointer dereference when we forget to pass the work stash,
it's still required to prealloc all on affected platforms.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +++-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 4 +++-
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 1aee5e6b1b23..de3aa79b788e 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -433,7 +433,9 @@ struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt)
ppgtt->base.vm.pd_shift = ilog2(SZ_4K * SZ_4K / sizeof(gen6_pte_t));
ppgtt->base.vm.top = 1;
- ppgtt->base.vm.bind_async_flags = I915_VMA_LOCAL_BIND;
+ if (!intel_vm_no_concurrent_access_wa(gt->i915))
+ ppgtt->base.vm.bind_async_flags = I915_VMA_LOCAL_BIND;
+
ppgtt->base.vm.allocate_va_range = gen6_alloc_va_range;
ppgtt->base.vm.clear_range = gen6_ppgtt_clear_range;
ppgtt->base.vm.insert_entries = gen6_ppgtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index e3a8924d2286..aa58b0e48ae1 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -732,7 +732,9 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt)
goto err_free_pd;
}
- ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
+ if (!intel_vm_no_concurrent_access_wa(gt->i915))
+ ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
+
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index b319fd3f91cc..d550ee911e68 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -436,7 +436,7 @@ int i915_vma_bind(struct i915_vma *vma,
work->pinned = i915_gem_object_get(vma->obj);
}
} else {
- vma->ops->bind_vma(vma->vm, NULL, vma, cache_level, bind_flags);
+ vma->ops->bind_vma(vma->vm, work ? &work->stash : NULL, vma,
cache_level, bind_flags);
}
atomic_or(bind_flags, &vma->flags);
@@ -895,7 +895,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
if (flags & PIN_GLOBAL)
wakeref = intel_runtime_pm_get(&vma->vm->i915->runtime_pm);
- if (flags & vma->vm->bind_async_flags) {
+ if ((flags & vma->vm->bind_async_flags) || vma->vm->allocate_va_range) {
/* lock VM */
err = i915_vm_lock_objects(vma->vm, ww);
if (err)
--
2.31.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
On Fri, May 28, 2021 at 02:15:46PM -0400, Adam Chasen wrote: > Any further advice on tracing what is triggering what appears to be the > limitation of the clock? My guess is it is imposing a DVI Single-Link speed > (165000) limitation on the dual-link DVI adapter. > > > TMDS clock 25000-165000 > > I am able to override in xorg with xrandr to 268500 > > Per Ville's request: > DPCD DFP: 0a > > What is the DPCD DFP? It indicates the port is DVI with HPD capability. But unfortunately it's using the one byte caps format which doesn't let us differentiate between single link and dual link DVI. So we take the more cautious apporach and assume it's single link. > > Thanks, > Adam > > On Wed, May 12, 2021, at 5:07 PM, Adam Chasen wrote: > > Ville, > > DPCD DFP: 0a > > > > What is the DPCD DFP? > > > > Additional info, this is the first time there has been an issue with > > this adapter not working (i.e. it must have been operating above > > 165MHz), but it is possible other drivers have "ignored" things and > > just followed the EDID. > > > > Thanks! > > Adam > > > > kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > > [CONNECTOR:95:DP-1] > > kernel: i915 :00:02.0: [drm:intel_dp_detect [i915]] > > [CONNECTOR:95:DP-1] > > kernel: [drm:drm_dp_read_dpcd_caps [drm_kms_helper]] AUX C/DDI C/PHY C: > > DPCD: 11 0a 84 01 00 05 00 81 00 00 00 00 00 00 00 > > kernel: [drm:drm_dp_read_desc [drm_kms_helper]] AUX C/DDI C/PHY C: DP > > branch: OUI 00-80-e1 dev-ID m2DVIa HW-rev 0.1 SW-rev 2.0 quirks 0x > > kernel: [drm:drm_dp_read_downstream_info [drm_kms_helper]] AUX C/DDI > > C/PHY C: DPCD DFP: 0a > > kernel: i915 :00:02.0: [drm:intel_dp_detect [i915]] [ENCODER:94:DDI > > C/PHY C] MST support: port: yes, sink: no, modparam: yes > > kernel: i915 :00:02.0: [drm:intel_dp_print_rates [i915]] source > > rates: 162000, 216000, 27, 324000, 432000, 54 > > kernel: i915 :00:02.0: [drm:intel_dp_print_rates [i915]] sink > > rates: 162000, 27 > > kernel: i915 :00:02.0: [drm:intel_dp_print_rates [i915]] common > > rates: 162000, 27 > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > native defer > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > native defer > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > native defer > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > native defer > > kernel: i915 :00:02.0: [drm:intel_dp_set_edid [i915]] > > [CONNECTOR:95:DP-1] DFP max bpc 8, max dotclock 0, TMDS clock > > 25000-165000 > > kernel: i915 :00:02.0: [drm:intel_dp_set_edid [i915]] > > [CONNECTOR:95:DP-1] YCbCr 4:2:0 allowed? no, YCbCr 4:4:4->4:2:0 > > conversion? no > > kernel: [drm:drm_dp_get_edid_quirks [drm_kms_helper]] DP sink: EDID mfg > > 22-f0 prod-ID 90-26 quirks: 0x > > kernel: [drm:drm_add_edid_modes [drm]] ELD: no CEA Extension found > > kernel: [drm:drm_add_display_info [drm]] Supported Monitor Refresh rate > > range is 0 Hz - 0 Hz > > kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0 > > kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": > > 60 268000 2560 2608 2640 2720 1600 1603 1609 1646 0x48 0x9 > > kernel: [drm:drm_mode_prune_invalid [drm]] Not using 2560x1600 mode: > > CLOCK_HIGH > > kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > > [CONNECTOR:95:DP-1] probed modes : > > kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "1280x800": > > 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9 > > > > # for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 count=16 > > skip=$((0x80)) 2>/dev/null | hexdump -C ; done > > 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > 0010 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > 0010 > > > > # for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 2>/dev/null | > > hexdump -C ; done > > 11 0a 84 01 00 05 00 81 00 00 00 00 00 00 00 00 > > || > > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > * > > 0080 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > * > > 0100 0a 84 00 08 08 08 08 00 01 00 00 00 00 00 00 00 > > || > > 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > * > > 0200 01 00 77 77 81 00 44 44 00 00 00 00 00 00 00 00 > > |..ww..DD| > > 0210 00 80 00 80 00 80 00 80 00 00 00 00 00 00 00 00 > > || > > 0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > || > > * > > 0240 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 |.. > > .| > > 0250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms
On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> For Intel platforms, pitch needs to be 64 byte aligned.
> Kernel code vgem_gem_dumb_create which is platform generic code
> doesnt do the alignment. This causes frame buffer creation to fail
> on Intel platforms where the pitch is not 64 byte aligned.
>
> tests: test run on Intel platforms with panel resolution 1366x768
>
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_prime.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
> index 8cb2ca2a9dc3..fdc941fe8100 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -51,6 +51,8 @@ static struct {
> { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },
> };
>
> +bool check_platform;
> +
> IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
>
> static bool has_prime_import(int fd)
> @@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct
> dumb_bo *scratch,
> scratch->bpp = 32;
>
> scratch->handle = kmstest_dumb_create(exporter_fd,
> - scratch->width,
> + check_platform? ALIGN(scratch->width, 64):
> scratch->width,
The dumb_create ioctl already does this for us.
> scratch->height,
> scratch->bpp,
> &scratch->pitch,
> @@ -262,6 +264,7 @@ igt_main
>
> /* ANY = anything that is not VGEM */
> first_fd = __drm_open_driver_another(0, DRIVER_ANY |
> DRIVER_VGEM);
> + check_platform = is_i915_device(first_fd);
> igt_require(first_fd >= 0);
>
> second_fd = __drm_open_driver_another(1, DRIVER_ANY |
> DRIVER_VGEM);
> --
> 2.7.4
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/29] drm/i915/gem: Roll all of context creation together
On Thu, May 27, 2021 at 11:26:50AM -0500, Jason Ekstrand wrote:
> Now that we have the whole engine set and VM at context creation time,
> we can just assign those fields instead of creating first and handling
> the VM and engines later. This lets us avoid creating useless VMs and
> engine sets and lets us get rid of the complex VM setting code.
>
> Signed-off-by: Jason Ekstrand
On the last three patches:
Reviewed-by: Daniel Vetter
Looking at the end result we still have the ctx->user_flags which are
muttable, and I think for again no reason at all. Especially for
persistence I think it'd be nice to have that immutable, since some of the
dedicated cleanup code for that is rather hairy.
But really also would be nice if the other 3 hang related flags would be
immutable too.
Anyway that's a separate thing for sure, since the big ones are clearly
the mutable vm/engines, and that's now gone.
Cheers!
I'll check with Zbyscek who cross-checks the revised igt coverage against
the revised uapi. And to avoid confusion like last round: I'll expect you
to ping me if you disagree on some or send out v6. Next round should
already come with r-b: me on all the patches (well one maybe I need to
check out again when you've moved the wrongly squashed hunk to the right
place).
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 159 ++
> .../gpu/drm/i915/gem/selftests/mock_context.c | 33 ++--
> 2 files changed, 64 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index e6a6ead477ff4..502a2bd1a043e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1298,56 +1298,6 @@ static int __context_set_persistence(struct
> i915_gem_context *ctx, bool state)
> return 0;
> }
>
> -static struct i915_gem_context *
> -__create_context(struct drm_i915_private *i915,
> - const struct i915_gem_proto_context *pc)
> -{
> - struct i915_gem_context *ctx;
> - struct i915_gem_engines *e;
> - int err;
> - int i;
> -
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> - if (!ctx)
> - return ERR_PTR(-ENOMEM);
> -
> - kref_init(&ctx->ref);
> - ctx->i915 = i915;
> - ctx->sched = pc->sched;
> - mutex_init(&ctx->mutex);
> - INIT_LIST_HEAD(&ctx->link);
> -
> - spin_lock_init(&ctx->stale.lock);
> - INIT_LIST_HEAD(&ctx->stale.engines);
> -
> - mutex_init(&ctx->engines_mutex);
> - e = default_engines(ctx, pc->legacy_rcs_sseu);
> - if (IS_ERR(e)) {
> - err = PTR_ERR(e);
> - goto err_free;
> - }
> - RCU_INIT_POINTER(ctx->engines, e);
> -
> - INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
> - mutex_init(&ctx->lut_mutex);
> -
> - /* NB: Mark all slices as needing a remap so that when the context first
> - * loads it will restore whatever remap state already exists. If there
> - * is no remap info, it will be a NOP. */
> - ctx->remap_slice = ALL_L3_SLICES(i915);
> -
> - ctx->user_flags = pc->user_flags;
> -
> - for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
> - ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
> -
> - return ctx;
> -
> -err_free:
> - kfree(ctx);
> - return ERR_PTR(err);
> -}
> -
> static inline struct i915_gem_engines *
> __context_engines_await(const struct i915_gem_context *ctx,
> bool *user_engines)
> @@ -1391,86 +1341,77 @@ context_apply_all(struct i915_gem_context *ctx,
> i915_sw_fence_complete(&e->fence);
> }
>
> -static void __apply_ppgtt(struct intel_context *ce, void *vm)
> -{
> - i915_vm_put(ce->vm);
> - ce->vm = i915_vm_get(vm);
> -}
> -
> -static struct i915_address_space *
> -__set_ppgtt(struct i915_gem_context *ctx, struct i915_address_space *vm)
> -{
> - struct i915_address_space *old;
> -
> - old = rcu_replace_pointer(ctx->vm,
> - i915_vm_open(vm),
> - lockdep_is_held(&ctx->mutex));
> - GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
> -
> - context_apply_all(ctx, __apply_ppgtt, vm);
> -
> - return old;
> -}
> -
> -static void __assign_ppgtt(struct i915_gem_context *ctx,
> -struct i915_address_space *vm)
> -{
> - if (vm == rcu_access_pointer(ctx->vm))
> - return;
> -
> - vm = __set_ppgtt(ctx, vm);
> - if (vm)
> - i915_vm_close(vm);
> -}
> -
> static struct i915_gem_context *
> i915_gem_create_context(struct drm_i915_private *i915,
> const struct i915_gem_proto_context *pc)
> {
> struct i915_gem_context *ctx;
> - int ret;
> + struct i915_gem_engines *e;
> + int err;
> + int i;
>
> - ctx = __create_context(i915, pc);
> - if (IS_ERR(ctx))
> - return ctx;
> + ctx = kzalloc(si
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms
Hello Ville,
Thank you very much.
Before reaching our i915's i915_gem_dumb_create, it goes to
vgem_gem_dumb_create for kms_prime.
The pitch gets calculated there and it is not 64 byte aligned. Due to this,
intel_framebuffer_init reports "pitch must be 64 byte aligned"
and framebuffer creation fails. I tried submitting vgem patch where 64 byte
alignment can be done in vgem_gem_dumb_create and that also
passes. But we did not get approval yet as few of them felt, vgem is generic
and other platforms might fail if we do 64 byte alignment there.
Kindly suggest. Thanks a lot.
Regards
Vidya
-Original Message-
From: Ville Syrjälä
Sent: Monday, May 31, 2021 7:48 PM
To: Srinivas, Vidya
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin,
Charlton
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64
byte for Intel platforms
On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> For Intel platforms, pitch needs to be 64 byte aligned.
> Kernel code vgem_gem_dumb_create which is platform generic code doesnt
> do the alignment. This causes frame buffer creation to fail on Intel
> platforms where the pitch is not 64 byte aligned.
>
> tests: test run on Intel platforms with panel resolution 1366x768
>
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_prime.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> 8cb2ca2a9dc3..fdc941fe8100 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -51,6 +51,8 @@ static struct {
> { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x }, };
>
> +bool check_platform;
> +
> IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
>
> static bool has_prime_import(int fd)
> @@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct
> dumb_bo *scratch,
> scratch->bpp = 32;
>
> scratch->handle = kmstest_dumb_create(exporter_fd,
> - scratch->width,
> + check_platform? ALIGN(scratch->width, 64):
> scratch->width,
The dumb_create ioctl already does this for us.
> scratch->height,
> scratch->bpp,
> &scratch->pitch,
> @@ -262,6 +264,7 @@ igt_main
>
> /* ANY = anything that is not VGEM */
> first_fd = __drm_open_driver_another(0, DRIVER_ANY |
> DRIVER_VGEM);
> + check_platform = is_i915_device(first_fd);
> igt_require(first_fd >= 0);
>
> second_fd = __drm_open_driver_another(1, DRIVER_ANY |
> DRIVER_VGEM);
> --
> 2.7.4
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Same slices mask is not same Dbuf state
> -Original Message- > From: Intel-gfx On Behalf Of > Stanislav > Lisovskiy > Sent: Thursday, May 27, 2021 4:31 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH] drm/i915/adl_p: Same slices mask is not same Dbuf > state > > We currently treat same slice mask as a same DBuf state and skip updating the > Dbuf > slices, if we detect that. > This is wrong as if we have a multi to single pipe change or vice versa, that > would be > treated as a same Dbuf state and thus no changes required, so we don't get > Mbus > updated, causing issues. > Solution: check also mbus_join, in addition to slices mask. Change looks good to me. Reviewed-by: Uma Shankar > Cc: Ville Syrjälä > Signed-off-by: Stanislav Lisovskiy > --- > drivers/gpu/drm/i915/intel_pm.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 00f3dead20ad..804d83486e81 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -8093,7 +8093,8 @@ void intel_dbuf_pre_plane_update(struct > intel_atomic_state *state) > intel_atomic_get_old_dbuf_state(state); > > if (!new_dbuf_state || > - new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices) > + ((new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices) > + && (new_dbuf_state->joined_mbus == old_dbuf_state->joined_mbus))) > return; > > WARN_ON(!new_dbuf_state->base.changed); > @@ -8113,7 +8114,8 @@ void intel_dbuf_post_plane_update(struct > intel_atomic_state *state) > intel_atomic_get_old_dbuf_state(state); > > if (!new_dbuf_state || > - new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices) > + ((new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices) > + && (new_dbuf_state->joined_mbus == old_dbuf_state->joined_mbus))) > return; > > WARN_ON(!new_dbuf_state->base.changed); > -- > 2.24.1.485.gad05a3d8e5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 01/15] swiotlb: Refactor swiotlb init functions
On Fri, May 28, 2021 at 12:32 AM Tom Lendacky wrote: > > On 5/27/21 9:41 AM, Tom Lendacky wrote: > > On 5/27/21 8:02 AM, Christoph Hellwig wrote: > >> On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote: > >>> You convert this call site with swiotlb_init_io_tlb_mem() which did not > >>> do the set_memory_decrypted()+memset(). Is this okay or should > >>> swiotlb_init_io_tlb_mem() add an additional argument to do this > >>> conditionally? > >> > >> The zeroing is useful and was missing before. I think having a clean > >> state here is the right thing. > >> > >> Not sure about the set_memory_decrypted, swiotlb_update_mem_attributes > >> kinda suggests it is too early to set the memory decrupted. > >> > >> Adding Tom who should now about all this. > > > > The reason for adding swiotlb_update_mem_attributes() was because having > > the call to set_memory_decrypted() in swiotlb_init_with_tbl() triggered a > > BUG_ON() related to interrupts not being enabled yet during boot. So that > > call had to be delayed until interrupts were enabled. > > I pulled down and tested the patch set and booted with SME enabled. The > following was seen during the boot: > > [0.134184] BUG: Bad page state in process swapper pfn:108002 > [0.134196] page:(ptrval) refcount:0 mapcount:-128 > mapping: index:0x0 pfn:0x108002 > [0.134201] flags: 0x17c000(node=0|zone=2|lastcpupid=0x1f) > [0.134208] raw: 0017c000 88847f355e28 88847f355e28 > > [0.134210] raw: 0001 ff7f > > [0.134212] page dumped because: nonzero mapcount > [0.134213] Modules linked in: > [0.134218] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.0-rc2-sos-custom > #3 > [0.134221] Hardware name: ... > [0.134224] Call Trace: > [0.134233] dump_stack+0x76/0x94 > [0.134244] bad_page+0xa6/0xf0 > [0.134252] __free_pages_ok+0x331/0x360 > [0.134256] memblock_free_all+0x158/0x1c1 > [0.134267] mem_init+0x1f/0x14c > [0.134273] start_kernel+0x290/0x574 > [0.134279] secondary_startup_64_no_verify+0xb0/0xbb > > I see this about 40 times during the boot, each with a different PFN. The > system boots (which seemed odd), but I don't know if there will be side > effects to this (I didn't stress the system). > > I modified the code to add a flag to not do the set_memory_decrypted(), as > suggested by Florian, when invoked from swiotlb_init_with_tbl(), and that > eliminated the bad page state BUG. Thanks. Will add a flag to skip set_memory_decrypted() in v9. > > Thanks, > Tom > > > > > Thanks, > > Tom > > > >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2.
== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2. URL : https://patchwork.freedesktop.org/series/90795/ State : warning == Summary == $ dim checkpatch origin/drm-tip 498a33865b2e drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2. -:59: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #59: FILE: drivers/gpu/drm/i915/i915_vma.c:439: + vma->ops->bind_vma(vma->vm, work ? &work->stash : NULL, vma, cache_level, bind_flags); total: 0 errors, 1 warnings, 0 checks, 36 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_dp_dsc: Avoid SIGSEGV when release DRM connector.
Got SIGSEGV fault while running kms_dp_dsc test but did not
connect DP DSC capable monitor on eDP/DP port. This test daemon
should "SKIP" test without any problem. We found kms_dp_dsc
can't get proper drmModeConnector and caused this SIGSEGV fault
when release it. Make sure drmModeConnector is available before
free it can avoid this issue.
Signed-off-by: Lee Shawn C
---
tests/kms_dp_dsc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/kms_dp_dsc.c b/tests/kms_dp_dsc.c
index 2446fd82bba3..ea7c9f4f72ce 100644
--- a/tests/kms_dp_dsc.c
+++ b/tests/kms_dp_dsc.c
@@ -262,7 +262,7 @@ igt_main
data_t data = {};
igt_output_t *output;
drmModeRes *res;
- drmModeConnector *connector;
+ drmModeConnector *connector = NULL;
int i, test_conn_cnt, test_cnt;
int tests[] = {DRM_MODE_CONNECTOR_eDP, DRM_MODE_CONNECTOR_DisplayPort};
@@ -311,7 +311,8 @@ igt_main
}
igt_fixture {
- drmModeFreeConnector(connector);
+ if (connector)
+ drmModeFreeConnector(connector);
drmModeFreeResources(res);
close(data.debugfs_fd);
close(data.drm_fd);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2.
== Series Details ==
Series: drm/i915: Only set bind_async_flags when concurrent access wa is not
active, v2.
URL : https://patchwork.freedesktop.org/series/90795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10152 -> Patchwork_20239
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/index.html
Known issues
Here are the changes found in Patchwork_20239 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live@hangcheck:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2782])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-icl-y/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-guc: [DMESG-FAIL][5] ([i915#2291] / [i915#541]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-kbl-guc/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-kbl-guc/igt@i915_selftest@live@gt_heartbeat.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [DMESG-FAIL][7] ([i915#3462]) -> [INCOMPLETE][8]
([i915#3462])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [INCOMPLETE][9] ([i915#2782] / [i915#3462]) ->
[DMESG-FAIL][10] ([i915#3462])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-icl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8109u: [FAIL][11] ([i915#2426] / [i915#3363]) -> [FAIL][12]
([i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cfl-8109u/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-cfl-8109u/igt@run...@aborted.html
- fi-icl-u2: [FAIL][13] ([i915#2782] / [i915#3363]) -> [FAIL][14]
([i915#2426] / [i915#2782] / [i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-icl-u2/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-icl-u2/igt@run...@aborted.html
- fi-kbl-7500u: [FAIL][15] ([i915#1436] / [i915#3363]) -> [FAIL][16]
([i915#1436] / [i915#2426] / [i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-kbl-7500u/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-kbl-7500u/igt@run...@aborted.html
- fi-bxt-dsi: [FAIL][17] ([i915#3363]) -> [FAIL][18] ([i915#2426] /
[i915#3363])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-bxt-dsi/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-bxt-dsi/igt@run...@aborted.html
- fi-cml-s: [FAIL][19] ([i915#3363] / [i915#3462]) -> [FAIL][20]
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cml-s/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-cml-s/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][21] ([i915#3363]) -> [FAIL][22] ([i915#2426] /
[i915#3363])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-cfl-guc/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-cfl-guc/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][23] ([i915#1436] / [i915#3363]) -> [FAIL][24]
([i915#1436] / [i915#2426] / [i915#3363])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/fi-skl-6700k2/igt@run...@aborted.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/22
[Intel-gfx] ✓ Fi.CI.IGT: success for Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90681/ State : success == Summary == CI Bug Log - changes from CI_DRM_10152_full -> Patchwork_20238_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20238_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23]) -> ([PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [FAIL][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47]) ([i915#3174]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl10/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl10/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl10/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl10/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl3/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl4/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl4/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl6/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl6/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl7/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl7/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl8/boot.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl8/boot.html [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20238/shard-skl8/boo
Re: [Intel-gfx] [PATCH V3] drm/i915/jsl: Add W/A 1409054076 for JSL
On Wed, May 19, 2021 at 07:48:21PM +0530, Tejas Upadhyay wrote:
> When pipe A is disabled and MIPI DSI is enabled on pipe B,
> the AMT KVMR feature will incorrectly see pipe A as enabled.
> Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
> it set while DSI is enabled on pipe B. No impact to setting it
> all the time.
>
> Changes since V2:
> - Used REG_BIT, ignored pipe A and used sw state check - Jani
> - Made function wrapper - Jani
> Changes since V1:
> - ./dim checkpatch errors addressed
>
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 21 +
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ce544e20f35c..799cacf4cf6e 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1236,15 +1236,34 @@ static void gen11_dsi_pre_enable(struct
> intel_atomic_state *state,
> gen11_dsi_set_transcoder_timings(encoder, pipe_config);
> }
>
> +/*
> + * WA 1409054076:JSL,EHL
It's also needed on ICL.
> + * When pipe A is disabled and MIPI DSI is enabled on pipe B,
> + * the AMT KVMR feature will incorrectly see pipe A as enabled.
> + * Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
> + * it set while DSI is enabled on pipe B
> + */
> +static void wa_1409054076(struct intel_encoder *encoder,
The name should be more readable something like
icl_apply_kvmr_pipe_a_wa().
> + enum pipe pipe, bool enable)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + if (IS_JSL_EHL(dev_priv) && pipe == PIPE_B)
Based on the above the platform check should be DISPLAY_VER == 11.
> + intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> + enable ? 0 : IGNORE_KVMR_PIPE_A,
No need to make the clear (ie mask) param conditional.
> + enable ? IGNORE_KVMR_PIPE_A : 0);
> +}
> static void gen11_dsi_enable(struct intel_atomic_state *state,
>struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
> {
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> + struct intel_crtc *crtc = to_intel_crtc(conn_state->crtc);
>
> drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
>
> + wa_1409054076(encoder, crtc->pipe, true);
> /* step6d: enable dsi transcoder */
> gen11_dsi_enable_transcoder(encoder);
>
> @@ -1398,7 +1417,9 @@ static void gen11_dsi_disable(struct intel_atomic_state
> *state,
> const struct drm_connector_state *old_conn_state)
> {
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> + struct intel_crtc *crtc = to_intel_crtc(old_conn_state->crtc);
>
> + wa_1409054076(encoder, crtc->pipe, false);
The flag should be cleared after disabling the pipe ie after
gen11_dsi_disable_transcoder().
Would be good to print a debug message during driver loading/resume if
BIOS hasn't set the WA correctly on a DSI output enabled on pipe B
already.
> /* step1: turn off backlight */
> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
> intel_panel_disable_backlight(old_conn_state);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 089b5a59bed3..fe01c6e05a45 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8041,6 +8041,7 @@ enum {
> # define CHICKEN3_DGMG_DONE_FIX_DISABLE (1 << 2)
>
> #define CHICKEN_PAR1_1 _MMIO(0x42080)
> +#define IGNORE_KVMR_PIPE_A REG_BIT(23)
> #define KBL_ARB_FILL_SPARE_22 REG_BIT(22)
> #define DIS_RAM_BYPASS_PSR2_MAN_TRACK (1 << 16)
> #define SKL_DE_COMPRESSED_HASH_MODE (1 << 15)
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 00/15] Move LMEM (VRAM) management over to TTM
This is an initial patch series to move discrete memory management over to TTM. It will be followed up shortly with adding more functionality. The buddy allocator is temporarily removed along with its selftests and It is replaced with the TTM range manager and some selftests are adjusted to account for introduced fragmentation. Work is ongoing to reintroduce the buddy allocator as a TTM resource manager. A new memcpy ttm move is introduced that uses kmap_local() functionality rather than vmap(). Among other things stated in the patch commit message it helps us deal with page-pased LMEM memory. It is generic enough to replace the ttm memcpy move with some additional work if so desired. On x86 it also enables prefetching reads from write-combined memory. Finally the old i915 gem object LMEM backend is replaced with a i915 gem object TTM backend and some additional i915 gem object ops are introduced to support the added functionality. Currently it is used only to support management and eviction of the LMEM region, but work is underway to extend the support to system memory. In this way we use TTM the way it was originally intended, having the GPU binding taken care of by driver code. Intention is to follow up with - System memory support - Pipelined accelerated moves / migration - Re-added buddy allocator in the TTM framework v2: - Add patches to move pagefaulting over to TTM - Break out TTM changes to separate patches - Address various review comments as detailed in the affected patches v3: - Drop TTM pagefaulting patches for now due changing approach due to a NAK. - Address feedback on TTM patches - Move the new TTM memcpy functionality into TTM. - Move fast WC memcpy to drm - Various fixes all over the place as shown in patch commit messages. v4: - Re-add TTM pagefaulting patches. - Addressed review feedback mainly from Matthew Auld - Fixed the mock ttm device code that was using an incorrect approach. v5: - Cleanups in the TTM pagefaulting patches. - Just add the WC memcpy to DRM without removing from i915 (Suggested by Daniel Vetter). - Various minor fixes as reported in patch log messages. v6: - Fix a merge conflict causing build error. v7: - Fix the WC memcpy compilation and perform a fallback memcpy in addition to warning in interrupt (Suggested by Christian König) - Renistate check for ttm_tt_is_populated() on swapout. v8: - Added a couple of acks and r-bs - pgoff_t -> u32 in interface of ttm_move_memcpy. - Fix missing export in !X86 WC memcpy. Cc: Christian König Maarten Lankhorst (3): drm/i915: Disable mmap ioctl for gen12+ drm/vma: Add a driver_private member to vma_node. drm/i915: Use ttm mmap handling for ttm bo's. Thomas Hellström (12): drm/i915: Untangle the vma pages_mutex drm/i915: Don't free shared locks while shared drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages drm/i915/ttm Initialize the ttm device and memory managers drm/i915/ttm: Embed a ttm buffer object in the i915 gem object drm/ttm: Add a generic TTM memcpy move for page-based iomem drm: Add a prefetching memcpy_from_wc drm/ttm: Use drm_memcpy_from_wc for TTM bo moves drm/ttm: Document and optimize ttm_bo_pipeline_gutting() drm/ttm, drm/amdgpu: Allow the driver some control over swapping drm/i915/ttm: Introduce a TTM i915 gem object backend drm/i915/lmem: Verify checks for lmem residency Documentation/gpu/drm-mm.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 + drivers/gpu/drm/drm_cache.c | 148 drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_gem.c | 9 - drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 71 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 - drivers/gpu/drm/i915/gem/i915_gem_mman.c | 90 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 149 +++- drivers/gpu/drm/i915/gem/i915_gem_object.h| 19 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 52 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 126 +-- drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 - drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 647 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 48 ++ drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 90 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 +- drivers/g
[Intel-gfx] [PATCH v8 01/15] drm/i915: Untangle the vma pages_mutex
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index b319fd3f91cc..0f227f28b280 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -800,32 +800,37 @@ static bool try_qad_pin(struct i915_vma *vma, unsigned
int flags)
static int vma_get_pages(struct i915_vma *vma)
{
int err = 0;
+ bool pinned_pages = false;
if (atomic_add_unless(&vma->pages_count, 1, 0))
return 0;
+ if (vma->obj) {
+ err = i915_gem_object_pin_pages(vma->obj);
+ if (err)
+ return err;
+ pinned_pages = true;
+ }
+
/* Allocations ahoy! */
- if (mutex_lock_interruptible(&vma->pages_mutex))
- return -EINTR;
+ if (mutex_lock_interruptible(&vma->pages_mutex)) {
+ err = -EINTR;
+ goto unpin;
+ }
if (!atomic_read(&vma->pages_count)) {
- if (vma->obj) {
- err = i915_gem_object_pin_pages(vma->obj);
- if (err)
- goto unlock;
- }
-
err = vma->ops->set_pages(vma);
- if (err) {
- if (vma->obj)
- i915_gem_object_unpin_pages(vma->obj);
+ if (err)
goto unlock;
- }
+ pinned_pages = false;
}
atomic_inc(&vma->pages_count);
unlock:
mutex_unlock(&vma->pages_mutex);
+unpin:
+ if (pinned_pages)
+ __i915_gem_object_unpin_pages(vma->obj);
return err;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 02/15] drm/i915: Don't free shared locks while shared
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add an additional refcount, for GGTT we take additional
measures to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
v2: Try harder to make sure objects sharing the GGTT reservation lock are
freed at GGTT takedown.
v3: Use a pointer to the vm to indicate that an object shares a reservation
object from that vm, rather than a pointer to the reservation object itself.
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 28 +++-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 5 +++
7 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 28144410df86..2be6109d0093 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -252,6 +252,9 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
if (obj->mm.n_placements > 1)
kfree(obj->mm.placements);
+ if (obj->shares_resv_from)
+ i915_vm_resv_put(obj->shares_resv_from);
+
/* But keep the pointer alive for RCU-protected lookups */
call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
cond_resched();
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 0727d0c76aa0..0415f99b6b95 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -149,6 +149,10 @@ struct drm_i915_gem_object {
* when i915_gem_ww_ctx_backoff() or i915_gem_ww_ctx_fini() are called.
*/
struct list_head obj_link;
+ /**
+* @shared_resv_from: The object shares the resv from this vm.
+*/
+ struct i915_address_space *shares_resv_from;
union {
struct rcu_head rcu;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 35069ca5d7de..10c23a749a95 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -746,7 +746,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
mutex_unlock(&ggtt->vm.mutex);
i915_address_space_fini(&ggtt->vm);
- dma_resv_fini(&ggtt->vm.resv);
arch_phys_wc_del(ggtt->mtrr);
@@ -768,6 +767,19 @@ void i915_ggtt_driver_release(struct drm_i915_private
*i915)
ggtt_cleanup_hw(ggtt);
}
+/**
+ * i915_ggtt_driver_late_release - Cleanup of GGTT that needs to be done after
+ * all free objects have been drained.
+ * @i915: i915 device
+ */
+void i915_ggtt_driver_late_release(struct drm_i915_private *i915)
+{
+ struct i915_ggtt *ggtt = &i915->ggtt;
+
+ GEM_WARN_ON(kref_read(&ggtt->vm.resv_ref) != 1);
+ dma_resv_fini(&ggtt->vm._resv);
+}
+
static unsigned int gen6_get_total_gtt_size(u16 snb_gmch_ctl)
{
snb_gmch_ctl >>= SNB_GMCH_GGMS_SHIFT;
@@ -829,6 +841,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
return -ENOMEM;
}
+ kref_init(&ggtt->vm.resv_ref);
ret = setup_scratch_page(&ggtt->vm);
if (ret) {
drm_err(&i915->drm, "Scratch setup failed\n");
@@ -1135,7 +1148,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
ggtt->vm.gt = gt;
ggtt->vm.i915 = i915;
ggtt->vm.dma = i915->drm.dev;
- dma_resv_init(&ggtt->vm.resv);
+ dma_resv_init(&ggtt->vm._resv);
if (INTEL_GEN(i915) <= 5)
ret = i915_gmch_probe(ggtt);
@@ -1144,7 +1157,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
else
ret = gen8_gmch_probe(ggtt);
if (ret) {
- dma_resv_fini(&ggtt->vm.resv);
+ dma_resv_fini(&ggtt->vm._resv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 9b98f9d9faa3..94849567143d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -22,8 +22,11 @@ struct drm_i915_gem_object *alloc_pt_lmem(struct
i915_address_space *vm, int sz)
* object underneath, with the idea that one object_lock() will lock
* t
[Intel-gfx] [PATCH v8 03/15] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/i915_scatterlist.h | 16
4 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index ccede73c6465..616c3a2f1baf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -209,7 +209,7 @@ static int i915_gem_object_get_pages_dmabuf(struct
drm_i915_gem_object *obj)
if (IS_ERR(pages))
return PTR_ERR(pages);
- sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 51a05e62875d..be72ad0634ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -207,7 +207,7 @@ static int i915_gem_object_shmem_to_phys(struct
drm_i915_gem_object *obj)
err_xfer:
if (!IS_ERR_OR_NULL(pages)) {
- unsigned int sg_page_sizes = i915_sg_page_sizes(pages->sgl);
+ unsigned int sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index a657b99ec760..602f0ed983ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -173,7 +173,7 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
goto err;
}
- sg_page_sizes = i915_sg_page_sizes(st->sgl);
+ sg_page_sizes = i915_sg_dma_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 9cb26a224034..b96baad66a3a 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -101,15 +101,23 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
(((__iter).curr += PAGE_SIZE) >= (__iter).max) ? \
(__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0 : 0)
-static inline unsigned int i915_sg_page_sizes(struct scatterlist *sg)
+/**
+ * i915_sg_dma_sizes - Record the dma segment sizes of a scatterlist
+ * @sg: The scatterlist
+ *
+ * Return: An unsigned int with segment sizes logically or'ed together.
+ * A caller can use this information to determine what hardware page table
+ * entry sizes can be used to map the memory represented by the scatterlist.
+ */
+static inline unsigned int i915_sg_dma_sizes(struct scatterlist *sg)
{
unsigned int page_sizes;
page_sizes = 0;
- while (sg) {
+ while (sg && sg_dma_len(sg)) {
GEM_BUG_ON(sg->offset);
- GEM_BUG_ON(!IS_ALIGNED(sg->length, PAGE_SIZE));
- page_sizes |= sg->length;
+ GEM_BUG_ON(!IS_ALIGNED(sg_dma_len(sg), PAGE_SIZE));
+ page_sizes |= sg_dma_len(sg);
sg = __sg_next(sg);
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 04/15] drm/i915/ttm Initialize the ttm device and memory managers
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lmem_get_pages() (Reported by Matthew Auld)
- Break out and modify usage of i915_sg_dma_sizes() (Reported by Mattew Auld)
- Break out TTM changes to a separate patch (Reported by Christian König)
v3:
- Fix the same error unwind in mock_region_get_pages()
(Reported by Matthew Auld)
- Don't rely on new TTM functionality, but create a mock TTM device,
(Reported by Christian König)
v4:
- Use mock_gem_device rather than creating a separate ttm_device per
region.
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 59 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 120 ---
drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 -
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 -
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 27 +-
drivers/gpu/drm/i915/i915_buddy.c | 435 --
drivers/gpu/drm/i915/i915_buddy.h | 131 ---
drivers/gpu/drm/i915/i915_drv.c | 8 +
drivers/gpu/drm/i915/i915_drv.h | 8 +-
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_globals.c | 1 -
drivers/gpu/drm/i915/i915_globals.h | 1 -
drivers/gpu/drm/i915/i915_scatterlist.c | 70 ++
drivers/gpu/drm/i915/i915_scatterlist.h | 4 +
drivers/gpu/drm/i915/intel_memory_region.c| 180 ++--
drivers/gpu/drm/i915/intel_memory_region.h| 44 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 220 +
drivers/gpu/drm/i915/intel_region_ttm.h | 32 +
drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 --
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
.../drm/i915/selftests/intel_memory_region.c | 133 +--
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 +
drivers/gpu/drm/i915/selftests/mock_region.c | 70 +-
30 files changed, 631 insertions(+), 1754 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.c
create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.h
delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 93f4d059fc89..61ff5c178714 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -27,6 +27,7 @@ config DRM_I915
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
select VMAP_PFN
+ select DRM_TTM
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6947495bf34b..4f22cac1c49b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -50,6 +50,7 @@ i915-y += i915_drv.o \
intel_memory_region.o \
intel_pch.o \
intel_pm.o \
+ intel_region_ttm.o \
intel_runtime_pm.o \
intel_sideband.o \
intel_step.o \
@@ -160,7 +161,6 @@ gem-y += \
i915-y += \
$(gem-y) \
i915_active.o \
- i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
i915_gem_gtt.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index f44bdd08f7cb..3b4aa28a076d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -4,16 +4,71 @@
*/
#include "intel_memory_region.h"
+#include "intel_region_ttm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
+static void lmem_put_pages(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
+{
+ intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node);
+ obj->mm.dirty = false;
+ sg_free_table(pages);
+ kfree(pages);
+}
+
+static int lmem_get_pages(struct drm_i915_gem_object *obj)
+{
+ unsigned int flags;
+ struct sg_table *pages;
+
+ flags = I915_ALLOC_MIN_PAGE_SIZE;
+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
+ flags |= I915_ALLOC_CONTIGUOUS;
+
+ obj->mm.st_mm_node = intel_region_ttm_node_alloc(obj->mm.region,
+
[Intel-gfx] [PATCH v8 05/15] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other backends.
To make this a bit more storage efficient for the other backends,
we'd have to use a pointer for the gem object which would require
a lot of changes in the driver. We postpone that for later.
Signed-off-by: Thomas Hellström
Acked-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 7 +++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2be6109d0093..5706d471692d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -62,6 +62,13 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops,
struct lock_class_key *key, unsigned flags)
{
+ /*
+* A gem object is embedded both in a struct ttm_buffer_object :/ and
+* in a drm_i915_gem_object. Make sure they are aliased.
+*/
+ BUILD_BUG_ON(offsetof(typeof(*obj), base) !=
+offsetof(typeof(*obj), __do_not_access.base));
+
spin_lock_init(&obj->vma.lock);
INIT_LIST_HEAD(&obj->vma.list);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index f5b46d11e6e6..d047ea126029 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include "i915_active.h"
@@ -99,7 +100,16 @@ struct i915_gem_object_page_iter {
};
struct drm_i915_gem_object {
- struct drm_gem_object base;
+ /*
+* We might have reason to revisit the below since it wastes
+* a lot of space for non-ttm gem objects.
+* In any case, always use the accessors for the ttm_buffer_object
+* when accessing it.
+*/
+ union {
+ struct drm_gem_object base;
+ struct ttm_buffer_object __do_not_access;
+ };
const struct drm_i915_gem_object_ops *ops;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 06/15] drm/ttm: Add a generic TTM memcpy move for page-based iomem
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional global
TLB flushes of ioremap() and consuming ioremap space, elimination of a
critical point of failure and with a slight change of semantics we could
also push the memcpy out async for testing and async driver development
purposes.
A special linear iomem iterator is introduced internally to mimic the
old ioremap behaviour for code-paths that can't immediately be ported
over. This adds to the code size and should be considered a temporary
solution.
Looking at the code we have a lot of checks for iomap tagged pointers.
Ideally we should extend the core memremap functions to also accept
uncached memory and kmap_local functionality. Then we could strip a
lot of code.
Cc: Christian König
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
---
v3:
- Split up in various TTM files and addressed review comments by
Christian König. Tested and fixed legacy iomap memcpy path on i915.
v4:
- Fix an uninitialized variable
Reported by: kernel test robot
Reported by: Dan Carpenter
- Minor change to the ttm_move_memcpy() interface.
- Gracefully handle lack of memremap() support on memcpy
(Reported by Matthew Auld)
- Minor style fix (Reported by Matthew Auld)
v8:
- Change num_pages from pgoff_t to uint32_t (Suggested by Christian König)
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 280 ++---
drivers/gpu/drm/ttm/ttm_module.c | 35
drivers/gpu/drm/ttm/ttm_resource.c | 193
drivers/gpu/drm/ttm/ttm_tt.c | 42 +
include/drm/ttm/ttm_bo_driver.h| 28 +++
include/drm/ttm/ttm_caching.h | 2 +
include/drm/ttm/ttm_kmap_iter.h| 61 +++
include/drm/ttm/ttm_resource.h | 61 +++
include/drm/ttm/ttm_tt.h | 16 ++
9 files changed, 536 insertions(+), 182 deletions(-)
create mode 100644 include/drm/ttm/ttm_kmap_iter.h
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ae8b61460724..a800998a12b0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device *bdev,
mem->bus.addr = NULL;
}
-static int ttm_resource_ioremap(struct ttm_device *bdev,
- struct ttm_resource *mem,
- void **virtual)
+/**
+ * ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
+ * @bo: The struct ttm_buffer_object.
+ * @new_mem: The struct ttm_resource we're moving to (copy destination).
+ * @new_iter: A struct ttm_kmap_iter representing the destination resource.
+ * @src_iter: A struct ttm_kmap_iter representing the source resource.
+ *
+ * This function is intended to be able to move out async under a
+ * dma-fence if desired.
+ */
+void ttm_move_memcpy(struct ttm_buffer_object *bo,
+u32 num_pages,
+struct ttm_kmap_iter *dst_iter,
+struct ttm_kmap_iter *src_iter)
{
- int ret;
- void *addr;
-
- *virtual = NULL;
- ret = ttm_mem_io_reserve(bdev, mem);
- if (ret || !mem->bus.is_iomem)
- return ret;
+ const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
+ const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
+ struct ttm_tt *ttm = bo->ttm;
+ struct dma_buf_map src_map, dst_map;
+ pgoff_t i;
- if (mem->bus.addr) {
- addr = mem->bus.addr;
- } else {
- size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+ /* Single TTM move. NOP */
+ if (dst_ops->maps_tt && src_ops->maps_tt)
+ return;
- if (mem->bus.caching == ttm_write_combined)
- addr = ioremap_wc(mem->bus.offset, bus_size);
-#ifdef CONFIG_X86
- else if (mem->bus.caching == ttm_cached)
- addr = ioremap_cache(mem->bus.offset, bus_size);
-#endif
- else
- addr = ioremap(mem->bus.offset, bus_size);
- if (!addr) {
- ttm_mem_io_free(bdev, mem);
- return -ENOMEM;
+ /* Don't move nonexistent data. Clear destination instead. */
+ if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
+ if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+ return;
+
+ for (i = 0; i < num_pages; ++i) {
+ dst_ops->map_local(dst_iter, &dst_map, i);
+ if (dst_map.is_iomem)
+ memset_io(dst_map.vaddr_iomem, 0, PAGE_SIZE);
+
[Intel-gfx] [PATCH v8 07/15] drm: Add a prefetching memcpy_from_wc
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to use a fast prefetching memcpy and
otherwise falls back to ordinary memcopies, taking the iomem tagging
into account.
The code is largely copied from i915_memcpy_from_wc.
Cc: Daniel Vetter
Cc: Christian König
Suggested-by: Daniel Vetter
Signed-off-by: Thomas Hellström
Acked-by: Christian König
Acked-by: Daniel Vetter
---
v7:
- Perform a memcpy even if warning with in_interrupt(). Suggested by
Christian König.
- Fix compilation failure on !X86 (Reported by kernel test robot
l...@intel.com)
v8:
- Skip kerneldoc for drm_memcpy_init_early()
- Export drm_memcpy_from_wc() also for non-x86.
---
Documentation/gpu/drm-mm.rst | 2 +-
drivers/gpu/drm/drm_cache.c | 148 +++
drivers/gpu/drm/drm_drv.c| 2 +
include/drm/drm_cache.h | 7 ++
4 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 21be6deadc12..c66058c5bce7 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -469,7 +469,7 @@ DRM MM Range Allocator Function References
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
-DRM Cache Handling
+DRM Cache Handling and Fast WC memcpy()
==
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 79a50ef1250f..546599f19a93 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -28,6 +28,7 @@
* Authors: Thomas Hellström
*/
+#include
#include
#include
#include
@@ -35,6 +36,9 @@
#include
+/* A small bounce buffer that fits on the stack. */
+#define MEMCPY_BOUNCE_SIZE 128
+
#if defined(CONFIG_X86)
#include
@@ -209,3 +213,147 @@ bool drm_need_swiotlb(int dma_bits)
return max_iomem > ((u64)1 << dma_bits);
}
EXPORT_SYMBOL(drm_need_swiotlb);
+
+static void memcpy_fallback(struct dma_buf_map *dst,
+ const struct dma_buf_map *src,
+ unsigned long len)
+{
+ if (!dst->is_iomem && !src->is_iomem) {
+ memcpy(dst->vaddr, src->vaddr, len);
+ } else if (!src->is_iomem) {
+ dma_buf_map_memcpy_to(dst, src->vaddr, len);
+ } else if (!dst->is_iomem) {
+ memcpy_fromio(dst->vaddr, src->vaddr_iomem, len);
+ } else {
+ /*
+* Bounce size is not performance tuned, but using a
+* bounce buffer like this is significantly faster than
+* resorting to ioreadxx() + iowritexx().
+*/
+ char bounce[MEMCPY_BOUNCE_SIZE];
+ void __iomem *_src = src->vaddr_iomem;
+ void __iomem *_dst = dst->vaddr_iomem;
+
+ while (len >= MEMCPY_BOUNCE_SIZE) {
+ memcpy_fromio(bounce, _src, MEMCPY_BOUNCE_SIZE);
+ memcpy_toio(_dst, bounce, MEMCPY_BOUNCE_SIZE);
+ _src += MEMCPY_BOUNCE_SIZE;
+ _dst += MEMCPY_BOUNCE_SIZE;
+ len -= MEMCPY_BOUNCE_SIZE;
+ }
+ if (len) {
+ memcpy_fromio(bounce, _src, MEMCPY_BOUNCE_SIZE);
+ memcpy_toio(_dst, bounce, MEMCPY_BOUNCE_SIZE);
+ }
+ }
+}
+
+#ifdef CONFIG_X86
+
+static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
+
+static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
+{
+ kernel_fpu_begin();
+
+ while (len >= 4) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movntdqa 16(%0), %%xmm1\n"
+ "movntdqa 32(%0), %%xmm2\n"
+ "movntdqa 48(%0), %%xmm3\n"
+ "movaps %%xmm0, (%1)\n"
+ "movaps %%xmm1, 16(%1)\n"
+ "movaps %%xmm2, 32(%1)\n"
+ "movaps %%xmm3, 48(%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 64;
+ dst += 64;
+ len -= 4;
+ }
+ while (len--) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movaps %%xmm0, (%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 16;
+ dst += 16;
+ }
+
+ kernel_fpu_end();
+}
+
+/*
+ * __drm_memcpy_from_wc copies @len bytes from @src to @dst using
+ * non-temporal instructions where available. Note that all arguments
+ * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
+ * of 16.
+ */
+static void __drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
+{
+ if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
+ memcpy(dst, src, len);
+ els
[Intel-gfx] [PATCH v8 08/15] drm/ttm: Use drm_memcpy_from_wc for TTM bo moves
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König #v4
--
v4:
- Clarify when we try drm_memcpy_from_wc_dbm (Reported by Matthew Auld)
- Be paranoid about when drm_memcpy_from_wc_dbm may fail (Reported by
Matthew Auld)
v5:
- Rebase on change to drm_memcpy_from_wc (Suggested by Daniel Vetter)
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index a800998a12b0..30bafac416a5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -118,22 +119,8 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
dst_ops->map_local(dst_iter, &dst_map, i);
src_ops->map_local(src_iter, &src_map, i);
- if (!src_map.is_iomem && !dst_map.is_iomem) {
- memcpy(dst_map.vaddr, src_map.vaddr, PAGE_SIZE);
- } else if (!src_map.is_iomem) {
- dma_buf_map_memcpy_to(&dst_map, src_map.vaddr,
- PAGE_SIZE);
- } else if (!dst_map.is_iomem) {
- memcpy_fromio(dst_map.vaddr, src_map.vaddr_iomem,
- PAGE_SIZE);
- } else {
- int j;
- u32 __iomem *src = src_map.vaddr_iomem;
- u32 __iomem *dst = dst_map.vaddr_iomem;
-
- for (j = 0; j < (PAGE_SIZE / sizeof(u32)); ++j)
- iowrite32(ioread32(src++), dst++);
- }
+ drm_memcpy_from_wc(&dst_map, &src_map, PAGE_SIZE);
+
if (src_ops->unmap_local)
src_ops->unmap_local(src_iter, &src_map);
if (dst_ops->unmap_local)
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 09/15] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the call to ttm_tt_create() fails.
Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict().
Cc: Christian König
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
---
v4:
- Clarify why we mark bo for clearing after ttm_bo_pipeline_gutting()
(Reported by Matthew Auld)
v5:
- Make ttm_tt_mark_for_clear() inline (Suggested by Christian König)
---
drivers/gpu/drm/ttm/ttm_bo.c | 20 +--
drivers/gpu/drm/ttm/ttm_bo_util.c | 55 ---
include/drm/ttm/ttm_tt.h | 13
3 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 51a94fd63bd7..be0406466460 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bdev->funcs->evict_flags(bo, &placement);
if (!placement.num_placement && !placement.num_busy_placement) {
- ttm_bo_wait(bo, false, false);
+ ret = ttm_bo_wait(bo, true, false);
+ if (ret)
+ return ret;
- ttm_bo_cleanup_memtype_use(bo);
- return ttm_tt_create(bo, false);
+ /*
+* Since we've already synced, this frees backing store
+* immediately.
+*/
+ return ttm_bo_pipeline_gutting(bo);
}
ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx);
@@ -976,13 +981,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
/*
* Remove the backing store if no placement is given.
*/
- if (!placement->num_placement && !placement->num_busy_placement) {
- ret = ttm_bo_pipeline_gutting(bo);
- if (ret)
- return ret;
-
- return ttm_tt_create(bo, false);
- }
+ if (!placement->num_placement && !placement->num_busy_placement)
+ return ttm_bo_pipeline_gutting(bo);
/*
* Check whether we need to move buffer.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 30bafac416a5..d0db63a7f00c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -565,26 +565,73 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
*bo,
}
EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
+/**
+ * ttm_bo_pipeline_gutting - purge the contents of a bo
+ * @bo: The buffer object
+ *
+ * Purge the contents of a bo, async if the bo is not idle.
+ * After a successful call, the bo is left unpopulated in
+ * system placement. The function may wait uninterruptible
+ * for idle on OOM.
+ *
+ * Return: 0 if successful, negative error code on failure.
+ */
int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
+ struct ttm_tt *ttm;
int ret;
- ret = ttm_buffer_object_transfer(bo, &ghost);
+ /* If already idle, no need for ghost object dance. */
+ ret = ttm_bo_wait(bo, false, true);
+ if (ret != -EBUSY) {
+ if (!bo->ttm) {
+ /* See comment below about clearing. */
+ ret = ttm_tt_create(bo, true);
+ if (ret)
+ return ret;
+ } else {
+ ttm_tt_unpopulate(bo->bdev, bo->ttm);
+ if (bo->type == ttm_bo_type_device)
+ ttm_tt_mark_for_clear(bo->ttm);
+ }
+ ttm_resource_free(bo, &bo->mem);
+ ttm_resource_alloc(bo, &sys_mem, &bo->mem);
+
+ return 0;
+ }
+
+ /*
+* We need an unpopulated ttm_tt after giving our current one,
+* if any, to the ghost object. And we can't afford to fail
+* creating one *after* the operation. If the bo subsequently gets
+* resurrected, make sure it's cleared (if ttm_bo_type_device)
+* to avoid leaking sensitive information to user-space.
+*/
+
+ ttm = bo->ttm;
+ bo->ttm = NULL;
+ ret = ttm_tt_create(bo, true);
+ swap(bo->ttm, ttm);
if (ret)
return ret;
+ ret = ttm_buffer_object_transfer(bo, &ghost);
+ if (ret) {
+ ttm_tt_destroy(bo->bdev, ttm);
+ return ret;
+ }
+
ret = dma_resv_copy_fences(&ghost->base._resv, bo->base.resv);
/* Last resort, wait for the BO to be idle when we are OOM */
if (ret)
ttm_bo_wait(bo,
[Intel-gfx] [PATCH v8 10/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped out,
in which case the drivers normal eviction_valuable path is run.
Reviewed-by: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Thomas Hellström
Acked-by: Christian König
---
v3:
- Don't export ttm_tt_unpopulate
- Fix confusion reading the locked pointer instead of the value
pointed to in ttm_bo_evict_swapout_allowable (Reported by
Maarten Lankhorst)
v5:
- Use memset() rather than = {} (Suggested by Christian König)
- Remove check for ttm_tt_is_populated in the swapout code in the hope
it will be fixed elsewhere (Suggested by Christian König)
v7:
- Re-add the check for ttm_tt_is_populated in the swapout code.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +++
drivers/gpu/drm/ttm/ttm_bo.c| 46 -
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 80437b6ba5f3..5116065748a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1328,6 +1328,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
struct dma_fence *f;
int i;
+ /* Swapout? */
+ if (bo->mem.mem_type == TTM_PL_SYSTEM)
+ return true;
+
if (bo->type == ttm_bo_type_kernel &&
!amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)))
return false;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index be0406466460..98c41bf6a07d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
+ dma_resv_assert_held(bo->base.resv);
+ if (bo->mem.mem_type == TTM_PL_SYSTEM)
+ return true;
+
/* Don't evict this BO if it's outside of the
* requested placement range
*/
@@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
- struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
+ struct ttm_operation_ctx *ctx,
+ const struct ttm_place *place,
+ bool *locked, bool *busy)
{
bool ret = false;
@@ -576,6 +582,14 @@ static bool ttm_bo_evict_swapout_allowable(struct
ttm_buffer_object *bo,
*busy = !ret;
}
+ if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) {
+ ret = false;
+ if (*locked) {
+ dma_resv_unlock(bo->base.resv);
+ *locked = false;
+ }
+ }
+
return ret;
}
@@ -630,20 +644,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
list_for_each_entry(bo, &man->lru[i], lru) {
bool busy;
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked,
- &busy)) {
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
+ &locked, &busy)) {
if (busy && !busy_bo && ticket !=
dma_resv_locking_ctx(bo->base.resv))
busy_bo = bo;
continue;
}
- if (place && !bdev->funcs->eviction_valuable(bo,
- place)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
if (!ttm_bo_get_unless_zero(bo)) {
if (locked)
dma_resv_unlock(bo->base.resv);
@@ -1140,10 +1148,19 @@ EXPORT_SYMBOL(ttm_bo_wait);
int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
gfp_t gfp_flags)
{
+ struct ttm_place place;
bool locked;
int re
[Intel-gfx] [PATCH v8 12/15] drm/i915/lmem: Verify checks for lmem residency
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by Mattew Auld)
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 42 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 18 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++
4 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index caf0414e0b50..f947295d7e53 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11756,7 +11756,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 2b8cd15de1d9..d539dffa1554 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,10 +23,50 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
}
+/**
+ * i915_gem_object_validates_to_lmem - Whether the object is resident in
+ * lmem when pages are present.
+ * @obj: The object to check.
+ *
+ * Migratable objects residency may change from under us if the object is
+ * not pinned or locked. This function is intended to be used to check whether
+ * the object can only reside in lmem when pages are present.
+ *
+ * Return: Whether the object is always resident in lmem when pages are
+ * present.
+ */
+bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+ return !i915_gem_object_migratable(obj) &&
+ mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
+}
+
+/**
+ * i915_gem_object_is_lmem - Whether the object is resident in
+ * lmem
+ * @obj: The object to check.
+ *
+ * Even if an object is allowed to migrate and change memory region,
+ * this function checks whether it will always be present in lmem when
+ * valid *or* if that's not the case, whether it's currently resident in lmem.
+ * For migratable and evictable objects, the latter only makes sense when
+ * the object is locked.
+ *
+ * Return: Whether the object migratable but resident in lmem, or not
+ * migratable and will be present in lmem when valid.
+ */
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
- struct intel_memory_region *mr = obj->mm.region;
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+#ifdef CONFIG_LOCKDEP
+ if (i915_gem_object_migratable(obj) &&
+ i915_gem_object_evictable(obj))
+ assert_object_held(obj);
+#endif
return mr && (mr->type == INTEL_MEMORY_LOCAL ||
mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 16eac5ea9238..cf18c430d51f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -457,6 +457,24 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object
*obj)
return pin_count == 0;
}
+/**
+ * i915_gem_object_migratable - Whether the object is migratable out of the
+ * current region.
+ * @obj: Pointer to the object.
+ *
+ * Return: Whether the object is allowed to be resident in other
+ * regions than the current while pages are present.
+ */
+bool i915_gem_object_migratable(struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+ if (!mr)
+ return false;
+
+ return obj->mm.n_placements > 1;
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ae5930e307d5..a3ad8cf4eefd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -596,6 +596,10 @@ void __i915_gem_free_object(struct drm_i915_gem_object
*obj);
bool i915_gem_object_evictable(struct drm_i915_gem_object *obj);
+bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
+
+bool i915_gem_objec
[Intel-gfx] [PATCH v8 11/15] drm/i915/ttm: Introduce a TTM i915 gem object backend
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects) is not
visible to i915 GEM yet. The plan is to move the i915 gem system region
over to the TTM system memory type in upcoming patches.
We set up GPU bindings directly both from LMEM and from the system region,
as there is no need to use the legacy TTM_TT memory type. We reserve
that for future porting of GGTT bindings to TTM.
Remove the old lmem backend.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Break out needed TTM functionality to a separate patch (Reported by
Christian König).
- Fix an unhandled error (Reported by Matthew Auld and Maarten Lankhorst)
- Remove a stray leftover sg_table allocation (Reported by Matthew Auld)
- Use ttm_tt_unpopulate() rather than ttm_tt_destroy() in the purge path
as some TTM functionality relies on having a ttm_tt present for !is_iomem.
v3:
- Use ttm_bo_type_device for userspace visible objects so that TTM can
allocate an address space offset for mmap'ing.
- Fix up the destruction path (Reported by Matthew Auld)
- Use ttm_bo_validate() for purging (Reported by Christian König)
- Create ttm_tts write-combined as they are currently for eviction only and
we want to maintain consistent write-combined caching for bos that are
not in system only. (Suggested by Daniel Vetter)
- Make struct ttm_placements static.
- Add the ttm device funcs/ops to i915_gem_ttm.h for the region code.
- Rename new->dst and old->src. Check for swapin in the move callback.
v4:
- Adapt to small interface change in ttm_move_memcpy.
- Use a function to pull out the ttm driver from the backend.
v6:
- Remove the ttm device verify_access assignment. The member is gone
upstream.
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 84 ---
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_object.c| 125 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 9 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 540 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 48 ++
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 5 +-
drivers/gpu/drm/i915/intel_memory_region.c| 1 -
drivers/gpu/drm/i915/intel_memory_region.h| 1 -
drivers/gpu/drm/i915/intel_region_ttm.c | 8 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 11 +-
16 files changed, 730 insertions(+), 153 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f22cac1c49b..f57dfc74d6ce 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,6 +155,7 @@ gem-y += \
gem/i915_gem_stolen.o \
gem/i915_gem_throttle.o \
gem/i915_gem_tiling.o \
+ gem/i915_gem_ttm.o \
gem/i915_gem_userptr.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 548ddf39d853..93bf63bbaff1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -85,13 +85,10 @@ i915_gem_setup(struct drm_i915_gem_object *obj, u64 size)
return -E2BIG;
/*
-* For now resort to CPU based clearing for device local-memory, in the
-* near future this will use the blitter engine for accelerated, GPU
-* based clearing.
+* I915_BO_ALLOC_USER will make sure the object is cleared before
+* any user access.
*/
- flags = 0;
- if (mr->type == INTEL_MEMORY_LOCAL)
- flags = I915_BO_ALLOC_CPU_CLEAR;
+ flags = I915_BO_ALLOC_USER;
ret = mr->ops->init_object(mr, obj, size, flags);
if (ret)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 3b4aa28a076d..2b8cd15de1d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -4,74 +4,10 @@
*/
#include "intel_memory_region.h"
-#include "intel_region_ttm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
#include "i915_drv.h"
-static void lmem_put_pages(struct drm_i915_gem_object *obj,
- struct sg_table *pages)
-{
- intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node);
- obj->mm.dirty = false;
- sg_free_
[Intel-gfx] [PATCH v8 13/15] drm/i915: Disable mmap ioctl for gen12+
From: Maarten Lankhorst
The platform should exclusively use mmap_offset, one less path to worry
about for discrete.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index f6fe5cb01438..fd1c9714f8d8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -56,10 +56,17 @@ int
i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
+ struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_mmap *args = data;
struct drm_i915_gem_object *obj;
unsigned long addr;
+ /* mmap ioctl is disallowed for all platforms after TGL-LP. This also
+* covers all platforms with local memory.
+*/
+ if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
+ return -EOPNOTSUPP;
+
if (args->flags & ~(I915_MMAP_WC))
return -EINVAL;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 14/15] drm/vma: Add a driver_private member to vma_node.
From: Maarten Lankhorst
This allows drivers to distinguish between different types of vma_node's.
The readonly flag was unused and is thus removed.
This is a temporary solution, until i915 is converted completely to
use ttm for bo's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
Acked-by: Daniel Vetter #irc
---
drivers/gpu/drm/drm_gem.c | 9 -
include/drm/drm_vma_manager.h | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9989425e9875..e710e79069f6 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1149,15 +1149,6 @@ int drm_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return -EACCES;
}
- if (node->readonly) {
- if (vma->vm_flags & VM_WRITE) {
- drm_gem_object_put(obj);
- return -EINVAL;
- }
-
- vma->vm_flags &= ~VM_MAYWRITE;
- }
-
ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT,
vma);
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 76ac5e97a559..4f8c35206f7c 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -53,7 +53,7 @@ struct drm_vma_offset_node {
rwlock_t vm_lock;
struct drm_mm_node vm_node;
struct rb_root vm_files;
- bool readonly:1;
+ void *driver_private;
};
struct drm_vma_offset_manager {
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 15/15] drm/i915: Use ttm mmap handling for ttm bo's.
From: Maarten Lankhorst
Use the ttm handlers for servicing page faults, and vm_access.
We do our own validation of read-only access, otherwise use the
ttm handlers as much as possible.
Because the ttm handlers expect the vma_node at vma->base, we slightly
need to massage the mmap handlers to look at vma_node->driver_private
to fetch the bo, if it's NULL, we assume i915's normal mmap_offset uapi
is used.
This is the easiest way to achieve compatibility without changing ttm's
semantics.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
- Fixed some minor style issues. (Thomas Hellström)
- Added a mutex Destroy (Thomas Hellström)
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 83
drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 121 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 90 ++---
drivers/gpu/drm/i915/selftests/igt_mmap.c | 25 +++-
drivers/gpu/drm/i915/selftests/igt_mmap.h | 12 +-
8 files changed, 251 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fd1c9714f8d8..d1de97e4adfd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -19,6 +19,7 @@
#include "i915_gem_mman.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
+#include "i915_gem_ttm.h"
#include "i915_vma.h"
static inline bool
@@ -622,6 +623,8 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
struct i915_mmap_offset *mmo;
int err;
+ GEM_BUG_ON(obj->ops->mmap_offset || obj->ops->mmap_ops);
+
mmo = lookup_mmo(obj, mmap_type);
if (mmo)
goto out;
@@ -664,40 +667,47 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
}
static int
-__assign_mmap_offset(struct drm_file *file,
-u32 handle,
+__assign_mmap_offset(struct drm_i915_gem_object *obj,
enum i915_mmap_type mmap_type,
-u64 *offset)
+u64 *offset, struct drm_file *file)
{
- struct drm_i915_gem_object *obj;
struct i915_mmap_offset *mmo;
- int err;
- obj = i915_gem_object_lookup(file, handle);
- if (!obj)
- return -ENOENT;
+ if (i915_gem_object_never_mmap(obj))
+ return -ENODEV;
- if (i915_gem_object_never_mmap(obj)) {
- err = -ENODEV;
- goto out;
+ if (obj->ops->mmap_offset) {
+ *offset = obj->ops->mmap_offset(obj);
+ return 0;
}
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i915_gem_object_has_struct_page(obj) &&
- !i915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM)) {
- err = -ENODEV;
- goto out;
- }
+ !i915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM))
+ return -ENODEV;
mmo = mmap_offset_attach(obj, mmap_type, file);
- if (IS_ERR(mmo)) {
- err = PTR_ERR(mmo);
- goto out;
- }
+ if (IS_ERR(mmo))
+ return PTR_ERR(mmo);
*offset = drm_vma_node_offset_addr(&mmo->vma_node);
- err = 0;
-out:
+ return 0;
+}
+
+static int
+__assign_mmap_offset_handle(struct drm_file *file,
+ u32 handle,
+ enum i915_mmap_type mmap_type,
+ u64 *offset)
+{
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ obj = i915_gem_object_lookup(file, handle);
+ if (!obj)
+ return -ENOENT;
+
+ err = __assign_mmap_offset(obj, mmap_type, offset, file);
i915_gem_object_put(obj);
return err;
}
@@ -717,7 +727,7 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
else
mmap_type = I915_MMAP_TYPE_GTT;
- return __assign_mmap_offset(file, handle, mmap_type, offset);
+ return __assign_mmap_offset_handle(file, handle, mmap_type, offset);
}
/**
@@ -785,7 +795,7 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void
*data,
return -EINVAL;
}
- return __assign_mmap_offset(file, args->handle, type, &args->offset);
+ return __assign_mmap_offset_handle(file, args->handle, type,
&args->offset);
}
static void vm_open(struct vm_area_struct *vma)
@@ -889,8 +899,18 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
* destroyed and will be invalid when the vma manager lock
* is released.
*/
- mmo = container_of(node, struct i915_mmap_offset, vma_node);
- obj = i915_gem_object_get_rcu(mmo->obj);
+ if (!node->driver_private) {
+ mmo =
Re: [Intel-gfx] New uAPI for color management proposal and feedback request
Am 12.05.21 um 19:59 schrieb Alex Deucher: > On Wed, May 12, 2021 at 9:04 AM Ville Syrjälä > wrote: >> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: >>> Hello, >>> >>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm >>> properties I propose 4 new properties: >>> "preferred pixel encoding", "active color depth", "active color range", and >>> "active pixel encoding" >>> >>> >>> Motivation: >>> >>> Current monitors have a variety pixel encodings available: RGB, YCbCr >>> 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. >>> >>> In addition they might be full or limited RGB range and the monitors accept >>> different bit depths. >>> >>> Currently the kernel driver for AMD and Intel GPUs automatically configure >>> the color settings automatically with little >>> to no influence of the user. However there are several real world scenarios >>> where the user might disagree with the >>> default chosen by the drivers and wants to set his or her own preference. >>> >>> Some examples: >>> >>> 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color >>> information, some screens might look better on one >>> than the other because of bad internal conversion. The driver currently >>> however has a fixed default that is chosen if >>> available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change >>> this currently is by editing and overloading >>> the edid reported by the monitor to the kernel. >>> >>> 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some >>> hardware might report that it supports the higher >>> port clock, but because of bad shielding on the PC, the cable, or the >>> monitor the screen cuts out every few seconds when >>> RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine >>> without changing hardware. The drivers >>> currently however always default to the "best available" option even if it >>> might be broken. >>> >>> 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color >>> by rapidly switching between 2 adjacent >>> colors. They advertise themselves to the kernel as 10-bit monitors but the >>> user might not like the "fake" 10-bit effect >>> and prefer running at the native 8-bit per color. >>> >>> 4. Some screens are falsely classified as full RGB range wile they actually >>> use limited RGB range. This results in >>> washed out colors in dark and bright scenes. A user override can be helpful >>> to manually fix this issue when it occurs. >>> >>> There already exist several requests, discussion, and patches regarding the >>> thematic: >>> >>> - https://gitlab.freedesktop.org/drm/amd/-/issues/476 >>> >>> - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 >>> >>> - https://lkml.org/lkml/2021/5/7/695 >>> >>> - https://lkml.org/lkml/2021/5/11/416 >>> >>> >>> Current State: >>> >>> I only know bits about the Intel i915 and AMD amdgpu driver. I don't know >>> how other driver handle color management >>> >>> - "max bpc", global setting applied by both i915 (only on dp i think?) and >>> amdgpu. Default value is "8". For every >>> resolution + frequency combination the highest possible even number between >>> 6 and max_bpc is chosen. If the range >>> doesn't contain a valid mode the resolution + frequency combination is >>> discarded (but I guess that would be a very >>> special edge case, if existent at all, when 6 doesn't work but 10 would >>> work). Intel HDMI code always checks 8, 12, and >>> 10 and does not check the max_bpc setting. >> i915 does limit things below max_bpc for both HDMI and DP. >> >>> - "Broadcast RGB" for i915 and "output_csc" for the old radeon driver (not >>> amdgpu), overwrites the kernel chosen color >>> range setting (full or limited). If I recall correctly Intel HDMI code >>> defaults to full unless this property is set, >>> Intel dp code tries to probe the monitor to find out what to use. amdgpu >>> has no corresponding setting (I don't know how >>> it's decided there). >> i915 has the same behaviour for HDMI and DP, as per the CTA-861/DP >> specs. Unfortunately as you already mentioned there are quite a few >> monitors (DP monitors in particular) that don't implemnt the spec >> correctly. IIRC later DP specs even relaxed the wording to say >> that you can basically ignore the spec and do whatever you want. >> Which I supose is just admitting defeat and concluding that there >> is no way to get this right 100% of the time. >> >>> - RGB pixel encoding can be forced by overloading a Monitors edid with one >>> that tells the kernel that only RGB is >>> possible. That doesn't work for YCbCr 4:4:4 however because of the edid >>> specification. Forcing YCbCr 4:2:0 would >>> theoretically also be possible this way. amdgpu has a debugfs switch >>> "force_ycbcr_420" which makes the driver default to >>> YCbCr 4:2:0 on all monitors if possible. >>> >>> >>> Proposed Solution: >>> >>> 1. Add a new uAPI property "preferred pixel encoding", as a
Re: [Intel-gfx] New uAPI for color management proposal and feedback request
Am 19.05.21 um 15:49 schrieb Ville Syrjälä: > On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote: >> On Wed, 12 May 2021 16:04:16 +0300 >> Ville Syrjälä wrote: >> >>> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote: Hello, In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm properties I propose 4 new properties: "preferred pixel encoding", "active color depth", "active color range", and "active pixel encoding" Motivation: Current monitors have a variety pixel encodings available: RGB, YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0. In addition they might be full or limited RGB range and the monitors accept different bit depths. Currently the kernel driver for AMD and Intel GPUs automatically configure the color settings automatically with little to no influence of the user. However there are several real world scenarios where the user might disagree with the default chosen by the drivers and wants to set his or her own preference. Some examples: 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color information, some screens might look better on one than the other because of bad internal conversion. The driver currently however has a fixed default that is chosen if available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change this currently is by editing and overloading the edid reported by the monitor to the kernel. 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some hardware might report that it supports the higher port clock, but because of bad shielding on the PC, the cable, or the monitor the screen cuts out every few seconds when RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine without changing hardware. The drivers currently however always default to the "best available" option even if it might be broken. 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color by rapidly switching between 2 adjacent colors. They advertise themselves to the kernel as 10-bit monitors but the user might not like the "fake" 10-bit effect and prefer running at the native 8-bit per color. 4. Some screens are falsely classified as full RGB range wile they actually use limited RGB range. This results in washed out colors in dark and bright scenes. A user override can be helpful to manually fix this issue when it occurs. There already exist several requests, discussion, and patches regarding the thematic: - https://gitlab.freedesktop.org/drm/amd/-/issues/476 - https://gitlab.freedesktop.org/drm/amd/-/issues/1548 - https://lkml.org/lkml/2021/5/7/695 - https://lkml.org/lkml/2021/5/11/416 >> ... >> Adoption: A KDE dev wants to implement the settings in the KDE settings GUI: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370 Tuxedo Computers (my employer) wants to implement the settings desktop environment agnostic in Tuxedo Control Center. I will start work on this in parallel to implementing the new kernel code. >>> I suspect everyone would be happier to accept new uapi if we had >>> multiple compositors signed up to implement it. >> I think having Weston support for these would be good, but for now it >> won't be much of an UI: just weston.ini to set, and the log to see what >> happened. >> >> However, knowing what happened is going to be important for color >> calibration auditing: >> https://gitlab.freedesktop.org/wayland/weston/-/issues/467 >> >> Yes, please, very much for read-only properties for the feedback part. >> Properties that both userspace and kernel will write are hard to deal >> with in general. >> >> Btw. "max bpc" I can kind of guess that conversion from framebuffer >> format to the wire bpc happens automatically and only as the final >> step, > Well, there could be dithering and whatnot also involved. So it's > not super well specified atm either. > >> but "Broadcast RGB" is more complicated: is the output from the >> abstract pixel pipeline sent as-is and "Broadcast RGB" is just another >> inforframe bit to the monitor, or does "Broadcast RGB" setting actually >> change what happens in the pixel pipeline *and* set infoframe bits? > It does indeed compress the actual pixel data. There was once a patch > porposed to introduce a new enum value that only sets the infoframe and > thus would allow userspace to pass through already limited range data. > Shouldn't be hard to resurrect that if needed. For the time being I try to keep the functionality of Broadcast RGB the same and just port it over to AMDGPU, but i haven't looked into it in detail yet. > >> My vague recollection is that framebuffer w
Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
Ville, Thanks for the additional detail! I looked up HPD and understand it is hot plug detection, but I didn't find much for "one byte caps format". I assume this is short hand for "capability format". Is the "one byte" format a limitation from the monitor, the dongle, the motherboard, or the chipset? What are some examples of other "capability formats"? Is there a recommended approach to setting the port to support Dual-Link based on EDID response (or is it too late by the time we get the EDID)? If there is no obvious automatic solution, do you have an example of a "manual override" (i.e. module argument) for another situation I can use as a guide? Still curious what DPCD DFP stands for. Thanks, Adam On Mon, May 31, 2021, at 10:15 AM, Ville Syrjälä wrote: > On Fri, May 28, 2021 at 02:15:46PM -0400, Adam Chasen wrote: > > Any further advice on tracing what is triggering what appears to be the > > limitation of the clock? My guess is it is imposing a DVI Single-Link speed > > (165000) limitation on the dual-link DVI adapter. > > > > > TMDS clock 25000-165000 > > > > I am able to override in xorg with xrandr to 268500 > > > > Per Ville's request: > > DPCD DFP: 0a > > > > What is the DPCD DFP? > > It indicates the port is DVI with HPD capability. But unfortunately it's > using the one byte caps format which doesn't let us differentiate > between single link and dual link DVI. So we take the more cautious > apporach and assume it's single link. > > > > > Thanks, > > Adam > > > > On Wed, May 12, 2021, at 5:07 PM, Adam Chasen wrote: > > > Ville, > > > DPCD DFP: 0a > > > > > > What is the DPCD DFP? > > > > > > Additional info, this is the first time there has been an issue with > > > this adapter not working (i.e. it must have been operating above > > > 165MHz), but it is possible other drivers have "ignored" things and > > > just followed the EDID. > > > > > > Thanks! > > > Adam > > > > > > kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > > > [CONNECTOR:95:DP-1] > > > kernel: i915 :00:02.0: [drm:intel_dp_detect [i915]] > > > [CONNECTOR:95:DP-1] > > > kernel: [drm:drm_dp_read_dpcd_caps [drm_kms_helper]] AUX C/DDI C/PHY C: > > > DPCD: 11 0a 84 01 00 05 00 81 00 00 00 00 00 00 00 > > > kernel: [drm:drm_dp_read_desc [drm_kms_helper]] AUX C/DDI C/PHY C: DP > > > branch: OUI 00-80-e1 dev-ID m2DVIa HW-rev 0.1 SW-rev 2.0 quirks 0x > > > kernel: [drm:drm_dp_read_downstream_info [drm_kms_helper]] AUX C/DDI > > > C/PHY C: DPCD DFP: 0a > > > kernel: i915 :00:02.0: [drm:intel_dp_detect [i915]] [ENCODER:94:DDI > > > C/PHY C] MST support: port: yes, sink: no, modparam: yes > > > kernel: i915 :00:02.0: [drm:intel_dp_print_rates [i915]] source > > > rates: 162000, 216000, 27, 324000, 432000, 54 > > > kernel: i915 :00:02.0: [drm:intel_dp_print_rates [i915]] sink > > > rates: 162000, 27 > > > kernel: i915 :00:02.0: [drm:intel_dp_print_rates [i915]] common > > > rates: 162000, 27 > > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > > native defer > > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > > native defer > > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > > native defer > > > kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: > > > native defer > > > kernel: i915 :00:02.0: [drm:intel_dp_set_edid [i915]] > > > [CONNECTOR:95:DP-1] DFP max bpc 8, max dotclock 0, TMDS clock > > > 25000-165000 > > > kernel: i915 :00:02.0: [drm:intel_dp_set_edid [i915]] > > > [CONNECTOR:95:DP-1] YCbCr 4:2:0 allowed? no, YCbCr 4:4:4->4:2:0 > > > conversion? no > > > kernel: [drm:drm_dp_get_edid_quirks [drm_kms_helper]] DP sink: EDID mfg > > > 22-f0 prod-ID 90-26 quirks: 0x > > > kernel: [drm:drm_add_edid_modes [drm]] ELD: no CEA Extension found > > > kernel: [drm:drm_add_display_info [drm]] Supported Monitor Refresh rate > > > range is 0 Hz - 0 Hz > > > kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0 > > > kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": > > > 60 268000 2560 2608 2640 2720 1600 1603 1609 1646 0x48 0x9 > > > kernel: [drm:drm_mode_prune_invalid [drm]] Not using 2560x1600 mode: > > > CLOCK_HIGH > > > kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > > > [CONNECTOR:95:DP-1] probed modes : > > > kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "1280x800": > > > 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9 > > > > > > # for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 count=16 > > > skip=$((0x80)) 2>/dev/null | hexdump -C ; done > > > 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > || > > > 0010 > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > || > > > 0010 > > > > > > # for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 2>/dev/null | > > > hexdump -C ; done
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Move LMEM (VRAM) management over to TTM (rev4)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev4) URL : https://patchwork.freedesktop.org/series/90681/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6de8c27efb29 drm/i915: Untangle the vma pages_mutex 8736b0670431 drm/i915: Don't free shared locks while shared 5c70526b5b0a drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages 3241ba8c38d7 drm/i915/ttm Initialize the ttm device and memory managers -:480: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #480: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1531 lines checked f32e448037d9 drm/i915/ttm: Embed a ttm buffer object in the i915 gem object 72d7aa2b6e3d drm/ttm: Add a generic TTM memcpy move for page-based iomem -:385: CHECK:ARCH_DEFINES: architecture specific defines should be avoided #385: FILE: drivers/gpu/drm/ttm/ttm_module.c:56: +#if defined(__i386__) || defined(__x86_64__) -:728: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #728: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 840 lines checked c6a460918b4c drm: Add a prefetching memcpy_from_wc 9e816089e010 drm/ttm: Use drm_memcpy_from_wc for TTM bo moves 9e663526255d drm/ttm: Document and optimize ttm_bo_pipeline_gutting() c6772d8d4e09 drm/ttm, drm/amdgpu: Allow the driver some control over swapping 352563b73985 drm/i915/ttm: Introduce a TTM i915 gem object backend -:449: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #449: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1042 lines checked 78d583a5e067 drm/i915/lmem: Verify checks for lmem residency 9252e2a7b44c drm/i915: Disable mmap ioctl for gen12+ b67ba63965f5 drm/vma: Add a driver_private member to vma_node. c510fe8b6eed drm/i915: Use ttm mmap handling for ttm bo's. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move LMEM (VRAM) management over to TTM (rev4)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev4) URL : https://patchwork.freedesktop.org/series/90681/ 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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdg
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2.
== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active, v2. URL : https://patchwork.freedesktop.org/series/90795/ State : success == Summary == CI Bug Log - changes from CI_DRM_10152_full -> Patchwork_20239_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20239_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: NOTRUN -> [DMESG-WARN][1] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-snb5/igt@gem_ctx_persiste...@idempotent.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-apl6/igt@gem_exec_fair@basic-n...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-apl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271]) +151 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2389]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_whisper@basic-queues-forked: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-glk2/igt@gem_exec_whis...@basic-queues-forked.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-glk9/igt@gem_exec_whis...@basic-queues-forked.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: NOTRUN -> [INCOMPLETE][13] ([i915#3468]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-skl: NOTRUN -> [INCOMPLETE][14] ([i915#198] / [i915#2910] / [i915#3468]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-skl5/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy-odd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_mmap_gtt@cpuset-medium-copy-xy: - shard-apl: [PASS][17] -> [INCOMPLETE][18] ([i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-apl6/igt@gem_mmap_...@cpuset-medium-copy-xy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-apl3/igt@gem_mmap_...@cpuset-medium-copy-xy.html - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10152/shard-iclb4/igt@gem_mmap_...@cpuset-medium-copy-xy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-iclb7/igt@gem_mmap_...@cpuset-medium-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent: - shard-snb: NOTRUN -> [INCOMPLETE][21] ([i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-snb5/igt@gem_mmap_...@fault-concurrent.html - shard-kbl: NOTRUN -> [INCOMPLETE][22] ([i915#3468]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20239/shard-kbl3/igt@gem_mmap_...@fault-concurrent.html * igt@gem_render_copy@y-tiled-mc-ccs-to-y-tiled-ccs: - shard-iclb: NOTRUN -> [SKIP][23] ([i
[Intel-gfx] ✓ Fi.CI.BAT: success for Move LMEM (VRAM) management over to TTM (rev4)
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev4)
URL : https://patchwork.freedesktop.org/series/90681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10153 -> Patchwork_20240
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20240:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_tiled_fence_blits@basic:
- {fi-rkl-11500t}:[FAIL][1] ([i915#3277]) -> [FAIL][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-rkl-11500t/igt@gem_tiled_fence_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-rkl-11500t/igt@gem_tiled_fence_bl...@basic.html
* igt@kms_busy@basic:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][3] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-rkl-11500t/igt@kms_b...@basic.html
* igt@prime_self_import@basic-with_two_bos:
- {fi-rkl-11500t}:[PASS][4] -> [FAIL][5] +4 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-rkl-11500t/igt@prime_self_import@basic-with_two_bos.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-rkl-11500t/igt@prime_self_import@basic-with_two_bos.html
* igt@prime_vgem@basic-fence-flip:
- {fi-rkl-11500t}:[PASS][6] -> [SKIP][7] +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-rkl-11500t/igt@prime_v...@basic-fence-flip.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-rkl-11500t/igt@prime_v...@basic-fence-flip.html
* igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:[SKIP][8] ([i915#3291]) -> [SKIP][9] +2 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-rkl-11500t/igt@prime_v...@basic-read.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-rkl-11500t/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- {fi-rkl-11500t}:[SKIP][10] ([i915#3301]) -> [SKIP][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-rkl-11500t/igt@prime_v...@basic-userptr.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-rkl-11500t/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_20240 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][12] ([i915#2283])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_selftest@live@execlists:
- fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][13] ([i915#3462])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][15] -> [DMESG-WARN][16] ([i915#2868])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][17] ([fdo#109271]) +9 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][18] ([i915#3303]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [FAIL][20] ([i915#3049]) -> [SKIP][21] ([fdo#109271])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [INCOMPLETE][22] ([i915#3462]) -> [DMESG-FAIL][23]
([i915#3462])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[Intel-gfx] [PATCH v2 0/2] GPD Win Max display fixes
This patch series is for making the GPD Win Max display usable with Linux. The GPD Win Max is a small laptop, and its eDP panel does not send an EDID over DPCD; the EDID is instead available in the intel opregion, in mailbox #5 [1] The first patch is based on Jani's patch series [2] adding support for the opregion, with changes. I've changed authorship, but I'd be glad to revert it The second patch is just to fix the orientation of the panel. Changes since v1: - rebased on drm-tip - squashed patch 1 & 2 - picked up Reviewed-by from Hans de Goede (thanks for the review) [1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454 [2]: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/ Anisse Astier (2): drm/i915/opregion: add support for mailbox #5 EDID drm: Add orientation quirk for GPD Win Max .../gpu/drm/drm_panel_orientation_quirks.c| 6 ++ drivers/gpu/drm/i915/display/intel_dp.c | 3 + drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++- drivers/gpu/drm/i915/display/intel_opregion.h | 8 +++ 4 files changed, 85 insertions(+), 1 deletion(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm: Add orientation quirk for GPD Win Max
Panel is 800x1280, but mounted on a laptop form factor, sideways.
Reviewed-by: Hans de Goede
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index f6bdec7fa925..3c3f4ed89173 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -148,6 +148,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MicroPC"),
},
.driver_data = (void *)&lcd720x1280_rightside_up,
+ }, {/* GPD Win Max */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1619-01"),
+ },
+ .driver_data = (void *)&lcd800x1280_rightside_up,
}, {/*
* GPD Pocket, note that the the DMI data is less generic then
* it seems, devices with a board-vendor of "AMI Corporation"
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/opregion: add support for mailbox #5 EDID
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.
Fixes the GPD Win Max display.
Based on original patch series by: Jani Nikula
https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
Changes:
- EDID is copied and validated with drm_edid_is_valid
- Mode is now added via drm_add_edid_modes instead of using override
mechanism
- squashed the two patches
Cc: Jani Nikula
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +
drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
drivers/gpu/drm/i915/display/intel_opregion.h | 8 +++
3 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..43fb485c0e02 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5191,6 +5191,9 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
+ /* Set up override EDID, if any, from ACPI OpRegion */
+ intel_opregion_edid_probe(intel_connector);
+
mutex_lock(&dev->mode_config.mutex);
edid = drm_get_edid(connector, &intel_dp->aux.ddc);
if (edid) {
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index dfd724e506b5..ef8d38f041eb 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -196,6 +196,8 @@ struct opregion_asle_ext {
#define ASLE_IUER_WINDOWS_BTN (1 << 1)
#define ASLE_IUER_POWER_BTN(1 << 0)
+#define ASLE_PHED_EDID_VALID_MASK 0x3
+
/* Software System Control Interrupt (SWSCI) */
#define SWSCI_SCIC_INDICATOR (1 << 0)
#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
@@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
opregion->asle->ardy = ASLE_ARDY_NOT_READY;
}
- if (mboxes & MBOX_ASLE_EXT)
+ if (mboxes & MBOX_ASLE_EXT) {
drm_dbg(&dev_priv->drm, "ASLE extension supported\n");
+ opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
+ }
if (intel_load_vbt_firmware(dev_priv) == 0)
goto out;
@@ -1037,6 +1041,68 @@ intel_opregion_get_panel_type(struct drm_i915_private
*dev_priv)
return ret - 1;
}
+/**
+ * intel_opregion_edid_probe - Add EDID from ACPI OpRegion mailbox #5
+ * @intel_connector: eDP connector
+ *
+ * This reads the ACPI Opregion mailbox #5 to extract the EDID that is passed
+ * to it.
+ *
+ * Will take a lock on the DRM mode_config to add the EDID; make sure it isn't
+ * called with lock taken.
+ *
+ */
+void intel_opregion_edid_probe(struct intel_connector *intel_connector)
+{
+ struct drm_connector *connector = &intel_connector->base;
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ struct intel_opregion *opregion = &i915->opregion;
+ const void *in_edid;
+ const struct edid *edid;
+ struct edid *new_edid;
+ int len, ret, num;
+
+ if (!opregion->asle_ext || connector->override_edid)
+ return;
+
+ in_edid = opregion->asle_ext->bddc;
+
+ /* Validity corresponds to number of 128-byte blocks */
+ len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
+ if (!len || !memchr_inv(in_edid, 0, len))
+ return;
+
+ edid = in_edid;
+
+ if (len < EDID_LENGTH * (1 + edid->extensions)) {
+ drm_dbg_kms(&i915->drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5)\n");
+ return;
+ }
+ new_edid = drm_edid_duplicate(edid);
+ if (!new_edid) {
+ drm_err(&i915->drm, "Cannot duplicate EDID\n");
+ return;
+ }
+ if (!drm_edid_is_valid(new_edid)) {
+ kfree(new_edid);
+ drm_dbg_kms(&i915->drm, "Cannot validate EDID in ACPI OpRegion
(Mailbox #5)\n");
+ return;
+ }
+
+ ret = drm_connector_update_edid_property(connector, new_edid);
+ if (ret) {
+ kfree(new_edid);
+ return;
+ }
+
+ mutex_lock(&connector->dev->mode_config.mutex);
+ num = drm_add_edid_modes(connector, new_edid);
+ mutex_unlock(&connector->dev->mode_config.mutex);
+
+ drm_dbg_kms(&i915->drm, "Using OpRegion EDID for [CONNECTOR:%d:%s],
added %d mode(s)\n",
+ connector->base.id, connector->name, num);
+}
+
void intel_opregion_register(struct drm_i915_private *i915)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GPD Win Max display fixes (rev2)
== Series Details == Series: GPD Win Max display fixes (rev2) URL : https://patchwork.freedesktop.org/series/90483/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8d4543be1dff drm/i915/opregion: add support for mailbox #5 EDID -:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #20: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/ total: 0 errors, 1 warnings, 0 checks, 141 lines checked 8873d6deae22 drm: Add orientation quirk for GPD Win Max ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GPD Win Max display fixes (rev2)
== Series Details == Series: GPD Win Max display fixes (rev2) URL : https://patchwork.freedesktop.org/series/90483/ 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:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (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:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488: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: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include
[Intel-gfx] ✓ Fi.CI.BAT: success for GPD Win Max display fixes (rev2)
== Series Details ==
Series: GPD Win Max display fixes (rev2)
URL : https://patchwork.freedesktop.org/series/90483/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10153 -> Patchwork_20241
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/index.html
Known issues
Here are the changes found in Patchwork_20241 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][1] ([i915#2283])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@i915_selftest@live@execlists:
- fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][2] ([i915#3462])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2: [PASS][4] -> [FAIL][5] ([i915#2416])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][7] ([i915#3303]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [FAIL][9] ([i915#3049]) -> [SKIP][10] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][11] ([i915#2782] / [i915#2940] /
[i915#3462]) -> [DMESG-FAIL][12] ([i915#3462])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2: [DMESG-FAIL][13] ([i915#3462]) -> [INCOMPLETE][14]
([i915#3462])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-glk-dsi: [FAIL][15] ([i915#2426] / [i915#3363] /
[k.org#202321]) -> [FAIL][16] ([i915#3363] / [k.org#202321])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-glk-dsi/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-glk-dsi/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][17] ([i915#1602] / [i915#2029]) -> [FAIL][18]
([i915#3462])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-bdw-5557u/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bdw-5557u/igt@run...@aborted.html
- fi-bxt-dsi: [FAIL][19] ([i915#2426] / [i915#3363]) -> [FAIL][20]
([i915#3363])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-bxt-dsi/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-bxt-dsi/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][21] ([i915#1436] / [i915#3363]) -> [FAIL][22]
([i915#1436] / [i915#2426] / [i915#3363])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/fi-skl-6700k2/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/fi-skl-6700k2/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/
[Intel-gfx] ✗ Fi.CI.IGT: failure for Move LMEM (VRAM) management over to TTM (rev4)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev4) URL : https://patchwork.freedesktop.org/series/90681/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10153_full -> Patchwork_20240_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20240_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20240_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_20240_full: ### IGT changes ### Possible regressions * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-iclb2/igt@kms_plane_low...@pipe-a-tiling-y.html Known issues Here are the changes found in Patchwork_20240_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-iclb: NOTRUN -> [SKIP][2] ([i915#1839]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-iclb3/igt@feature_discov...@display-2x.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_shared@q-smoketest-all: - shard-glk: [PASS][4] -> [DMESG-WARN][5] ([i915#118] / [i915#95]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-glk2/igt@gem_ctx_sha...@q-smoketest-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-glk2/igt@gem_ctx_sha...@q-smoketest-all.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-iclb3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: NOTRUN -> [FAIL][9] ([i915#2842] / [i915#3468]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2849]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][12] ([fdo#112283]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-iclb2/igt@gem_exec_par...@secure-non-master.html * igt@gem_media_vme: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271]) +37 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-skl10/igt@gem_media_vme.html * igt@gem_mmap_gtt@big-copy: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#307]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-glk8/igt@gem_mmap_...@big-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-glk7/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#2910] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-iclb3/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-iclb6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-tglb7/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20240/shard-tglb6/igt@gem_mmap_...@cpuset-bas
[Intel-gfx] ✗ Fi.CI.IGT: failure for GPD Win Max display fixes (rev2)
== Series Details == Series: GPD Win Max display fixes (rev2) URL : https://patchwork.freedesktop.org/series/90483/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10153_full -> Patchwork_20241_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20241_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20241_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_20241_full: ### IGT changes ### Possible regressions * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-y.html Known issues Here are the changes found in Patchwork_20241_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +9 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-kbl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-glk: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-glk4/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2849]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][11] ([fdo#112283]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-iclb5/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2389]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_media_vme: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271]) +37 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-skl2/igt@gem_media_vme.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: NOTRUN -> [INCOMPLETE][14] ([i915#3468]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-apl3/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198] / [i915#3468]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-skl1/igt@gem_mmap_...@cpuset-basic-small-copy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-skl3/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10153/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy-xy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-y: - shard-snb: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-snb6/igt@gem_mmap_...@fault-concurrent-y.html * igt@gem_pread@exhaustion: - shard-snb: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20241/shard-snb5/igt@gem_pr...@exhaustion.html - shard-skl:
[Intel-gfx] linux-next: build failure after merge of the i2c tree
Hi all,
After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/gpu/drm/i915/i915_gem.c:1250:
drivers/gpu/drm/i915/selftests/i915_gem.c:97:13: error: conflicting types for
'pm_suspend'
97 | static void pm_suspend(struct drm_i915_private *i915)
| ^~
In file included from include/linux/regulator/consumer.h:35,
from include/linux/i2c.h:18,
from drivers/gpu/drm/i915/i915_drv.h:39,
from drivers/gpu/drm/i915/gt/intel_context.h:14,
from drivers/gpu/drm/i915/gem/i915_gem_context.h:12,
from drivers/gpu/drm/i915/i915_gem.c:44:
include/linux/suspend.h:331:12: note: previous declaration of 'pm_suspend' was
here
331 | extern int pm_suspend(suspend_state_t state);
|^~
Caused by commit
5a7b95fb993e ("i2c: core: support bus regulator controlling in adapter")
interacting with commit
3f51b7e1f36a ("drm/i915/selftests: Add a simple exerciser for
suspend/hibernate")
from Linus' tree (v4.20-rc1)
I have added the following merge fix patch:
From: Stephen Rothwell
Date: Tue, 1 Jun 2021 10:25:49 +1000
Subject: [PATCH] drm/i915/selftests: Avoid name clash with pm_ global functions
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/selftests/i915_gem.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index dc394fb7ccfa..5d674708b047 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -87,14 +87,14 @@ static void simulate_hibernate(struct drm_i915_private
*i915)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
}
-static int pm_prepare(struct drm_i915_private *i915)
+static int test_pm_prepare(struct drm_i915_private *i915)
{
i915_gem_suspend(i915);
return 0;
}
-static void pm_suspend(struct drm_i915_private *i915)
+static void test_pm_suspend(struct drm_i915_private *i915)
{
intel_wakeref_t wakeref;
@@ -104,7 +104,7 @@ static void pm_suspend(struct drm_i915_private *i915)
}
}
-static void pm_hibernate(struct drm_i915_private *i915)
+static void test_pm_hibernate(struct drm_i915_private *i915)
{
intel_wakeref_t wakeref;
@@ -116,7 +116,7 @@ static void pm_hibernate(struct drm_i915_private *i915)
}
}
-static void pm_resume(struct drm_i915_private *i915)
+static void test_pm_resume(struct drm_i915_private *i915)
{
intel_wakeref_t wakeref;
@@ -148,16 +148,16 @@ static int igt_gem_suspend(void *arg)
if (err)
goto out;
- err = pm_prepare(i915);
+ err = test_pm_prepare(i915);
if (err)
goto out;
- pm_suspend(i915);
+ test_pm_suspend(i915);
/* Here be dragons! Note that with S3RST any S3 may become S4! */
simulate_hibernate(i915);
- pm_resume(i915);
+ test_pm_resume(i915);
err = switch_to_context(ctx);
out:
@@ -183,16 +183,16 @@ static int igt_gem_hibernate(void *arg)
if (err)
goto out;
- err = pm_prepare(i915);
+ err = test_pm_prepare(i915);
if (err)
goto out;
- pm_hibernate(i915);
+ test_pm_hibernate(i915);
/* Here be dragons! */
simulate_hibernate(i915);
- pm_resume(i915);
+ test_pm_resume(i915);
err = switch_to_context(ctx);
out:
--
2.30.2
--
Cheers,
Stephen Rothwell
pgpB7_DzG91w0.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for linux-next: build failure after merge of the i2c tree
== Series Details == Series: linux-next: build failure after merge of the i2c tree URL : https://patchwork.freedesktop.org/series/90804/ State : failure == Summary == Applying: linux-next: build failure after merge of the i2c tree Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/selftests/i915_gem.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/selftests/i915_gem.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/selftests/i915_gem.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 linux-next: build failure after merge of the i2c tree When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_dp_dsc: Transmit correct DRM connector structure.
1. Pass one more parameter (current drmModeConnector) when
call "run_test()". Use it to retrieve proper connector_type.
2. SIGSEGV fault would happen due to "igt_output" did not
store properly in "data->output". Main funciton already
pass "igt_output" pointer into "run_test()" function.
Use this pointer instead of "data->output" to get display mode.
Fixes: a1772be7dede ("tests/kms_dp_dsc: Bug fix for DP on Pipe A")
Signed-off-by: Lee Shawn C
---
tests/kms_dp_dsc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/kms_dp_dsc.c b/tests/kms_dp_dsc.c
index ea7c9f4f72ce..e434384da369 100644
--- a/tests/kms_dp_dsc.c
+++ b/tests/kms_dp_dsc.c
@@ -224,11 +224,11 @@ static void update_display(data_t *data, enum
dsc_test_type test_type)
}
static void run_test(data_t *data, igt_output_t *output,
-enum dsc_test_type test_type)
+drmModeConnector *connector, enum dsc_test_type test_type)
{
enum pipe pipe;
- data->mode = igt_output_get_mode(data->output);
+ data->mode = igt_output_get_mode(output);
igt_create_pattern_fb(data->drm_fd, data->mode->hdisplay,
data->mode->vdisplay,
DRM_FORMAT_XRGB,
@@ -239,7 +239,7 @@ static void run_test(data_t *data, igt_output_t *output,
if (is_i915_device(data->drm_fd)) {
uint32_t devid = intel_get_drm_devid(data->drm_fd);
- if (data->connector->connector_type ==
DRM_MODE_CONNECTOR_DisplayPort &&
+ if (connector->connector_type ==
DRM_MODE_CONNECTOR_DisplayPort &&
data->pipe == PIPE_A && IS_GEN11(devid)) {
igt_debug("DSC not supported on Pipe A on
external DP in Gen11 platforms\n");
continue;
@@ -304,7 +304,7 @@ igt_main
continue;
}
test_conn_cnt++;
- run_test(&data, output, test_basic_dsc_enable);
+ run_test(&data, output, connector,
test_basic_dsc_enable);
}
igt_skip_on(test_conn_cnt == 0);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
