On Thu, Aug 19, 2021 at 12:53 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/8/21 7:02 pm, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
> >> In a future patch, a read lock on drm_device.master_rwsem is
> >> held in the
In
commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
Author: Daniel Vetter
Date: Tue Aug 3 14:48:33 2021 +0200
drm/i915: delete gpu reloc code
I deleted the gpu relocation code and the selftest include and
enabling, but accidentally forgot about the selftest source code.
Fix this
On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote:
>
> On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
> > Author: Daniel Vetter
> > Date: Tue Aug 3 14:48:33 2021 +0200
> &g
_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1719,6 +1719,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>
> #define HAS_VRR(i915) (GRAPHICS_VER(i915) >= 12)
>
> +#define HAS_FRONTBUFFER_RENDERING(i915)(GRAPHICS_VER(i915) < 9)
> +
> /* Only valid when HAS_DISPLAY() is true */
> #define INTEL_DISPLAY_ENABLED(dev_priv) \
> (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),
> !(dev_priv)->params.disable_display)
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ternals
> directly here?
Imo we should just emebed ttm_resource_mager into our own and not try to
abstract this all away that much. At least in upstream there is just not
going to be another memory region implementation, and for backporting I'm
not sure these abstractions really help that much - we're touching all the
same code still in the end.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
sts.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_s
master_release in
> drm_close_helper, and remove drm_master_release from drm_file_free to
> avoid the null ptr dereference.
>
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Daniel Vetter
I guess we should also have a cc: stable on this one? I think this bug
existed since pr
; - drm_master.magic_map
>
> There is a clear separation between functions that read or change
> these attributes. Hence, convert master_mutex into a rwsem to enable
> concurrent readers.
>
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Daniel Vetter
&
tl for this so it's extremely clear it's
the same condition in both?
Either way: Reviewed-by: Daniel Vetter
> + mutex_lock(&drm_global_mutex);
> +
> retcode = drm_ioctl_permit(flags, file_priv);
> if (unlikely(retcode))
> - return
On Thu, Aug 26, 2021 at 11:51:44AM +0200, Thomas Hellström wrote:
> On Thu, 2021-08-26 at 11:16 +0200, Daniel Vetter wrote:
> > On Thu, Aug 19, 2021 at 09:32:20AM +0200, Thomas Hellström wrote:
> > > On Wed, 2021-08-18 at 15:58 +0100, Matthew Auld wrote:
> > > > Th
On Thu, Aug 26, 2021 at 12:03:29PM +0200, Daniel Vetter wrote:
> On Thu, Aug 26, 2021 at 11:51:44AM +0200, Thomas Hellström wrote:
> > On Thu, 2021-08-26 at 11:16 +0200, Daniel Vetter wrote:
> > > On Thu, Aug 19, 2021 at 09:32:20AM +0200, Thomas Hellström wrote:
> > > &g
100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -2385,9 +2385,13 @@ static inline void guc_init_lrc_mapping(struct
> intel_guc *guc)
>* and even it did this code would be run again.
>*/
>
> - for_each_engine(engine, gt, id)
> - if (engine->kernel_context)
> - guc_kernel_context_pin(guc, engine->kernel_context);
> + for_each_engine(engine, gt, id) {
> + struct intel_context *ce;
> +
> + list_for_each_entry(ce, &engine->pinned_contexts_list,
> + pinned_contexts_link)
> + guc_kernel_context_pin(guc, ce);
> + }
> }
>
> static void guc_release(struct intel_engine_cs *engine)
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Aug 26, 2021 at 07:53:58PM +0800, Desmond Cheong Zhi Xi wrote:
> On 26/8/21 5:53 pm, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 10:01:16AM +0800, Desmond Cheong Zhi Xi wrote:
> > > drm_master_release can be called on a drm_file without a master, which
> >
that holds a write lock, like drm_mode_create_lease_ioctl
> which eventually calls drm_master_open), we remove the DRM_MASTER flag
> and push the master_rwsem lock and permissions check into the ioctl.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
>
,9 @@ struct drm_object_properties {
> return "(unknown)"; \
> }
>
> +struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev,
> + struct drm_file *file_priv,
>
tex);
> - drm_master_put(&lessor);
>
> unlock:
> up_write(&dev->master_rwsem);
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index d12bb2ba7814..e2d49fe3e32d 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -227,16 +227,12 @@ struct drm_file {
>* @master:
>*
>* Master this node is currently associated with. Protected by struct
> - * &drm_device.master_rwsem, and serialized by @master_lookup_lock.
> + * &drm_device.master_rwsem.
>*
>* Only relevant if drm_is_primary_client() returns true. Note that
>* this only matches &drm_device.master if the master is the currently
>* active one.
>*
> - * To update @master, both &drm_device.master_rwsem and
> - * @master_lookup_lock need to be held, therefore holding either of
> - * them is safe and enough for the read side.
> - *
>* When dereferencing this pointer, either hold struct
>* &drm_device.master_rwsem for the duration of the pointer's use, or
>* use drm_file_get_master() if struct &drm_device.master_rwsem is not
> @@ -248,9 +244,6 @@ struct drm_file {
>*/
> struct drm_master *master;
>
> - /** @master_lock: Serializes @master. */
> - spinlock_t master_lookup_lock;
> -
> /** @pid: Process that opened this file. */
> struct pid *pid;
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e.lock, flags);
> }
> }
> @@ -1979,7 +1982,7 @@ static const struct intel_context_ops guc_context_ops =
> {
> .unpin = guc_context_unpin,
> .post_unpin = guc_context_post_unpin,
>
> - .ban = guc_context_ban,
> + .revoke = guc_context_revoke,
>
> .cancel_request = guc_context_cancel_request,
>
> @@ -2176,7 +2179,7 @@ static const struct intel_context_ops
> virtual_guc_context_ops = {
> .unpin = guc_context_unpin,
> .post_unpin = guc_context_post_unpin,
>
> - .ban = guc_context_ban,
> + .revoke = guc_context_revoke,
>
> .cancel_request = guc_context_cancel_request,
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index ce446716d092..b1a9bec83339 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -583,7 +583,7 @@ bool __i915_request_submit(struct i915_request *request)
> goto active;
> }
>
> - if (unlikely(intel_context_is_banned(request->context)))
> + if (unlikely(!intel_context_is_schedulable(request->context)))
> i915_request_set_error_once(request, -EIO);
>
> if (unlikely(fatal_error(request->fence.error)))
> --
> 2.30.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Aug 26, 2021 at 03:59:30PM +0200, Thomas Hellström wrote:
> On Thu, 2021-08-26 at 14:44 +0200, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 12:45:14PM +0200, Thomas Hellström wrote:
> > > Pinned contexts, like the migrate contexts need reset after resume
> > >
cy on memory allocations and dma fences (i915_requests).
> Requests depend on resets, thus now we have a circular dependency. To
> work around this, allocate the error capture in a nowait context.
>
> v2:
> (Daniel Vetter)
> - Use GFP_NOWAIT instead GFP_ATOMIC
>
>
On Fri, Aug 20, 2021 at 07:59:04PM +0200, Daniel Vetter wrote:
> On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote:
> >
> > On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> > > In
> > >
> > > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40
t; > +static bool
> > +can_use_semaphore_wait(struct i915_request *to, struct i915_request *from)
> > +{
> > + return to->engine->gt == from->engine->gt;
> > +}
> > +
> > static int
> > emit_semaphore_wait(struct i915_request *to,
> > struct i915_request *from,
> > @@ -1160,6 +1166,9 @@ emit_semaphore_wait(struct i915_request *to,
> > const intel_engine_mask_t mask = READ_ONCE(from->engine)->mask;
> > struct i915_sw_fence *wait = &to->submit;
> > + if (!can_use_semaphore_wait(to, from))
> > + goto await_fence;
> > +
> > if (!intel_context_use_semaphores(to->context))
> > goto await_fence;
> > @@ -1263,7 +1272,8 @@ __i915_request_await_execution(struct i915_request
> > *to,
> > * immediate execution, and so we must wait until it reaches the
> > * active slot.
> > */
> > - if (intel_engine_has_semaphores(to->engine) &&
> > + if (can_use_semaphore_wait(to, from) &&
> > + intel_engine_has_semaphores(to->engine) &&
> > !i915_request_has_initial_breadcrumb(to)) {
> > err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
> > if (err < 0)
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote:
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Chri
On Thu, Aug 26, 2021 at 09:16:25AM -0700, Rob Clark wrote:
> On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > There's only one exclusive slot, and we must not break the ordering.
> >
> > Adding a new exclusive fence drops all previous fences from the
_mem;
> + if (!src_iter->ops->maps_tt)
> + ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
> ttm_bo_move_sync_cleanup(bo, dst_mem);
>
> - if (!src_iter->ops->maps_tt)
> - ttm_kmap_iter_linear_io_fini(&_src_iter.io, b
On Thu, Aug 05, 2021 at 12:47:05PM +0200, Daniel Vetter wrote:
> Specifically document the new/clarified rules around how the shared
> fences do not have any ordering requirements against the exclusive
> fence.
>
> But also document all the things a bit better, given how central
&g
ris Wilson
Date: Fri Aug 30 19:03:25 2019 +0100
drm/i915: Use RCU for unlocked vm_idr lookup
except we have the conversion from idr to xarray in between.
v2: kref_get_unless_zero is no longer required (Maarten)
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten
On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
> Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> > The only reason for this really is the i915_gem_engines->fence
> > callback engines_notify(), which exists purely as a fairly funky
> > reference
On Tue, Aug 31, 2021 at 02:02:39PM +0800, Desmond Cheong Zhi Xi wrote:
> On 26/8/21 9:21 pm, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 10:01:22AM +0800, Desmond Cheong Zhi Xi wrote:
> > > Previously, master_lookup_lock was introduced in
> > > commit 0b
On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
>
> On 30/08/2021 09:26, Daniel Vetter wrote:
> > On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 27/08/2021 15:39, Tvrtko Ursulin wrote:
> > > > From: Tvrt
this is uapi, therefore your patch needs to include
- link to the igts for this
- link to the userspace MR that uses this (I guess it's mesa?)
Cheers, Daniel
> + * Returns OA buffer properties to be used with mmap.
> + *
> + * This ioctl is available in perf revision 8.
> + */
> +#define I915_PERF_IOCTL_GET_OA_BUFFER_INFO _IOWR('i', 0x3, struct
> drm_i915_perf_oa_buffer_info)
> +
> +/*
> + * OA buffer size and offset.
> + *
> + * OA output buffer
> + * type: 0
> + * flags: mbz
> + *
> + * After querying the info, pass (size,offset) to mmap(),
> + *
> + * mmap(0, info.size, PROT_READ, MAP_PRIVATE, perf_fd, info.offset).
> + *
> + * Note that only a private (not shared between processes, or across
> fork())
> + * read-only mmapping is allowed.
> + *
> + * HW is continually writing data to the mapped OA buffer and it conforms
> to
> + * the OA format as specified by user config. The buffer provides reports
> that
> + * have OA counters - A, B and C.
> + */
> +struct drm_i915_perf_oa_buffer_info {
> + __u32 type; /* in */
> + __u32 flags; /* in */
> + __u64 size; /* out */
> + __u64 offset; /* out */
> + __u64 rsvd; /* mbz */
> +};
> +
> /*
> * Common to all i915 perf records
> */
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Aug 31, 2021 at 02:16:56PM +0200, Daniel Vetter wrote:
> On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
> > Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> > > The only reason for this really is the i915_gem_engines->fence
> > > callback
-ci.
Acked-by: Acked-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu
ange, is not the case.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)")
Cc: Jason Ekstrand
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Brost
Cc: Matthew Auld
Cc: Maar
full-ppgtt platforms. Ditching it all seemed
like a better idea.
Reviewed-by: Maarten Lankhorst
References: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running
contexts (v4)")
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Hellström"
Cc: Lionel Landwerlin
Cc: Dave Airlie
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-
s either a full ppgtt stored in gem->ctx, or the ggtt.
We'll make more use of this function later on.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hell
xt->vm or gt->vm,
which is always set.
v2: 0day found a testcase that I missed.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 +
r an accident
where we run kernel stuff in userspace vm or the other way round.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Li
close to anything
that's a hotpath where removing the single spinlock can be measured).
v2: Rebase over the change to move the i915_vm_put() into
i915_gem_context_release().
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankho
ris Wilson
Date: Fri Aug 30 19:03:25 2019 +0100
drm/i915: Use RCU for unlocked vm_idr lookup
except we have the conversion from idr to xarray in between.
v2: kref_get_unless_zero is no longer required (Maarten)
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
e also remove the rcu_barrier in ggtt_cleanup_hw added in
commit 60a4233a4952729089e4df152e730f8f4d0e82ce
Author: Chris Wilson
Date: Mon Jul 29 14:24:12 2019 +0100
drm/i915: Flush the i915_vm_release before ggtt shutdown
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon
On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
>
> On 31/08/2021 13:43, Daniel Vetter wrote:
> > On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 30/08/2021 09:26, Daniel Vetter wrote:
> > > > On Fri, Aug 27
On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
wrote:
>
>
> On 13/08/2021 21:30, Daniel Vetter wrote:
> > The only reason for this really is the i915_gem_engines->fence
> > callback engines_notify(), which exists purely as a fairly funky
> > reference counting scheme
On Thu, Sep 02, 2021 at 03:54:36PM +0100, Tvrtko Ursulin wrote:
> On 02/09/2021 15:20, Daniel Vetter wrote:
> > And use it anywhere we have open-coded checks for ctx->vm that really
> > only check for full ppgtt.
> >
> > Plus for paranoia add a GEM_BUG_ON that checks
On Thu, Sep 02, 2021 at 05:05:05PM +, Bloomfield, Jon wrote:
> > -Original Message-
> > From: Tvrtko Ursulin
> > Sent: Thursday, September 2, 2021 9:42 AM
> > To: Daniel Vetter
> > Cc: Daniel Vetter ; DRI Development > de...@lists.freedesktop.org&
_gt_driver_unregister(struct intel_gt *gt)
> * all in-flight requests so that we can quickly unbind the active
> * resources.
> */
> - intel_gt_set_wedged(gt);
> + intel_gt_set_wedged_on_fini(gt);
>
> /* Scrub all HW state upon relea
On Thu, Sep 2, 2021 at 6:20 PM Tvrtko Ursulin
wrote:
> On 02/09/2021 16:05, Daniel Vetter wrote:
> > On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 13/08/2021 21:30, Daniel Vetter wrote:
> >>> The only
i915/gt/intel_gt_requests.h
> > > > @@ -6,7 +6,7 @@
> > > > #ifndef INTEL_GT_REQUESTS_H
> > > > #define INTEL_GT_REQUESTS_H
> > > >
> > > > -#include
> > > > +#include
> > > >
> > > > struct intel_engine_cs;
> > > > struct intel_gt;
> > > > --
> > > > 2.32.0
>
> Ping? I am still applying this ...
Apologies, this fell through a lot of cracks. I applied this to drm-next now.
Matt/John, as author/committer it's your job to make sure issues and
fixes for the stuff you're pushing don't get lost. I'd have expected
John to apply this to at least drm-intel-gt-next (it's not even
there).
Joonas, I think this is the 2nd or 3rd or so issue this release cycle
where some compile fix got stuck a bit because drm-intel-gt-next isn't
in linux-next. Can we please fix that? It probably needs some changes
to the dim script.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Sep 03, 2021 at 09:05:00AM +0100, Tvrtko Ursulin wrote:
>
> On 02/09/2021 15:20, Daniel Vetter wrote:
> > The important part isn't so much that this does an rcu lookup - that's
> > more an implementation detail, which will also be removed.
> >
> >
-ish to amdgpu's DC.
But I'm honestly not sure how much that would improve anything, and
whether it's worth all the churn to make drm/i915/display more
self-contained.
-Daniel
> Has anyone any non-anecdotal knowledge of how bad the latter problem
> actually is?
> Other drivers seem to do a lot of it and nobody has complained about it.
>
> I'm happy to move to a pointer for it all to be honest,
> Dave.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Sep 03, 2021 at 01:47:52PM +0100, Tvrtko Ursulin wrote:
>
> On 29/07/2021 15:06, Daniel Vetter wrote:
> > On Thu, Jul 29, 2021 at 3:34 PM Tvrtko Ursulin
> > wrote:
> > >
> > > From: Tvrtko Ursulin
> > >
> > > Usage of Transparent H
On Wed, Sep 8, 2021 at 5:14 AM Masahiro Yamada wrote:
>
> On Mon, Sep 6, 2021 at 4:34 PM Daniel Vetter wrote:
> >
> > On Mon, Sep 6, 2021 at 12:49 AM Stephen Rothwell
> > wrote:
> > > Hi all,
> > >
> > > On Thu, 2 Sep 2021 07:50:38 +1000 Ste
(6)
> +#define GEN12_CCS1 (5)
> +#define GEN12_CCS0 (4)
> #define GEN11_RCS0 (0)
>
> #define GEN11_GT_INTR_DW1_MMIO(0x19001c)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bde5860b3686..9540f33523d8 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -166,6 +166,7 @@ enum drm_i915_gem_engine_class {
Please add kerneldoc for any updated/new uapi.
-Daniel
> I915_ENGINE_CLASS_COPY = 1,
> I915_ENGINE_CLASS_VIDEO = 2,
> I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
> + I915_ENGINE_CLASS_COMPUTE = 4,
>
> /* should be kept compact */
>
> --
> 2.25.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ENDER,
> + [CCS3] = GEN11_GRDOM_RENDER,
> };
> struct intel_engine_cs *engine;
> intel_engine_mask_t tmp;
> --
> 2.25.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Sep 02, 2021 at 04:01:40PM +0100, Tvrtko Ursulin wrote:
>
> On 02/09/2021 15:33, Daniel Vetter wrote:
> > On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 31/08/2021 13:43, Daniel Vetter wrote:
> > > > On Tue, Aug 31
lags)) {
> lrc_init_state(ce, engine, *vaddr);
>
> - __i915_gem_object_flush_map(ce->state->obj, 0,
> engine->context_size);
> + __i915_gem_object_flush_map(ce->state->obj, 0,
> engine->context_size);
> }
>
> return 0;
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;t matter. We still leave the
> spin_lock_init() in the ctor, since we can't re-init the rq->lock in
> case it is already held.
Holding rq->lock without having a full reference to it sounds like really
bad taste. I think it would be good to have a (kerneldoc) comment next to
i915
MUTEXES
> > + DEBUG_LOCKS_WARN_ON(ww->base.magic != &ww->base);
> > +#endif
> > +
> > + preempt_disable();
> > + locked = __mutex_trylock(&ww->base);
> > +
> > + if (locked) {
> > + ww_mutex_set_context_fastpath(ww, ctx);
> > + mutex_acquire_nest(&ww->base.dep_map, 0, 1, &ctx->dep_map,
> > _RET_IP_);
> > + }
> > + preempt_enable();
> > +
> > + return locked;
> > +}
> > +EXPORT_SYMBOL(ww_mutex_trylock);
>
> You'll need a similar hunk in ww_rt_mutex.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
is rather
> ugly right now.
>
> (maybe I should always pull it in before sending to Linus to avoid
> this in future).
>
> Dave.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jun 18, 2021 at 04:46:24PM +0100, Matthew Auld wrote:
> On Thu, 17 Jun 2021 at 18:27, Daniel Vetter wrote:
> >
> > On Mon, Jun 14, 2021 at 09:45:37PM +0900, Sergey Senozhatsky wrote:
> > > Hi,
> > >
> > > We are observing some user-space cras
On Mon, Jun 21, 2021 at 04:30:50PM +0200, Maarten Lankhorst wrote:
> Op 21-06-2021 om 11:33 schreef Matthew Auld:
> > On 18/06/2021 22:45, Daniel Vetter wrote:
> >> In
> >>
> >> commit ebc0808fa2da0548a78e715858024cb81cd732bc
> >> Author: Chris Wilson
frame+0x44/0xae
daniel@phenom:~/linux/drm-misc-fixes$ dim fixes
1815d9c86e3090477fbde066ff314a7e9721ee0f
Fixes: 1815d9c86e30 ("drm: add a locked version of drm_is_current_master")
Cc: Desmond Cheong Zhi Xi
Cc: Emil Velikov
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
Cc: Ma
but the full audit is not yet done.
Cheers, Daniel
Daniel Vetter (15):
dma-resv: Fix kerneldoc
dma-buf: Switch to inline kerneldoc
dma-buf: Document dma-buf implicit fencing/resv fencing rules
drm/panfrost: Shrink sched_lock
drm/panfrost: Use xarray and helpers for depedency tracking
d
es also hammer these in
again while we're at it.
Cc: mesa-...@lists.freedesktop.org
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Kristian H. Kristensen
Cc: Michel Dänzer
Cc: Daniel Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc
Also review & update everything while we're at it.
This is prep work to smash a ton of stuff into the kerneldoc for
@resv.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Nirmoy Das
Cc: Deepak R
Oversight from
commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
Author: Christian König
Date: Mon May 10 16:14:09 2021 +0200
dma-buf: rename and cleanup dma_resv_get_excl v3
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
drm/scheduler requires a lock between _init and _push_job, but the
reservation lock dance doesn't. So shrink the critical section a
notch.
v2: Lucas pointed out how this should really work, I got it all wrong
in v1.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Rob Herring
Cc: Tomeu V
: Alyssa Rosenzweig
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 41 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 65 +++--
drivers/gpu/drm/panfrost/pa
that against display.
With the prep work done to switch over to the dependency helpers this
is now a oneliner.
Signed-off-by: Daniel Vetter
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...
more clarity
in smaller drivers.
While at it complain if there's a cleanup_fb hook but no prepare_fb
hook, because that makes no sense. I haven't found any driver which
violates this, but better safe than sorry.
Subsequent patches will reap the benefits.
Signed-off-by: Daniel Vetter
Cc: Maar
No need to set it explicitly.
Acked-by: Heiko Stuebner
Acked-by: Paul Cercueil
Acked-by: Jernej Skrabec
Acked-by: Chun-Kuang Hu
Acked-by: Martin Blumenstingl
Acked-by: Tomi Valkeinen
Acked-by: Philippe Cornu
Acked-by: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Laurentiu Palcu
Cc
see __drm_atomic_helper_plane_destroy_state()
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 2 --
drivers/gpu/drm/armada/armada_plane.c | 29 -
drivers/gpu/drm/armada/armada_plane.h | 2 --
3 files changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/arm
Like we have for the shadow helpers too, and roll it out to drivers.
Acked-by: Tian Tao
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Hans de Goede
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Tian Tao
Cc: Laurent Pinchart
Goes through all the drivers and deletes the default hook since it's
the default now.
Acked-by: David Lechner
Acked-by: Noralf Trønnes
Acked-by: Oleksandr Andrushchenko
Acked-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes&q
Spotted while trying to convert panfrost to these.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3
make sense, and since simpler drivers are all new they better be GEM
based drivers.
v2: Warn and bail when it's _not_ a GEM driver (Noralf)
Cc: Noralf Trønnes
Acked-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airli
I guess no one ever tried running omap together with lima or panfrost,
not even sure that's possible. Anyway for consistency, fix this.
Reviewed-by: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_plane.c | 3 +++
1 file changed, 3 inser
Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
On Tue, Jun 22, 2021 at 8:50 PM Sam Ravnborg wrote:
>
> Hi Daniel,
>
> On Tue, Jun 22, 2021 at 06:54:57PM +0200, Daniel Vetter wrote:
> > Oversight from
> >
> > commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> > Author: Christian König
> > Date: Mon M
On Tue, Jun 22, 2021 at 9:01 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Tue, Jun 22, 2021 at 06:54:58PM +0200, Daniel Vetter wrote:
> > Also review & update everything while we're at it.
> >
> > This is prep work to smash a ton of stuff into the kerneld
On Tue, Jun 22, 2021 at 9:10 PM Sam Ravnborg wrote:
>
> Hi Daniel,
>
> On Tue, Jun 22, 2021 at 06:55:03PM +0200, Daniel Vetter wrote:
> > There's a bunch of atomic drivers who don't do this quite correctly,
> > luckily most of them aren't in wide use or pe
On Wed, Jun 23, 2021 at 10:09 AM Desmond Cheong Zhi Xi
wrote:
>
> On 22/6/21 3:54 pm, Daniel Vetter wrote:
> > This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.
> >
> > Unfortunately this inverts the locking hierarchy, so back to the
> > drawing b
On Wed, Jun 23, 2021 at 11:51 AM Desmond Cheong Zhi Xi
wrote:
>
> On 23/6/21 4:14 pm, Daniel Vetter wrote:
> > On Wed, Jun 23, 2021 at 10:09 AM Desmond Cheong Zhi Xi
> > wrote:
> >>
> >> On 22/6/21 3:54 pm, Daniel Vetter wrote:
> >>> This reverts
On Wed, Jun 23, 2021 at 11:45 AM Bas Nieuwenhuizen
wrote:
>
> On Tue, Jun 22, 2021 at 6:55 PM Daniel Vetter wrote:
> >
> > WARNING: Absolutely untested beyond "gcc isn't dying in agony".
> >
> > Implicit fencing done properly needs to treat the implic
On Wed, Jun 23, 2021 at 3:44 PM Christian König
wrote:
>
> Am 23.06.21 um 15:38 schrieb Bas Nieuwenhuizen:
> > On Wed, Jun 23, 2021 at 2:59 PM Christian König
> > wrote:
> >> Am 23.06.21 um 14:18 schrieb Daniel Vetter:
> >>> On Wed, Jun 23, 2021 at
On Wed, Jun 23, 2021 at 4:02 PM Christian König
wrote:
>
> Am 23.06.21 um 15:49 schrieb Daniel Vetter:
> > On Wed, Jun 23, 2021 at 3:44 PM Christian König
> > wrote:
> >> Am 23.06.21 um 15:38 schrieb Bas Nieuwenhuizen:
> >>> On Wed, Jun 23, 2021 at 2:59 PM
On Wed, Jun 23, 2021 at 04:58:27PM +0200, Bas Nieuwenhuizen wrote:
> On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 23, 2021 at 4:02 PM Christian König
> > wrote:
> > >
> > > Am 23.06.21 um 15:49 schrieb Daniel Vetter:
> >
915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM);
> +i915_gem_object_has_iomem(obj);
> }
>
> static int __igt_mmap_access(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c
> b/drivers/gpu/drm/i915/gem/se
On Wed, Jun 23, 2021 at 05:07:17PM +0200, Christian König wrote:
> Am 23.06.21 um 17:03 schrieb Daniel Vetter:
> > On Wed, Jun 23, 2021 at 04:58:27PM +0200, Bas Nieuwenhuizen wrote:
> > > On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter
> > > wrote:
> > > > On
On Wed, Jun 23, 2021 at 10:31:18AM +0200, Christian König wrote:
> Am 22.06.21 um 18:54 schrieb Daniel Vetter:
> > Oversight from
> >
> > commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> > Author: Christian König
> > Date: Mon May 10 16:14:09 2021 +0200
y: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Nirmoy Das
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
include/li
Nieuwenhuizen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Kristian H. Kristensen
Cc: Michel Dänzer
Cc: Daniel Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@list
(Sam)
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 10 ++
drivers/gpu/drm/drm_gem_atomic_helper.c | 3 +++
include/drm/drm
make sense, and since simpler drivers are all new they better be GEM
based drivers.
v2: Warn and bail when it's _not_ a GEM driver (Noralf)
v3: It's neither ... nor, not not (Sam)
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Acked-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: Maarten Lan
On Wed, Jun 23, 2021 at 5:38 PM Thomas Hellström
wrote:
>
> Thanks for reviewing, Daniel.
>
> On 6/23/21 5:09 PM, Daniel Vetter wrote:
> >
> >>
> >> +unsigned int mem_flags:2;
> > Is the entire bitfield array all protected by dma_resv_lock? If not
mory_region.h
> index 2be8433d373a..6f7a073d5a70 100644
> --- a/drivers/gpu/drm/i915/intel_memory_region.h
> +++ b/drivers/gpu/drm/i915/intel_memory_region.h
> @@ -74,6 +74,7 @@ struct intel_memory_region {
> resource_size_t io_start;
> resource_size_t min_page_size;
>
On Wed, Jun 23, 2021 at 06:47:37PM +0200, Boris Brezillon wrote:
> On Tue, 22 Jun 2021 18:55:02 +0200
> Daniel Vetter wrote:
>
> > Currently this has no practial relevance I think because there's not
> > many who can pull off a setup with panfrost and another gpu in th
On Wed, Jun 23, 2021 at 08:35:30PM +0100, Matthew Auld wrote:
> On Wed, 23 Jun 2021 at 20:15, Daniel Vetter wrote:
> >
> > On Wed, Jun 23, 2021 at 06:27:06PM +0100, Matthew Auld wrote:
> > > Looks like it got lost along the way, so add it back. This is needed for
> >
On Thu, Jun 24, 2021 at 1:08 PM Daniel Stone wrote:
>
> Hi,
>
> On Wed, 23 Jun 2021 at 17:20, Daniel Vetter wrote:
> > +*
> > +* IMPLICIT SYNCHRONIZATION RULES:
> > +*
> > +* Drivers which support implicit sync
601 - 700 of 23475 matches
Mail list logo
