[PATCH v5 1/2] xe/oa: Fix query mode of operation for OAR/OAC
Dixit, Ashutosh
ashutosh.dixit at intel.com
Fri Dec 20 22:00:50 UTC 2024
On Fri, 20 Dec 2024 10:08:41 -0800, Cavitt, Jonathan wrote:
>
>
> I don't have any major blocking revision notes for this. Feel free to
> take or leave any of the questions/suggestions I left below.
> Reviewed-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
Thanks.
>
> > ---
> > drivers/gpu/drm/xe/xe_oa.c | 136 ++++++++----------------
> > drivers/gpu/drm/xe/xe_ring_ops.c | 5 +-
> > drivers/gpu/drm/xe/xe_sched_job_types.h | 2 +
> > 3 files changed, 51 insertions(+), 92 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c
> > index ae94490b0eac..9add60097ab5 100644
> > --- a/drivers/gpu/drm/xe/xe_oa.c
> > +++ b/drivers/gpu/drm/xe/xe_oa.c
> > @@ -74,12 +74,6 @@ struct xe_oa_config {
> > struct rcu_head rcu;
> > };
> >
> > -struct flex {
> > - struct xe_reg reg;
> > - u32 offset;
> > - u32 value;
> > -};
> > -
> > struct xe_oa_open_param {
> > struct xe_file *xef;
> > u32 oa_unit_id;
> > @@ -605,19 +599,38 @@ static __poll_t xe_oa_poll(struct file *file, poll_table *wait)
> > return ret;
> > }
> >
> > +static void xe_oa_lock_vma(struct xe_exec_queue *q)
> > +{
> > + if (q->vm) {
> > + down_read(&q->vm->lock);
> > + xe_vm_lock(q->vm, false);
> > + }
> > +}
> > +
> > +static void xe_oa_unlock_vma(struct xe_exec_queue *q)
> > +{
> > + if (q->vm) {
> > + xe_vm_unlock(q->vm);
> > + up_read(&q->vm->lock);
> > + }
> > +}
> > +
> > static struct dma_fence *xe_oa_submit_bb(struct xe_oa_stream *stream, enum xe_oa_submit_deps deps,
> > struct xe_bb *bb)
> > {
> > + struct xe_exec_queue *q = stream->exec_q ?: stream->k_exec_q;
> > struct xe_sched_job *job;
> > struct dma_fence *fence;
> > int err = 0;
> >
> > - /* Kernel configuration is issued on stream->k_exec_q, not stream->exec_q */
> > - job = xe_bb_create_job(stream->k_exec_q, bb);
> > + xe_oa_lock_vma(q);
> > +
> > + job = xe_bb_create_job(q, bb);
> > if (IS_ERR(job)) {
> > err = PTR_ERR(job);
> > goto exit;
> > }
> > + job->ggtt = true;
> >
> > if (deps == XE_OA_SUBMIT_ADD_DEPS) {
> > for (int i = 0; i < stream->num_syncs && !err; i++)
> > @@ -632,10 +645,13 @@ static struct dma_fence *xe_oa_submit_bb(struct xe_oa_stream *stream, enum xe_oa
> > fence = dma_fence_get(&job->drm.s_fence->finished);
> > xe_sched_job_push(job);
> >
> > + xe_oa_unlock_vma(q);
> > +
> > return fence;
> > err_put_job:
> > xe_sched_job_put(job);
> > exit:
> > + xe_oa_unlock_vma(q);
> > return ERR_PTR(err);
>
> Non-blocking note:
> Hmm... I'm not a big fan of needing to call xe_oa_unlock_vma for the
> two separate cases, though unless we wanted to completely
> restructure the ending sequence here, I think this is the best option.
>
> Though, I guess this is what the ending sequence restructuring would
> look like if we took that route:
> """
> fence = dma_fence_get(&job->drm.s_fence->finished);
> xe_sched_job_push(job);
>
> err_put_job:
> if (err)
> xe_sched_job_put(job);
> exit:
> xe_oa_unlock_vma(q);
> return err ? ERR_PTR(err) : fence;
> }
> """
> So it seems restructuring the exit sequence would be less of a bad option than
> I had initially thought, but it's not a necessary change.
About this, I think we are going to leave as is for now. But if interested
look at include/linux/cleanup.h for some other ideas.
Thanks.
--
Ashutosh
More information about the Intel-xe
mailing list