From: Matthew Auld <matthew.auld@intel.com> To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: matthew.brost@intel.com, paulo.r.zanoni@intel.com, tvrtko.ursulin@intel.com, jani.nikula@intel.com, lionel.g.landwerlin@intel.com, thomas.hellstrom@intel.com, jason@jlekstrand.net, andi.shyti@linux.intel.com, daniel.vetter@intel.com, christian.koenig@amd.com Subject: Re: [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings Date: Thu, 1 Dec 2022 10:49:15 +0000 [thread overview] Message-ID: <dbbd19e4-4354-bd11-a68d-435f59150fc8@intel.com> (raw) In-Reply-To: <20221129072635.847-23-niranjana.vishwanathapura@intel.com> On 29/11/2022 07:26, Niranjana Vishwanathapura wrote: > Support dump capture of persistent mappings upon user request. > > Signed-off-by: Brian Welty <brian.welty@intel.com> > Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> > --- > .../drm/i915/gem/i915_gem_vm_bind_object.c | 11 +++++++++++ > drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +++ > drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++++ > drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++++++++++++++++++ > drivers/gpu/drm/i915/i915_vma.c | 1 + > drivers/gpu/drm/i915/i915_vma_types.h | 2 ++ > include/uapi/drm/i915_drm.h | 3 ++- > 7 files changed, 43 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > index 78e7c0642c5f..50969613daf6 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > @@ -88,6 +88,11 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj) > { > lockdep_assert_held(&vma->vm->vm_bind_lock); > > + spin_lock(&vma->vm->vm_capture_lock); > + if (!list_empty(&vma->vm_capture_link)) > + list_del_init(&vma->vm_capture_link); > + spin_unlock(&vma->vm->vm_capture_lock); > + > spin_lock(&vma->vm->vm_rebind_lock); > if (!list_empty(&vma->vm_rebind_link)) > list_del_init(&vma->vm_rebind_link); > @@ -357,6 +362,12 @@ static int i915_gem_vm_bind_obj(struct i915_address_space *vm, > continue; > } > > + if (va->flags & I915_GEM_VM_BIND_CAPTURE) { > + spin_lock(&vm->vm_capture_lock); > + list_add_tail(&vma->vm_capture_link, &vm->vm_capture_list); > + spin_unlock(&vm->vm_capture_lock); > + } > + > list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list); > i915_vm_bind_it_insert(vma, &vm->va); > if (!obj->priv_root) > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c > index ebf6830574a0..bdabe13fc30e 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c > @@ -297,6 +297,9 @@ void i915_address_space_init(struct i915_address_space *vm, int subclass) > spin_lock_init(&vm->vm_rebind_lock); > spin_lock_init(&vm->userptr_invalidated_lock); > INIT_LIST_HEAD(&vm->userptr_invalidated_list); > + > + INIT_LIST_HEAD(&vm->vm_capture_list); > + spin_lock_init(&vm->vm_capture_lock); > } > > void *__px_vaddr(struct drm_i915_gem_object *p) > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h > index 87e5b6568a00..8e4ddd073348 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gtt.h > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h > @@ -281,6 +281,11 @@ struct i915_address_space { > /** @root_obj: root object for dma-resv sharing by private objects */ > struct drm_i915_gem_object *root_obj; > > + /* @vm_capture_list: list of vm captures */ > + struct list_head vm_capture_list; > + /* @vm_capture_lock: protects vm_capture_list */ > + spinlock_t vm_capture_lock; > + > /* Global GTT */ > bool is_ggtt:1; > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c > index 9d5d5a397b64..3b2b12a739f7 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next, > return next; > } > > +static struct intel_engine_capture_vma * > +capture_user_vm(struct intel_engine_capture_vma *capture, > + struct i915_address_space *vm, gfp_t gfp) > +{ > + struct i915_vma *vma; > + > + spin_lock(&vm->vm_capture_lock); Does it make sense to move this into the eb3 submission stage, like we do for eb2? IIRC the gfp flags here are quite limiting due to potentially being in a fence critical section. If we can use rq->capture_list for eb3, we shouldn't need to change much here? Also there is the existing CONFIG_DRM_I915_CAPTURE_ERROR. Should we take that into account? > + /* vma->resource must be valid here as persistent vmas are bound */ > + list_for_each_entry(vma, &vm->vm_capture_list, vm_capture_link) > + capture = capture_vma_snapshot(capture, vma->resource, > + gfp, "user"); > + spin_unlock(&vm->vm_capture_lock); > + > + return capture; > +} > + > static struct intel_engine_capture_vma * > capture_user(struct intel_engine_capture_vma *capture, > const struct i915_request *rq, > @@ -1471,6 +1487,9 @@ capture_user(struct intel_engine_capture_vma *capture, > capture = capture_vma_snapshot(capture, c->vma_res, gfp, > "user"); > > + capture = capture_user_vm(capture, rq->context->vm, > + GFP_NOWAIT | __GFP_NOWARN); And this should maybe use the passed in gfp? > + > return capture; > } > > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c > index 68a9ac77b4f2..0244864e94f7 100644 > --- a/drivers/gpu/drm/i915/i915_vma.c > +++ b/drivers/gpu/drm/i915/i915_vma.c > @@ -248,6 +248,7 @@ vma_create(struct drm_i915_gem_object *obj, > INIT_LIST_HEAD(&vma->non_priv_vm_bind_link); > INIT_LIST_HEAD(&vma->vm_rebind_link); > INIT_LIST_HEAD(&vma->userptr_invalidated_link); > + INIT_LIST_HEAD(&vma->vm_capture_link); > return vma; > > err_unlock: > diff --git a/drivers/gpu/drm/i915/i915_vma_types.h b/drivers/gpu/drm/i915/i915_vma_types.h > index 90471dc0b235..10ae9f739d57 100644 > --- a/drivers/gpu/drm/i915/i915_vma_types.h > +++ b/drivers/gpu/drm/i915/i915_vma_types.h > @@ -309,6 +309,8 @@ struct i915_vma { > struct list_head vm_rebind_link; /* Link in vm_rebind_list */ > /** @userptr_invalidated_link: link to the vm->userptr_invalidated_list */ > struct list_head userptr_invalidated_link; > + /* @vm_capture_link: link to the captureable VMA list */ > + struct list_head vm_capture_link; > > /** Timeline fence for vm_bind completion notification */ > struct { > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index b9167f950327..0744651ad5b0 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -3930,7 +3930,8 @@ struct drm_i915_gem_vm_bind { > * Note that @fence carries its own flags. > */ > __u64 flags; > -#define __I915_GEM_VM_BIND_UNKNOWN_FLAGS (~0ull) > +#define I915_GEM_VM_BIND_CAPTURE (1 << 0) 1ull << 0 Worried about what the value of UNKNOWN_FLAGS might be otherwise? Also needs some kernel-doc. > +#define __I915_GEM_VM_BIND_UNKNOWN_FLAGS (-(I915_GEM_VM_BIND_CAPTURE << 1)) > > /** @rsvd: Reserved, MBZ */ > __u64 rsvd[2];
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com> To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: paulo.r.zanoni@intel.com, jani.nikula@intel.com, thomas.hellstrom@intel.com, daniel.vetter@intel.com, christian.koenig@amd.com Subject: Re: [Intel-gfx] [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings Date: Thu, 1 Dec 2022 10:49:15 +0000 [thread overview] Message-ID: <dbbd19e4-4354-bd11-a68d-435f59150fc8@intel.com> (raw) In-Reply-To: <20221129072635.847-23-niranjana.vishwanathapura@intel.com> On 29/11/2022 07:26, Niranjana Vishwanathapura wrote: > Support dump capture of persistent mappings upon user request. > > Signed-off-by: Brian Welty <brian.welty@intel.com> > Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> > --- > .../drm/i915/gem/i915_gem_vm_bind_object.c | 11 +++++++++++ > drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +++ > drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++++ > drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++++++++++++++++++ > drivers/gpu/drm/i915/i915_vma.c | 1 + > drivers/gpu/drm/i915/i915_vma_types.h | 2 ++ > include/uapi/drm/i915_drm.h | 3 ++- > 7 files changed, 43 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > index 78e7c0642c5f..50969613daf6 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c > @@ -88,6 +88,11 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj) > { > lockdep_assert_held(&vma->vm->vm_bind_lock); > > + spin_lock(&vma->vm->vm_capture_lock); > + if (!list_empty(&vma->vm_capture_link)) > + list_del_init(&vma->vm_capture_link); > + spin_unlock(&vma->vm->vm_capture_lock); > + > spin_lock(&vma->vm->vm_rebind_lock); > if (!list_empty(&vma->vm_rebind_link)) > list_del_init(&vma->vm_rebind_link); > @@ -357,6 +362,12 @@ static int i915_gem_vm_bind_obj(struct i915_address_space *vm, > continue; > } > > + if (va->flags & I915_GEM_VM_BIND_CAPTURE) { > + spin_lock(&vm->vm_capture_lock); > + list_add_tail(&vma->vm_capture_link, &vm->vm_capture_list); > + spin_unlock(&vm->vm_capture_lock); > + } > + > list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list); > i915_vm_bind_it_insert(vma, &vm->va); > if (!obj->priv_root) > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c > index ebf6830574a0..bdabe13fc30e 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c > @@ -297,6 +297,9 @@ void i915_address_space_init(struct i915_address_space *vm, int subclass) > spin_lock_init(&vm->vm_rebind_lock); > spin_lock_init(&vm->userptr_invalidated_lock); > INIT_LIST_HEAD(&vm->userptr_invalidated_list); > + > + INIT_LIST_HEAD(&vm->vm_capture_list); > + spin_lock_init(&vm->vm_capture_lock); > } > > void *__px_vaddr(struct drm_i915_gem_object *p) > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h > index 87e5b6568a00..8e4ddd073348 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gtt.h > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h > @@ -281,6 +281,11 @@ struct i915_address_space { > /** @root_obj: root object for dma-resv sharing by private objects */ > struct drm_i915_gem_object *root_obj; > > + /* @vm_capture_list: list of vm captures */ > + struct list_head vm_capture_list; > + /* @vm_capture_lock: protects vm_capture_list */ > + spinlock_t vm_capture_lock; > + > /* Global GTT */ > bool is_ggtt:1; > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c > index 9d5d5a397b64..3b2b12a739f7 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next, > return next; > } > > +static struct intel_engine_capture_vma * > +capture_user_vm(struct intel_engine_capture_vma *capture, > + struct i915_address_space *vm, gfp_t gfp) > +{ > + struct i915_vma *vma; > + > + spin_lock(&vm->vm_capture_lock); Does it make sense to move this into the eb3 submission stage, like we do for eb2? IIRC the gfp flags here are quite limiting due to potentially being in a fence critical section. If we can use rq->capture_list for eb3, we shouldn't need to change much here? Also there is the existing CONFIG_DRM_I915_CAPTURE_ERROR. Should we take that into account? > + /* vma->resource must be valid here as persistent vmas are bound */ > + list_for_each_entry(vma, &vm->vm_capture_list, vm_capture_link) > + capture = capture_vma_snapshot(capture, vma->resource, > + gfp, "user"); > + spin_unlock(&vm->vm_capture_lock); > + > + return capture; > +} > + > static struct intel_engine_capture_vma * > capture_user(struct intel_engine_capture_vma *capture, > const struct i915_request *rq, > @@ -1471,6 +1487,9 @@ capture_user(struct intel_engine_capture_vma *capture, > capture = capture_vma_snapshot(capture, c->vma_res, gfp, > "user"); > > + capture = capture_user_vm(capture, rq->context->vm, > + GFP_NOWAIT | __GFP_NOWARN); And this should maybe use the passed in gfp? > + > return capture; > } > > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c > index 68a9ac77b4f2..0244864e94f7 100644 > --- a/drivers/gpu/drm/i915/i915_vma.c > +++ b/drivers/gpu/drm/i915/i915_vma.c > @@ -248,6 +248,7 @@ vma_create(struct drm_i915_gem_object *obj, > INIT_LIST_HEAD(&vma->non_priv_vm_bind_link); > INIT_LIST_HEAD(&vma->vm_rebind_link); > INIT_LIST_HEAD(&vma->userptr_invalidated_link); > + INIT_LIST_HEAD(&vma->vm_capture_link); > return vma; > > err_unlock: > diff --git a/drivers/gpu/drm/i915/i915_vma_types.h b/drivers/gpu/drm/i915/i915_vma_types.h > index 90471dc0b235..10ae9f739d57 100644 > --- a/drivers/gpu/drm/i915/i915_vma_types.h > +++ b/drivers/gpu/drm/i915/i915_vma_types.h > @@ -309,6 +309,8 @@ struct i915_vma { > struct list_head vm_rebind_link; /* Link in vm_rebind_list */ > /** @userptr_invalidated_link: link to the vm->userptr_invalidated_list */ > struct list_head userptr_invalidated_link; > + /* @vm_capture_link: link to the captureable VMA list */ > + struct list_head vm_capture_link; > > /** Timeline fence for vm_bind completion notification */ > struct { > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index b9167f950327..0744651ad5b0 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -3930,7 +3930,8 @@ struct drm_i915_gem_vm_bind { > * Note that @fence carries its own flags. > */ > __u64 flags; > -#define __I915_GEM_VM_BIND_UNKNOWN_FLAGS (~0ull) > +#define I915_GEM_VM_BIND_CAPTURE (1 << 0) 1ull << 0 Worried about what the value of UNKNOWN_FLAGS might be otherwise? Also needs some kernel-doc. > +#define __I915_GEM_VM_BIND_UNKNOWN_FLAGS (-(I915_GEM_VM_BIND_CAPTURE << 1)) > > /** @rsvd: Reserved, MBZ */ > __u64 rsvd[2];
next prev parent reply other threads:[~2022-12-01 10:49 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-29 7:26 [PATCH v8 00/22] drm/i915/vm_bind: Add VM_BIND functionality Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 01/22] drm/i915/vm_bind: Expose vm lookup function Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 02/22] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 03/22] drm/i915/vm_bind: Expose i915_gem_object_max_page_size() Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 04/22] drm/i915/vm_bind: Add support to create persistent vma Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 05/22] drm/i915/vm_bind: Implement bind and unbind of object Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 06/22] drm/i915/vm_bind: Support for VM private BOs Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 07/22] drm/i915/vm_bind: Add support to handle object evictions Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 08/22] drm/i915/vm_bind: Support persistent vma activeness tracking Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 09/22] drm/i915/vm_bind: Add out fence support Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 10/22] drm/i915/vm_bind: Abstract out common execbuf functions Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 11/22] drm/i915/vm_bind: Use common execbuf functions in execbuf path Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 12/22] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 13/22] drm/i915/vm_bind: Update i915_vma_verify_bind_complete() Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 14/22] drm/i915/vm_bind: Expose i915_request_await_bind() Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 15/22] drm/i915/vm_bind: Handle persistent vmas in execbuf3 Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [PATCH v8 16/22] drm/i915/vm_bind: userptr dma-resv changes Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 17/22] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 18/22] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 19/22] drm/i915/vm_bind: Render VM_BIND documentation Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 20/22] drm/i915/vm_bind: Async vm_unbind support Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 21/22] drm/i915/vm_bind: Properly build persistent map sg table Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-12-12 18:17 ` Matthew Auld 2022-12-12 18:17 ` [Intel-gfx] " Matthew Auld 2022-12-14 4:58 ` Niranjana Vishwanathapura 2022-12-14 4:58 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-11-29 7:26 ` [Intel-gfx] [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings Niranjana Vishwanathapura 2022-11-29 7:26 ` Niranjana Vishwanathapura 2022-12-01 10:49 ` Matthew Auld [this message] 2022-12-01 10:49 ` [Intel-gfx] " Matthew Auld 2022-12-01 15:27 ` Niranjana Vishwanathapura 2022-12-01 15:27 ` [Intel-gfx] " Niranjana Vishwanathapura 2022-12-01 18:43 ` Niranjana Vishwanathapura 2022-12-06 17:40 ` Matthew Auld 2022-12-08 13:54 ` Niranjana Vishwanathapura 2022-11-29 8:24 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vm_bind: Add VM_BIND functionality (rev11) Patchwork 2022-11-29 8:24 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2022-11-29 8:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-11-29 11:29 ` [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=dbbd19e4-4354-bd11-a68d-435f59150fc8@intel.com \ --to=matthew.auld@intel.com \ --cc=andi.shyti@linux.intel.com \ --cc=christian.koenig@amd.com \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@intel.com \ --cc=jason@jlekstrand.net \ --cc=lionel.g.landwerlin@intel.com \ --cc=matthew.brost@intel.com \ --cc=niranjana.vishwanathapura@intel.com \ --cc=paulo.r.zanoni@intel.com \ --cc=thomas.hellstrom@intel.com \ --cc=tvrtko.ursulin@intel.com \ /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: linkBe 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.