All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Nirmoy Das <nirmoy.das@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Nirmoy Das <nirmoy.das@linux.intel.com>,
	Michal Wajdeczko <michal.wajdeczko@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 3/9] drm/xe/xe_reg_sr: Always call xe_force_wake_put/get in pairs
Date: Thu, 6 Jun 2024 13:46:51 -0400	[thread overview]
Message-ID: <ZmH2C6oT0A0-IjKf@intel.com> (raw)
In-Reply-To: <2f8c48f3-598c-4bc8-b9ca-da22e380c130@intel.com>

On Wed, Jun 05, 2024 at 12:49:42PM +0200, Nirmoy Das wrote:
> 
> On 6/4/2024 11:13 PM, Lucas De Marchi wrote:
> > On Tue, Jun 04, 2024 at 04:21:25PM GMT, Nirmoy Das wrote:
> > > Hi Michal,
> > > 
> > > On 6/4/2024 3:12 PM, Michal Wajdeczko wrote:
> > > > 
> > > > On 04.06.2024 13:02, Nirmoy Das wrote:
> > > > > xe_force_wake_get() increments the domain ref regardless of success
> > > > > or failure so call xe_force_wake_put() even on failure to keep ref
> > > > > count accurate.
> > > > > 
> > > > > Signed-off-by: Nirmoy Das<nirmoy.das@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/xe/xe_reg_sr.c | 20 ++++++++------------
> > > > >  1 file changed, 8 insertions(+), 12 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/xe/xe_reg_sr.c
> > > > > b/drivers/gpu/drm/xe/xe_reg_sr.c
> > > > > index 440ac572f6e5..8fcc08658d89 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_reg_sr.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_reg_sr.c
> > > > > @@ -201,13 +201,11 @@ void xe_reg_sr_apply_mmio(struct
> > > > > xe_reg_sr *sr, struct xe_gt *gt)
> > > > >      xa_for_each(&sr->xa, reg, entry)
> > > > >          apply_one_mmio(gt, entry);
> > > > > -    err = xe_force_wake_put(&gt->mmio.fw, XE_FORCEWAKE_ALL);
> > > > > -    XE_WARN_ON(err);
> > > > > -
> > > > > -    return;
> > > > > -
> > > > >  err_force_wake:
> > > > > -    xe_gt_err(gt, "Failed to apply, err=%d\n", err);
> > > > > +    if (err)
> > > > > +        xe_gt_err(gt, "Failed to whitelist %s registers, err=%d\n",
> > > > > +              sr->name, err);
> > > > > +    XE_WARN_ON(xe_force_wake_put(&gt->mmio.fw, XE_FORCEWAKE_ALL));
> > > > what's the rule whether to WARN about the failed xe_force_wake_put() or
> > > > not ? should we also WARN when xe_force_wake_get() failed ? does
> > > > it make
> > > > sense to WARN about put() if get() already failed ?
> > > We don't have one yet.
> > > > 
> > > > maybe simpler solution would be make function xe_force_wake_put() void
> > > > as it almost nothing that caller can do and move WARN there if needed ?
> > > 
> > > We have code that  does "return xe_force_wake_put()" So question is
> > > what shall we do
> > > 
> > > if xe_force_wake_get() worked but subsequent xe_force_wake_put() fails ?
> > 
> > there's not much can be done here. I even don't think there's a reason
> > to wait on ack for force_wake put... in most of the cases.
> > +Rodrigo, what exactly are we protecting against there?
> > 
> > If that xe_mmio_wait32() fails, driver is toast. The reason we check (or
> > should check) the return on _get() is because we want to bail out
> > whatever we are starting to do rather than attempting it and handling
> > bogus values of an IP that is not awaken.
> > 
> > So, maybe what could be done is
> > 
> > a) XE_WARN_ON(xe_force_wake_put()) -> xe_force_wake_put()
> > 
> >     We cann probably move the WARN_ON() inside xe_force_wake_put()
> >     if we want to maintain the behavior in most places
> > 
> >     Then make xe_force_wake_put() void as suggested here.

yeap, I believe we have a rough consensus here that put should be void function
and perhaps (likely?!) with some warn inside it.

> > 
> > b) I'm not sure about the benefit of the weirdness of
> > xe_force_wake_get() incrementing the ref even if we failed to wait for
> > ack.  The only thing the caller is going to do is to call
> > xe_force_wake_put() and bail out. Why are we not unwinding then?
> 
> With unwinding of ref count and partial woken domains on error, we should be
> able do
> 
> 
>     if (xe_force_wake_get(fw, d)) {
>         ...
>         xe_force_wake_put(fw, d);
> 
>     }
> 
> I will let Rodrigo suggest how best to handle this.

I believe the benefit of trying to run the code even when ack timed out
is on clean up cases, since we use this force_wake on a broader scope,
rather then only around the specific mmio calls that we really need it.

So, I'm okay with make this proposed flow as the rule, on always
checking the force_wake_get result before doing operations.
But maybe on top of that it would be worth to scrutinize a bit
the callers and see if we can/should reduce the scope of impact.

> 
> 
> Thanks,
> 
> Nirmoy
> 
> > 
> > 
> > Lucas De Marchi
> > 
> > > 
> > > Regards,
> > > 
> > > Nirmoy
> > > 
> > > > 
> > > > what about making the flow more intuitive like this:
> > > > 
> > > > bool xe_force_wake_get(fw, d);
> > > > void xe_force_wake_put(fw, d);
> > > > 
> > > >     if (xe_force_wake_get(fw, d)) {
> > > >         ...
> > > >         xe_force_wake_put(fw, d);
> > > >     }
> > > > 
> > > > >  }
> > > > >  void xe_reg_sr_apply_whitelist(struct xe_hw_engine *hwe)
> > > > > @@ -253,13 +251,11 @@ void xe_reg_sr_apply_whitelist(struct
> > > > > xe_hw_engine *hwe)
> > > > >          xe_mmio_write32(gt,
> > > > > RING_FORCE_TO_NONPRIV(mmio_base, slot), addr);
> > > > >      }
> > > > > -    err = xe_force_wake_put(&gt->mmio.fw, XE_FORCEWAKE_ALL);
> > > > > -    XE_WARN_ON(err);
> > > > > -
> > > > > -    return;
> > > > > -
> > > > >  err_force_wake:
> > > > > -    drm_err(&xe->drm, "Failed to apply, err=%d\n", err);
> > > > > +    if (err)
> > > > > +        xe_gt_err(gt, "Failed to whitelist %s registers, err=%d\n",
> > > > > +              sr->name, err);
> > > > > +    XE_WARN_ON(xe_force_wake_put(&gt->mmio.fw, XE_FORCEWAKE_ALL));
> > > > >  }
> > > > >  /**

  reply	other threads:[~2024-06-06 17:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 11:02 [PATCH 0/9] Ensure xe_force_wake_put is always called after xe_force_wake_get Nirmoy Das
2024-06-04 11:02 ` [PATCH 1/9] drm/xe/display: Always call xe_force_wake_put/get in pairs Nirmoy Das
2024-06-04 11:41   ` Ghimiray, Himal Prasad
2024-06-04 11:02 ` [PATCH 2/9] drm/xe/pat: " Nirmoy Das
2024-06-04 12:54   ` Michal Wajdeczko
2024-06-04 13:06     ` Nirmoy Das
2024-06-04 11:02 ` [PATCH 3/9] drm/xe/xe_reg_sr: " Nirmoy Das
2024-06-04 13:12   ` Michal Wajdeczko
2024-06-04 14:21     ` Nirmoy Das
2024-06-04 21:13       ` Lucas De Marchi
2024-06-05 10:49         ` Nirmoy Das
2024-06-06 17:46           ` Rodrigo Vivi [this message]
2024-06-10  9:59             ` Nirmoy Das
2024-06-04 11:02 ` [PATCH 4/9] drm/xe/xe_gt: " Nirmoy Das
2024-06-04 11:02 ` [PATCH 5/9] drm/xe/uc: " Nirmoy Das
2024-06-04 11:02 ` [PATCH 6/9] drm/xe: Add xe_force_wake_tryget to simplify forcewake handling Nirmoy Das
2024-06-04 11:02 ` [PATCH 7/9] drm/xe: Use xe_force_wake_tryget when possible Nirmoy Das
2024-06-04 11:02 ` [PATCH 8/9] drm/xe/client: Check return value of xe_force_wake_get Nirmoy Das
2024-06-04 11:02 ` [PATCH 9/9] drm/xe: Add __must_check for xe_force_wake_get Nirmoy Das
2024-06-04 20:49 ` [PATCH 0/9] Ensure xe_force_wake_put is always called after xe_force_wake_get Lucas De Marchi
2024-06-05  1:06 ` ✓ CI.Patch_applied: success for " Patchwork
2024-06-05  1:07 ` ✓ CI.checkpatch: " Patchwork
2024-06-05  1:08 ` ✓ CI.KUnit: " Patchwork
2024-06-05  1:19 ` ✓ CI.Build: " Patchwork
2024-06-05  1:19 ` ✗ CI.Hooks: failure " Patchwork
2024-06-05  1:21 ` ✓ CI.checksparse: success " Patchwork
2024-06-05  1:48 ` ✓ CI.BAT: " Patchwork
2024-06-05 10:15 ` ✗ CI.FULL: 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=ZmH2C6oT0A0-IjKf@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=nirmoy.das@intel.com \
    --cc=nirmoy.das@linux.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.