All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Ekstrand <jason@jlekstrand.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 13/21] drm/i915/gem: Add an intermediate proto_context struct
Date: Thu, 29 Apr 2021 11:44:42 -0500	[thread overview]
Message-ID: <CAOFGe94qNkG-8bUSMB0PudXQcs7C22mQqZR=NoPtSG6EHh0rpQ@mail.gmail.com> (raw)
In-Reply-To: <YIqufo0AsyRndhav@phenom.ffwll.local>

On Thu, Apr 29, 2021 at 8:02 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> The commit introducing a new data structure really should have a solid
> intro in the commit message about. Please cover
>
> - that ctx really should be immutable, safe for exceptions like priority
>
> - that unfortunately we butchered the uapi with setparam and sharing
>   setparams between create_ext and setparam
>
> - and how exactly proto ctx fixes this (with stuff like locking design
>   used)
>
> Maybe also dupe the kerneldoc into here for completeness.
> On Fri, Apr 23, 2021 at 05:31:23PM -0500, Jason Ekstrand wrote:
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 143 ++++++++++++++----
> >  .../gpu/drm/i915/gem/i915_gem_context_types.h |  21 +++
> >  .../gpu/drm/i915/gem/selftests/mock_context.c |  16 +-
>
> I'm wondering whether in the end we should split out the proto_ctx into
> its own file, with the struct private only to itself. But I guess
> impossible during the transition, and also maybe afterwards?
>
> >  3 files changed, 150 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 e5efd22c89ba2..3e883daab93bf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -191,6 +191,95 @@ 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 (test_bit(UCONTEXT_PERSISTENCE, &pc->user_flags) == persist)
> > +             return 0;
>
> We have compilers to optimize this kind of stuff, pls remove :-)
> Especially with the non-atomic bitops there's no point.

I thought at one point that this did have a purpose.  However, now
that I look at it harder, I'm pretty sure it doesn't.  Will drop.

> > +
> > +     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);
>
> It's a bit entetaining, but the bitops in the kernel are atomic. Which is
> hella confusing here.
>
> I think open coding is the standard for truly normal bitops.

There's __set_bit if you'd rather I use that.

> > +     } 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);
>
> Same here.
>
> > +     }
> > +
> > +     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;
> > +
> > +     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> > +         !HAS_EXECLISTS(i915))
> > +             return ERR_PTR(-EINVAL);
> > +
> > +     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));
> > +                     proto_context_close(pc);
> > +                     return ERR_CAST(ppgtt);
> > +             }
> > +             pc->vm = &ppgtt->vm;
> > +     }
> > +
> > +     pc->user_flags = 0;
> > +     set_bit(UCONTEXT_BANNABLE, &pc->user_flags);
> > +     set_bit(UCONTEXT_RECOVERABLE, &pc->user_flags);
>
> Same about atomic bitops here.

Changed to just initialize to BANNABLE | RECOVERABLE.

> > +     proto_context_set_persistence(i915, pc, true);
> > +     pc->sched.priority = I915_PRIORITY_NORMAL;
> > +
> > +     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE)
> > +             pc->single_timeline = true;
>
> bit a bikeshed, but I'd put the error checking in here too and deal with
> the unwind pain with the usual goto proto_close. That should also make the
> ppgtt unwind path a bit clearer because it sticks out in the standard way.

Sure.  Can do.

> > +
> > +     return pc;
> > +}
> > +
> >  static struct i915_address_space *
> >  context_get_vm_rcu(struct i915_gem_context *ctx)
> >  {
> > @@ -660,7 +749,8 @@ static int __context_set_persistence(struct i915_gem_context *ctx, bool state)
> >  }
> >
> >  static struct i915_gem_context *
> > -__create_context(struct drm_i915_private *i915)
> > +__create_context(struct drm_i915_private *i915,
> > +              const struct i915_gem_proto_context *pc)
> >  {
> >       struct i915_gem_context *ctx;
> >       struct i915_gem_engines *e;
> > @@ -673,7 +763,7 @@ __create_context(struct drm_i915_private *i915)
> >
> >       kref_init(&ctx->ref);
> >       ctx->i915 = i915;
> > -     ctx->sched.priority = I915_PRIORITY_NORMAL;
> > +     ctx->sched = pc->sched;
> >       mutex_init(&ctx->mutex);
> >       INIT_LIST_HEAD(&ctx->link);
> >
> > @@ -696,9 +786,7 @@ __create_context(struct drm_i915_private *i915)
> >        * is no remap info, it will be a NOP. */
> >       ctx->remap_slice = ALL_L3_SLICES(i915);
> >
> > -     i915_gem_context_set_bannable(ctx);
> > -     i915_gem_context_set_recoverable(ctx);
> > -     __context_set_persistence(ctx, true /* cgroup hook? */);
> > +     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;
> > @@ -786,38 +874,23 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
> >  }
> >
> >  static struct i915_gem_context *
> > -i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> > +i915_gem_create_context(struct drm_i915_private *i915,
> > +                     const struct i915_gem_proto_context *pc)
> >  {
> >       struct i915_gem_context *ctx;
> >       int ret;
> >
> > -     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> > -         !HAS_EXECLISTS(i915))
> > -             return ERR_PTR(-EINVAL);
> > -
> > -     ctx = __create_context(i915);
> > +     ctx = __create_context(i915, pc);
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > -     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));
> > -                     context_close(ctx);
> > -                     return ERR_CAST(ppgtt);
> > -             }
> > -
> > +     if (pc->vm) {
> >               mutex_lock(&ctx->mutex);
>
> I guess this dies later, but this mutex_lock here is superflous since
> right now no one else can get at our ctx struct. And nothing in
> __assign_ppgtt checks for us holding the lock.
>
> But fine if it only gets remove in the vm immutable patch.

Yeah, I think it gets dropped in the immutable patch.  I just didn't
want to perturb things more than necessary in this one.

> > -             __assign_ppgtt(ctx, &ppgtt->vm);
> > +             __assign_ppgtt(ctx, pc->vm);
> >               mutex_unlock(&ctx->mutex);
> > -
> > -             i915_vm_put(&ppgtt->vm);
> >       }
> >
> > -     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> > +     if (pc->single_timeline) {
> >               ret = drm_syncobj_create(&ctx->syncobj,
> >                                        DRM_SYNCOBJ_CREATE_SIGNALED,
> >                                        NULL);
> > @@ -883,6 +956,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
> >                         struct drm_file *file)
> >  {
> >       struct drm_i915_file_private *file_priv = file->driver_priv;
> > +     struct i915_gem_proto_context *pc;
> >       struct i915_gem_context *ctx;
> >       int err;
> >       u32 id;
> > @@ -892,7 +966,14 @@ int i915_gem_context_open(struct drm_i915_private *i915,
> >       /* 0 reserved for invalid/unassigned ppgtt */
> >       xa_init_flags(&file_priv->vm_xa, XA_FLAGS_ALLOC1);
> >
> > -     ctx = i915_gem_create_context(i915, 0);
> > +     pc = proto_context_create(i915, 0);
> > +     if (IS_ERR(pc)) {
> > +             err = PTR_ERR(pc);
> > +             goto err;
> > +     }
> > +
> > +     ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ctx)) {
> >               err = PTR_ERR(ctx);
> >               goto err;
> > @@ -1884,6 +1965,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> >  {
> >       struct drm_i915_private *i915 = to_i915(dev);
> >       struct drm_i915_gem_context_create_ext *args = data;
> > +     struct i915_gem_proto_context *pc;
> >       struct create_ext ext_data;
> >       int ret;
> >       u32 id;
> > @@ -1906,7 +1988,12 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> >               return -EIO;
> >       }
> >
> > -     ext_data.ctx = i915_gem_create_context(i915, args->flags);
> > +     pc = proto_context_create(i915, args->flags);
> > +     if (IS_ERR(pc))
> > +             return PTR_ERR(pc);
> > +
> > +     ext_data.ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ext_data.ctx))
> >               return PTR_ERR(ext_data.ctx);
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index df76767f0c41b..a42c429f94577 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -46,6 +46,27 @@ struct i915_gem_engines_iter {
> >       const struct i915_gem_engines *engines;
> >  };
> >
> > +/**
> > + * struct i915_gem_proto_context - prototype context
> > + *
> > + * The struct i915_gem_proto_context represents the creation parameters for
> > + * an i915_gem_context.  This is used to gather parameters provided either
> > + * through creation flags or via SET_CONTEXT_PARAM so that, when we create
> > + * the final i915_gem_context, those parameters can be immutable.
>
> The patch that puts them on an xa should explain how the locking here
> works, even if it's rather trivial.
>
> > + */
> > +struct i915_gem_proto_context {
> > +     /** @vm: See i915_gem_context::vm */
> > +     struct i915_address_space *vm;
> > +
> > +     /** @user_flags: See i915_gem_context::user_flags */
> > +     unsigned long user_flags;
> > +
> > +     /** @sched: See i915_gem_context::sched */
> > +     struct i915_sched_attr sched;
> > +
>
> To avoid the kerneldoc warning point at your emulated syncobj here.

Done.

> Also this file isn't included in the i915 context docs (why would it, the
> docs have been left dead for years after all :-/). Please fix that in a
> prep patch.

Will do.

--Jason

> > +     bool single_timeline;
> > +};
> > +
> >  /**
> >   * struct i915_gem_context - client state
> >   *
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > index 51b5a3421b400..e0f512ef7f3c6 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > @@ -80,11 +80,17 @@ void mock_init_contexts(struct drm_i915_private *i915)
> >  struct i915_gem_context *
> >  live_context(struct drm_i915_private *i915, struct file *file)
> >  {
> > +     struct i915_gem_proto_context *pc;
> >       struct i915_gem_context *ctx;
> >       int err;
> >       u32 id;
> >
> > -     ctx = i915_gem_create_context(i915, 0);
> > +     pc = proto_context_create(i915, 0);
> > +     if (IS_ERR(pc))
> > +             return ERR_CAST(pc);
> > +
> > +     ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > @@ -142,8 +148,14 @@ struct i915_gem_context *
> >  kernel_context(struct drm_i915_private *i915)
> >  {
> >       struct i915_gem_context *ctx;
> > +     struct i915_gem_proto_context *pc;
> > +
> > +     pc = proto_context_create(i915, 0);
> > +     if (IS_ERR(pc))
> > +             return ERR_CAST(pc);
> >
> > -     ctx = i915_gem_create_context(i915, 0);
> > +     ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ctx))
> >               return ctx;
>
> With all comments addressed: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> >
> > --
> > 2.31.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jason Ekstrand <jason@jlekstrand.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 13/21] drm/i915/gem: Add an intermediate proto_context struct
Date: Thu, 29 Apr 2021 11:44:42 -0500	[thread overview]
Message-ID: <CAOFGe94qNkG-8bUSMB0PudXQcs7C22mQqZR=NoPtSG6EHh0rpQ@mail.gmail.com> (raw)
In-Reply-To: <YIqufo0AsyRndhav@phenom.ffwll.local>

On Thu, Apr 29, 2021 at 8:02 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> The commit introducing a new data structure really should have a solid
> intro in the commit message about. Please cover
>
> - that ctx really should be immutable, safe for exceptions like priority
>
> - that unfortunately we butchered the uapi with setparam and sharing
>   setparams between create_ext and setparam
>
> - and how exactly proto ctx fixes this (with stuff like locking design
>   used)
>
> Maybe also dupe the kerneldoc into here for completeness.
> On Fri, Apr 23, 2021 at 05:31:23PM -0500, Jason Ekstrand wrote:
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 143 ++++++++++++++----
> >  .../gpu/drm/i915/gem/i915_gem_context_types.h |  21 +++
> >  .../gpu/drm/i915/gem/selftests/mock_context.c |  16 +-
>
> I'm wondering whether in the end we should split out the proto_ctx into
> its own file, with the struct private only to itself. But I guess
> impossible during the transition, and also maybe afterwards?
>
> >  3 files changed, 150 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 e5efd22c89ba2..3e883daab93bf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -191,6 +191,95 @@ 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 (test_bit(UCONTEXT_PERSISTENCE, &pc->user_flags) == persist)
> > +             return 0;
>
> We have compilers to optimize this kind of stuff, pls remove :-)
> Especially with the non-atomic bitops there's no point.

I thought at one point that this did have a purpose.  However, now
that I look at it harder, I'm pretty sure it doesn't.  Will drop.

> > +
> > +     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);
>
> It's a bit entetaining, but the bitops in the kernel are atomic. Which is
> hella confusing here.
>
> I think open coding is the standard for truly normal bitops.

There's __set_bit if you'd rather I use that.

> > +     } 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);
>
> Same here.
>
> > +     }
> > +
> > +     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;
> > +
> > +     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> > +         !HAS_EXECLISTS(i915))
> > +             return ERR_PTR(-EINVAL);
> > +
> > +     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));
> > +                     proto_context_close(pc);
> > +                     return ERR_CAST(ppgtt);
> > +             }
> > +             pc->vm = &ppgtt->vm;
> > +     }
> > +
> > +     pc->user_flags = 0;
> > +     set_bit(UCONTEXT_BANNABLE, &pc->user_flags);
> > +     set_bit(UCONTEXT_RECOVERABLE, &pc->user_flags);
>
> Same about atomic bitops here.

Changed to just initialize to BANNABLE | RECOVERABLE.

> > +     proto_context_set_persistence(i915, pc, true);
> > +     pc->sched.priority = I915_PRIORITY_NORMAL;
> > +
> > +     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE)
> > +             pc->single_timeline = true;
>
> bit a bikeshed, but I'd put the error checking in here too and deal with
> the unwind pain with the usual goto proto_close. That should also make the
> ppgtt unwind path a bit clearer because it sticks out in the standard way.

Sure.  Can do.

> > +
> > +     return pc;
> > +}
> > +
> >  static struct i915_address_space *
> >  context_get_vm_rcu(struct i915_gem_context *ctx)
> >  {
> > @@ -660,7 +749,8 @@ static int __context_set_persistence(struct i915_gem_context *ctx, bool state)
> >  }
> >
> >  static struct i915_gem_context *
> > -__create_context(struct drm_i915_private *i915)
> > +__create_context(struct drm_i915_private *i915,
> > +              const struct i915_gem_proto_context *pc)
> >  {
> >       struct i915_gem_context *ctx;
> >       struct i915_gem_engines *e;
> > @@ -673,7 +763,7 @@ __create_context(struct drm_i915_private *i915)
> >
> >       kref_init(&ctx->ref);
> >       ctx->i915 = i915;
> > -     ctx->sched.priority = I915_PRIORITY_NORMAL;
> > +     ctx->sched = pc->sched;
> >       mutex_init(&ctx->mutex);
> >       INIT_LIST_HEAD(&ctx->link);
> >
> > @@ -696,9 +786,7 @@ __create_context(struct drm_i915_private *i915)
> >        * is no remap info, it will be a NOP. */
> >       ctx->remap_slice = ALL_L3_SLICES(i915);
> >
> > -     i915_gem_context_set_bannable(ctx);
> > -     i915_gem_context_set_recoverable(ctx);
> > -     __context_set_persistence(ctx, true /* cgroup hook? */);
> > +     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;
> > @@ -786,38 +874,23 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
> >  }
> >
> >  static struct i915_gem_context *
> > -i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> > +i915_gem_create_context(struct drm_i915_private *i915,
> > +                     const struct i915_gem_proto_context *pc)
> >  {
> >       struct i915_gem_context *ctx;
> >       int ret;
> >
> > -     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> > -         !HAS_EXECLISTS(i915))
> > -             return ERR_PTR(-EINVAL);
> > -
> > -     ctx = __create_context(i915);
> > +     ctx = __create_context(i915, pc);
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > -     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));
> > -                     context_close(ctx);
> > -                     return ERR_CAST(ppgtt);
> > -             }
> > -
> > +     if (pc->vm) {
> >               mutex_lock(&ctx->mutex);
>
> I guess this dies later, but this mutex_lock here is superflous since
> right now no one else can get at our ctx struct. And nothing in
> __assign_ppgtt checks for us holding the lock.
>
> But fine if it only gets remove in the vm immutable patch.

Yeah, I think it gets dropped in the immutable patch.  I just didn't
want to perturb things more than necessary in this one.

> > -             __assign_ppgtt(ctx, &ppgtt->vm);
> > +             __assign_ppgtt(ctx, pc->vm);
> >               mutex_unlock(&ctx->mutex);
> > -
> > -             i915_vm_put(&ppgtt->vm);
> >       }
> >
> > -     if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> > +     if (pc->single_timeline) {
> >               ret = drm_syncobj_create(&ctx->syncobj,
> >                                        DRM_SYNCOBJ_CREATE_SIGNALED,
> >                                        NULL);
> > @@ -883,6 +956,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
> >                         struct drm_file *file)
> >  {
> >       struct drm_i915_file_private *file_priv = file->driver_priv;
> > +     struct i915_gem_proto_context *pc;
> >       struct i915_gem_context *ctx;
> >       int err;
> >       u32 id;
> > @@ -892,7 +966,14 @@ int i915_gem_context_open(struct drm_i915_private *i915,
> >       /* 0 reserved for invalid/unassigned ppgtt */
> >       xa_init_flags(&file_priv->vm_xa, XA_FLAGS_ALLOC1);
> >
> > -     ctx = i915_gem_create_context(i915, 0);
> > +     pc = proto_context_create(i915, 0);
> > +     if (IS_ERR(pc)) {
> > +             err = PTR_ERR(pc);
> > +             goto err;
> > +     }
> > +
> > +     ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ctx)) {
> >               err = PTR_ERR(ctx);
> >               goto err;
> > @@ -1884,6 +1965,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> >  {
> >       struct drm_i915_private *i915 = to_i915(dev);
> >       struct drm_i915_gem_context_create_ext *args = data;
> > +     struct i915_gem_proto_context *pc;
> >       struct create_ext ext_data;
> >       int ret;
> >       u32 id;
> > @@ -1906,7 +1988,12 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> >               return -EIO;
> >       }
> >
> > -     ext_data.ctx = i915_gem_create_context(i915, args->flags);
> > +     pc = proto_context_create(i915, args->flags);
> > +     if (IS_ERR(pc))
> > +             return PTR_ERR(pc);
> > +
> > +     ext_data.ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ext_data.ctx))
> >               return PTR_ERR(ext_data.ctx);
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index df76767f0c41b..a42c429f94577 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -46,6 +46,27 @@ struct i915_gem_engines_iter {
> >       const struct i915_gem_engines *engines;
> >  };
> >
> > +/**
> > + * struct i915_gem_proto_context - prototype context
> > + *
> > + * The struct i915_gem_proto_context represents the creation parameters for
> > + * an i915_gem_context.  This is used to gather parameters provided either
> > + * through creation flags or via SET_CONTEXT_PARAM so that, when we create
> > + * the final i915_gem_context, those parameters can be immutable.
>
> The patch that puts them on an xa should explain how the locking here
> works, even if it's rather trivial.
>
> > + */
> > +struct i915_gem_proto_context {
> > +     /** @vm: See i915_gem_context::vm */
> > +     struct i915_address_space *vm;
> > +
> > +     /** @user_flags: See i915_gem_context::user_flags */
> > +     unsigned long user_flags;
> > +
> > +     /** @sched: See i915_gem_context::sched */
> > +     struct i915_sched_attr sched;
> > +
>
> To avoid the kerneldoc warning point at your emulated syncobj here.

Done.

> Also this file isn't included in the i915 context docs (why would it, the
> docs have been left dead for years after all :-/). Please fix that in a
> prep patch.

Will do.

--Jason

> > +     bool single_timeline;
> > +};
> > +
> >  /**
> >   * struct i915_gem_context - client state
> >   *
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > index 51b5a3421b400..e0f512ef7f3c6 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> > @@ -80,11 +80,17 @@ void mock_init_contexts(struct drm_i915_private *i915)
> >  struct i915_gem_context *
> >  live_context(struct drm_i915_private *i915, struct file *file)
> >  {
> > +     struct i915_gem_proto_context *pc;
> >       struct i915_gem_context *ctx;
> >       int err;
> >       u32 id;
> >
> > -     ctx = i915_gem_create_context(i915, 0);
> > +     pc = proto_context_create(i915, 0);
> > +     if (IS_ERR(pc))
> > +             return ERR_CAST(pc);
> > +
> > +     ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > @@ -142,8 +148,14 @@ struct i915_gem_context *
> >  kernel_context(struct drm_i915_private *i915)
> >  {
> >       struct i915_gem_context *ctx;
> > +     struct i915_gem_proto_context *pc;
> > +
> > +     pc = proto_context_create(i915, 0);
> > +     if (IS_ERR(pc))
> > +             return ERR_CAST(pc);
> >
> > -     ctx = i915_gem_create_context(i915, 0);
> > +     ctx = i915_gem_create_context(i915, pc);
> > +     proto_context_close(pc);
> >       if (IS_ERR(ctx))
> >               return ctx;
>
> With all comments addressed: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> >
> > --
> > 2.31.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-04-29 16:44 UTC|newest]

Thread overview: 226+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 22:31 [PATCH 00/21] drm/i915/gem: ioctl clean-ups Jason Ekstrand
2021-04-23 22:31 ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 01/21] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:32   ` Daniel Vetter
2021-04-27  9:32     ` [Intel-gfx] " Daniel Vetter
2021-04-28  3:33     ` Jason Ekstrand
2021-04-28  3:33       ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 02/21] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:38   ` Daniel Vetter
2021-04-27  9:38     ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 03/21] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:42   ` Daniel Vetter
2021-04-27  9:42     ` [Intel-gfx] " Daniel Vetter
2021-04-28 15:55   ` Tvrtko Ursulin
2021-04-28 15:55     ` Tvrtko Ursulin
2021-04-28 17:24     ` Jason Ekstrand
2021-04-28 17:24       ` Jason Ekstrand
2021-04-29  8:04       ` Tvrtko Ursulin
2021-04-29  8:04         ` Tvrtko Ursulin
2021-04-29 14:54         ` Jason Ekstrand
2021-04-29 14:54           ` Jason Ekstrand
2021-04-29 17:12           ` Daniel Vetter
2021-04-29 17:12             ` Daniel Vetter
2021-04-29 17:13             ` Daniel Vetter
2021-04-29 17:13               ` Daniel Vetter
2021-04-29 18:41               ` Jason Ekstrand
2021-04-29 18:41                 ` Jason Ekstrand
2021-04-30 11:18           ` Tvrtko Ursulin
2021-04-30 11:18             ` Tvrtko Ursulin
2021-04-30 15:35             ` Jason Ekstrand
2021-04-30 15:35               ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 04/21] drm/i915/gem: Return void from context_apply_all Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:42   ` Daniel Vetter
2021-04-27  9:42     ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 05/21] drm/i915: Drop the CONTEXT_CLONE API Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:49   ` Daniel Vetter
2021-04-27  9:49     ` Daniel Vetter
2021-04-28 17:38     ` Jason Ekstrand
2021-04-28 17:38       ` Jason Ekstrand
2021-04-28 15:59   ` Tvrtko Ursulin
2021-04-28 15:59     ` Tvrtko Ursulin
2021-04-23 22:31 ` [PATCH 06/21] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v3) Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:55   ` Daniel Vetter
2021-04-27  9:55     ` Daniel Vetter
2021-04-28 15:49   ` Tvrtko Ursulin
2021-04-28 15:49     ` Tvrtko Ursulin
2021-04-28 17:26     ` Jason Ekstrand
2021-04-28 17:26       ` Jason Ekstrand
2021-04-29  8:06       ` Tvrtko Ursulin
2021-04-29  8:06         ` Tvrtko Ursulin
2021-04-29 12:08         ` Daniel Vetter
2021-04-29 12:08           ` Daniel Vetter
2021-04-29 14:47           ` Jason Ekstrand
2021-04-29 14:47             ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 07/21] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-27  9:58   ` Daniel Vetter
2021-04-27  9:58     ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-26 23:43   ` [PATCH 08/20] drm/i915/gem: Disallow bonding of virtual engines (v2) Jason Ekstrand
2021-04-26 23:43     ` [Intel-gfx] " Jason Ekstrand
2021-04-27 13:58     ` Daniel Vetter
2021-04-27 13:58       ` Daniel Vetter
2021-04-27 13:51   ` [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines Jason Ekstrand
2021-04-27 13:51     ` [Intel-gfx] " Jason Ekstrand
2021-04-28 10:13     ` Daniel Vetter
2021-04-28 10:13       ` [Intel-gfx] " Daniel Vetter
2021-04-28 17:18       ` Jason Ekstrand
2021-04-28 17:18         ` [Intel-gfx] " Jason Ekstrand
2021-04-28 17:18         ` Matthew Brost
2021-04-28 17:18           ` Matthew Brost
2021-04-28 17:46           ` Jason Ekstrand
2021-04-28 17:46             ` Jason Ekstrand
2021-04-28 17:55             ` Matthew Brost
2021-04-28 17:55               ` Matthew Brost
2021-04-28 18:17               ` Jason Ekstrand
2021-04-28 18:17                 ` Jason Ekstrand
2021-04-29 12:14                 ` Daniel Vetter
2021-04-29 12:14                   ` Daniel Vetter
2021-04-30  4:03                   ` Matthew Brost
2021-04-30  4:03                     ` Matthew Brost
2021-04-30 10:11                     ` Daniel Vetter
2021-04-30 10:11                       ` Daniel Vetter
2021-05-01 17:17                       ` Matthew Brost
2021-05-01 17:17                         ` Matthew Brost
2021-05-04  7:36                         ` Daniel Vetter
2021-05-04  7:36                           ` Daniel Vetter
2021-04-28 18:58         ` Jason Ekstrand
2021-04-28 18:58           ` [Intel-gfx] " Jason Ekstrand
2021-04-29 12:16           ` Daniel Vetter
2021-04-29 12:16             ` [Intel-gfx] " Daniel Vetter
2021-04-29 16:02             ` Jason Ekstrand
2021-04-29 16:02               ` [Intel-gfx] " Jason Ekstrand
2021-04-29 17:14               ` Daniel Vetter
2021-04-29 17:14                 ` [Intel-gfx] " Daniel Vetter
2021-04-28 15:51   ` Tvrtko Ursulin
2021-04-28 15:51     ` Tvrtko Ursulin
2021-04-29 12:24     ` Daniel Vetter
2021-04-29 12:24       ` Daniel Vetter
2021-04-29 12:54       ` Tvrtko Ursulin
2021-04-29 12:54         ` Tvrtko Ursulin
2021-04-29 15:41         ` Jason Ekstrand
2021-04-29 15:41           ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 09/21] drm/i915/gem: Disallow creating contexts with too many engines Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-28 10:16   ` Daniel Vetter
2021-04-28 10:16     ` Daniel Vetter
2021-04-28 10:42     ` Tvrtko Ursulin
2021-04-28 10:42       ` Tvrtko Ursulin
2021-04-28 14:02       ` Daniel Vetter
2021-04-28 14:02         ` Daniel Vetter
2021-04-28 14:26         ` Tvrtko Ursulin
2021-04-28 14:26           ` Tvrtko Ursulin
2021-04-28 17:09           ` Jason Ekstrand
2021-04-28 17:09             ` Jason Ekstrand
2021-04-29  8:01             ` Tvrtko Ursulin
2021-04-29  8:01               ` Tvrtko Ursulin
2021-04-29 19:16               ` Jason Ekstrand
2021-04-29 19:16                 ` Jason Ekstrand
2021-04-30 11:40                 ` Tvrtko Ursulin
2021-04-30 11:40                   ` Tvrtko Ursulin
2021-04-30 15:54                   ` Jason Ekstrand
2021-04-30 15:54                     ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 10/21] drm/i915/request: Remove the hook from await_execution Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-26 23:44   ` Jason Ekstrand
2021-04-26 23:44     ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 11/21] drm/i915: Stop manually RCU banging in reset_stats_ioctl Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-28 10:27   ` Daniel Vetter
2021-04-28 10:27     ` [Intel-gfx] " Daniel Vetter
2021-04-28 18:22     ` Jason Ekstrand
2021-04-28 18:22       ` [Intel-gfx] " Jason Ekstrand
2021-04-29 12:22       ` Daniel Vetter
2021-04-29 12:22         ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 12/21] drm/i915/gem: Add a separate validate_priority helper Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-28 14:37   ` Daniel Vetter
2021-04-28 14:37     ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 13/21] drm/i915/gem: Add an intermediate proto_context struct Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-29 13:02   ` Daniel Vetter
2021-04-29 13:02     ` Daniel Vetter
2021-04-29 16:44     ` Jason Ekstrand [this message]
2021-04-29 16:44       ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 14/21] drm/i915/gem: Return an error ptr from context_lookup Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-29 13:27   ` Daniel Vetter
2021-04-29 13:27     ` Daniel Vetter
2021-04-29 15:29     ` Jason Ekstrand
2021-04-29 15:29       ` Jason Ekstrand
2021-04-29 17:16       ` Daniel Vetter
2021-04-29 17:16         ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 15/21] drm/i915/gt: Drop i915_address_space::file Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-29 12:37   ` Daniel Vetter
2021-04-29 12:37     ` [Intel-gfx] " Daniel Vetter
2021-04-29 15:26     ` Jason Ekstrand
2021-04-29 15:26       ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 16/21] drm/i915/gem: Delay context creation Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-24  3:21   ` kernel test robot
2021-04-24  3:21     ` kernel test robot
2021-04-24  3:21     ` kernel test robot
2021-04-24  3:24   ` kernel test robot
2021-04-24  3:24     ` kernel test robot
2021-04-24  3:24     ` kernel test robot
2021-04-29 15:51   ` Daniel Vetter
2021-04-29 15:51     ` Daniel Vetter
2021-04-29 18:16     ` Jason Ekstrand
2021-04-29 18:16       ` Jason Ekstrand
2021-04-29 18:56       ` Daniel Vetter
2021-04-29 18:56         ` Daniel Vetter
2021-04-29 19:01         ` Jason Ekstrand
2021-04-29 19:01           ` Jason Ekstrand
2021-04-29 19:07           ` Daniel Vetter
2021-04-29 19:07             ` Daniel Vetter
2021-04-29 21:35             ` Jason Ekstrand
2021-04-29 21:35               ` Jason Ekstrand
2021-04-30  6:53               ` Daniel Vetter
2021-04-30  6:53                 ` Daniel Vetter
2021-04-30 11:58                 ` Tvrtko Ursulin
2021-04-30 11:58                   ` Tvrtko Ursulin
2021-04-30 12:30                   ` Daniel Vetter
2021-04-30 12:30                     ` Daniel Vetter
2021-04-30 12:44                     ` Tvrtko Ursulin
2021-04-30 12:44                       ` Tvrtko Ursulin
2021-04-30 13:07                       ` Daniel Vetter
2021-04-30 13:07                         ` Daniel Vetter
2021-04-30 13:15                         ` Tvrtko Ursulin
2021-04-30 13:15                           ` Tvrtko Ursulin
2021-04-30 16:27                 ` Jason Ekstrand
2021-04-30 16:27                   ` Jason Ekstrand
2021-04-30 16:33                   ` Daniel Vetter
2021-04-30 16:33                     ` Daniel Vetter
2021-04-30 16:57                     ` Jason Ekstrand
2021-04-30 16:57                       ` Jason Ekstrand
2021-04-30 17:08                       ` Daniel Vetter
2021-04-30 17:08                         ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 17/21] drm/i915/gem: Don't allow changing the VM on running contexts Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 18/21] drm/i915/gem: Don't allow changing the engine set " Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-29 17:21   ` Daniel Vetter
2021-04-29 17:21     ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 19/21] drm/i915/selftests: Take a VM in kernel_context() Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 20/21] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-29 17:19   ` Daniel Vetter
2021-04-29 17:19     ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 21/21] drm/i915/gem: Roll all of context creation together Jason Ekstrand
2021-04-23 22:31   ` [Intel-gfx] " Jason Ekstrand
2021-04-29 17:25   ` Daniel Vetter
2021-04-29 17:25     ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:49 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: ioctl clean-ups Patchwork
2021-04-23 22:51 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-04-23 23:16 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-04-24  2:14 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOFGe94qNkG-8bUSMB0PudXQcs7C22mQqZR=NoPtSG6EHh0rpQ@mail.gmail.com' \
    --to=jason@jlekstrand.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.