From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 3/9] drm/xe/rtp: Keep track of non-OA nonpriv slots
Date: Fri, 29 May 2026 18:51:47 -0700 [thread overview]
Message-ID: <8733z9mzpo.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <ahogLn6RQKw21klf@soc-5CG1426VCC.clients.intel.com>
On Fri, 29 May 2026 16:24:30 -0700, Umesh Nerlige Ramappa wrote:
>
> On Fri, May 29, 2026 at 01:45:12PM -0700, Dixit, Ashutosh wrote:
> > On Fri, 29 May 2026 11:30:34 -0700, Umesh Nerlige Ramappa wrote:
> >>
> >> On Mon, May 18, 2026 at 04:47:10PM -0700, Ashutosh Dixit wrote:
> >> > In order to dynamically whitelist/dewhitelist OA registers on OA stream
> >> > open/close, we need to keep track of nonpriv slots occupied by non-OA
> >> > register whitelists.
> >>
> >> Can we maintain the slot index within hwe, so that the caller does not need
> >> to keep track of it? I am assuming this will only be used in the probe
> >> path. For all other paths the *_sr registers are used directly which
> >> already have the registre<->slot association stored within them.
> >>
> >> i.e.
> >>
> >> hwe->slot;
> >
> > Hmm, when I first wrote the code, I had this in hwe: hwe->nonpriv_slots.
> > But later realized it is only needed in xe_reg_whitelist_process_engine(),
> > so moved it to the local variable nonpriv_slots there.
> >
> > Also, nonpriv_slots is actually number of slots occupied by non-OA
> > registers. So if it part of hwe, the question becomes more complicated:
> > what do we store there, number of slots excluding OA or including OA? Since
> > we only need number of slots excluding OA.
>
> I would just think of it as the next available nonpriv slot for the caller
> to use. It's just a state w.r.t the hwe. When you let the caller (even if
> internal to the KMD) manage it, it's prone to errors - not about this
> series or current code, but in general.
OK, will do this in v2. Thanks.
> >
> > Therefore, to avoid these complications, I decided that the best way was a
> > temporary local variable.
> >
> > What do you think we'd gain by maintaining it as part of hwe? If things
> > change later, we could add it, but for now the local variable seems
> > sufficient?
>
> >
> > Thanks.
> > --
> > Ashutosh
> >
> >> >
> >> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >> > ---
> >> > drivers/gpu/drm/xe/xe_reg_whitelist.c | 8 ++++++--
> >> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/xe/xe_reg_whitelist.c b/drivers/gpu/drm/xe/xe_reg_whitelist.c
> >> > index 6cc81f53fc601..1e788e2ee4014 100644
> >> > --- a/drivers/gpu/drm/xe/xe_reg_whitelist.c
> >> > +++ b/drivers/gpu/drm/xe/xe_reg_whitelist.c
> >> > @@ -159,7 +159,7 @@ static const struct xe_rtp_entry_sr oa_whitelist[] = {
> >> > },
> >> > };
> >> >
> >> > -static void whitelist_apply_to_hwe(struct xe_hw_engine *hwe)
> >> > +static int whitelist_apply_to_hwe(struct xe_hw_engine *hwe)
> >> > {
> >> > struct xe_reg_sr *sr = &hwe->reg_whitelist;
> >> > struct xe_reg_sr_entry *entry;
> >> > @@ -191,6 +191,8 @@ static void whitelist_apply_to_hwe(struct xe_hw_engine *hwe)
> >> >
> >> > slot++;
> >> > }
> >> > +
> >> > + return slot;
> >> > }
> >> >
> >> > /**
> >> > @@ -203,11 +205,13 @@ static void whitelist_apply_to_hwe(struct xe_hw_engine *hwe)
> >> > */
> >> > void xe_reg_whitelist_process_engine(struct xe_hw_engine *hwe)
> >> > {
> >> > + int nonpriv_slots;
> >> > +
> >> > struct xe_rtp_process_ctx ctx = XE_RTP_PROCESS_CTX_INITIALIZER(hwe);
> >> >
> >> > xe_rtp_process_to_sr(&ctx, register_whitelist, ARRAY_SIZE(register_whitelist),
> >> > &hwe->reg_whitelist, false);
> >> > - whitelist_apply_to_hwe(hwe);
> >> > + nonpriv_slots = whitelist_apply_to_hwe(hwe);
> >> >
> >> > xe_rtp_process_to_sr(&ctx, oa_whitelist, ARRAY_SIZE(oa_whitelist),
> >> > &hwe->oa_whitelist, false);
> >> > --
> >> > 2.54.0
> >> >
next prev parent reply other threads:[~2026-05-30 1:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 23:47 [PATCH 0/9] Don't whitelist OA registers unconditionally Ashutosh Dixit
2026-05-18 23:47 ` [PATCH 1/9] drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Ashutosh Dixit
2026-05-21 23:14 ` Umesh Nerlige Ramappa
2026-05-21 23:35 ` Dixit, Ashutosh
2026-05-26 19:12 ` Umesh Nerlige Ramappa
2026-05-27 20:03 ` Umesh Nerlige Ramappa
2026-05-29 19:12 ` Dixit, Ashutosh
2026-05-18 23:47 ` [PATCH 2/9] drm/xe/rtp: Maintain OA whitelists separately Ashutosh Dixit
2026-05-29 18:31 ` Umesh Nerlige Ramappa
2026-05-18 23:47 ` [PATCH 3/9] drm/xe/rtp: Keep track of non-OA nonpriv slots Ashutosh Dixit
2026-05-29 18:30 ` Umesh Nerlige Ramappa
2026-05-29 20:45 ` Dixit, Ashutosh
2026-05-29 23:24 ` Umesh Nerlige Ramappa
2026-05-30 1:51 ` Dixit, Ashutosh [this message]
2026-05-18 23:47 ` [PATCH 4/9] drm/xe/rtp: Generalize whitelist_apply_to_hwe Ashutosh Dixit
2026-05-18 23:47 ` [PATCH 5/9] drm/xe/rtp: Save OA nonpriv registers to register save/restore lists Ashutosh Dixit
2026-05-27 22:00 ` Umesh Nerlige Ramappa
2026-05-29 20:45 ` Dixit, Ashutosh
2026-05-18 23:47 ` [PATCH 6/9] drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regs Ashutosh Dixit
2026-05-29 18:33 ` Umesh Nerlige Ramappa
2026-05-18 23:47 ` [PATCH 7/9] drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gt Ashutosh Dixit
2026-05-27 21:49 ` Umesh Nerlige Ramappa
2026-05-29 23:03 ` Dixit, Ashutosh
2026-06-02 22:47 ` Umesh Nerlige Ramappa
2026-06-03 18:49 ` Dixit, Ashutosh
2026-05-18 23:47 ` [PATCH 8/9] drm/xe/oa: (De-)whitelist OA registers on OA stream open/release Ashutosh Dixit
2026-05-29 18:35 ` Umesh Nerlige Ramappa
2026-05-18 23:47 ` [PATCH 9/9] drm/xe/rtp: Ensure locking/ref counting for OA whitelists Ashutosh Dixit
2026-05-27 20:04 ` Umesh Nerlige Ramappa
2026-06-01 23:30 ` Dixit, Ashutosh
2026-05-18 23:54 ` ✓ CI.KUnit: success for Don't whitelist OA registers unconditionally Patchwork
2026-05-19 1:05 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-19 8:32 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-05-27 19:53 ` [PATCH 0/9] " Demi Marie Obenour
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=8733z9mzpo.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--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 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.