From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: "Cavitt, Jonathan" <jonathan.cavitt@intel.com>
Cc: "Nerlige Ramappa, Umesh" <umesh.nerlige.ramappa@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Souza, Jose" <jose.souza@intel.com>
Subject: Re: [PATCH v5 1/2] xe/oa: Fix query mode of operation for OAR/OAC
Date: Fri, 20 Dec 2024 14:00:50 -0800 [thread overview]
Message-ID: <85ed2210bx.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <BL1PR11MB54457FB542D12F9E10AB2AD2E5072@BL1PR11MB5445.namprd11.prod.outlook.com>
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@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
next prev parent reply other threads:[~2024-12-20 22:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 17:19 [PATCH v5 0/2] Fixes for MI_REPORT_PERF_COUNT Umesh Nerlige Ramappa
2024-12-20 17:19 ` [PATCH v5 1/2] xe/oa: Fix query mode of operation for OAR/OAC Umesh Nerlige Ramappa
2024-12-20 18:08 ` Cavitt, Jonathan
2024-12-20 18:24 ` Dixit, Ashutosh
2024-12-20 18:51 ` Cavitt, Jonathan
2024-12-20 22:00 ` Dixit, Ashutosh [this message]
2024-12-20 17:19 ` [PATCH v5 2/2] xe/oa: Drop the unused logic to parse context image Umesh Nerlige Ramappa
2024-12-20 18:09 ` Cavitt, Jonathan
2024-12-20 18:03 ` ✓ CI.Patch_applied: success for Fixes for MI_REPORT_PERF_COUNT (rev5) Patchwork
2024-12-20 18:03 ` ✓ CI.checkpatch: " Patchwork
2024-12-20 18:05 ` ✓ CI.KUnit: " Patchwork
2024-12-20 18:23 ` ✓ CI.Build: " Patchwork
2024-12-20 18:25 ` ✓ CI.Hooks: " Patchwork
2024-12-20 18:27 ` ✓ CI.checksparse: " Patchwork
2024-12-20 18:59 ` ✓ Xe.CI.BAT: " Patchwork
2024-12-20 19:54 ` [PATCH v5 0/2] Fixes for MI_REPORT_PERF_COUNT Souza, Jose
2024-12-20 20:05 ` Dixit, Ashutosh
2024-12-21 0:35 ` Umesh Nerlige Ramappa
2024-12-21 22:41 ` ✗ Xe.CI.Full: failure for Fixes for MI_REPORT_PERF_COUNT (rev5) 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=85ed2210bx.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=jose.souza@intel.com \
--cc=umesh.nerlige.ramappa@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox