All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Zhanjun Dong <zhanjun.dong@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	alan.previn.teres.alexis@intel.com
Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response
Date: Tue, 14 Jun 2022 13:01:22 -0700	[thread overview]
Message-ID: <87y1xzf20d.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <87zgiffbvl.wl-ashutosh.dixit@intel.com>

On Tue, 14 Jun 2022 09:28:14 -0700, Dixit, Ashutosh wrote:
> On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>
> > @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> >  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
> >  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
> >  #define done \
> > -	(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> > +	(!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> >	 GUC_HXG_ORIGIN_GUC)
> >	err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
> >	if (err)
> >		err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
> >  #undef done
> > +	if (!intel_guc_ct_enabled(ct))
> > +		err = -ECANCELED;
>
> Also, I really don't like intel_guc_ct_enabled() being called in two
> places. Is there a possibility that intel_guc_ct_enabled() can return false
> in the first place (causing the wait to exit) and then return true in the
> second place (so we don't return -ECANCELED)?
>
> Is it possible to change the status of the request to something else from
> intel_guc_ct_disable() (or wherever ct->enabled is set to false) rather
> than introducing intel_guc_ct_enabled() checks here. Changing the status of
> the request when CT goes down would cause the wait's to exit here. And then
> we can check that special request status signifying CT went down?

I think there are free bits in the request status fields which can be
used. But setting the request status say from intel_guc_ct_enabled() might
not be straightforward since you have to locate waiting requests and also
there may be multiple such requests (waiting in different threads).

Maybe an easier way might be to do something like:

bool foo(ct, req)
{
	if (!intel_guc_ct_enabled(ct)) {
		req->status = CT_WENT_AWAY;
		return true;
	}
	return false;
}

Now in your patch we can substitute foo() instead of
!intel_guc_ct_enabled(ct) so that we have:

 #define done \
    (foo() || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
     GUC_HXG_ORIGIN_GUC)

And then check for req->status == CT_WENT_AWAY (most likely in ct_send()).

WARNING: multiple messages have this Message-ID (diff)
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Zhanjun Dong <zhanjun.dong@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	alan.previn.teres.alexis@intel.com, michal.wajdeczko@intel.com
Subject: Re: [PATCH] drm/i915/guc: Check ctx while waiting for response
Date: Tue, 14 Jun 2022 13:01:22 -0700	[thread overview]
Message-ID: <87y1xzf20d.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <87zgiffbvl.wl-ashutosh.dixit@intel.com>

On Tue, 14 Jun 2022 09:28:14 -0700, Dixit, Ashutosh wrote:
> On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>
> > @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> >  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
> >  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
> >  #define done \
> > -	(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> > +	(!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> >	 GUC_HXG_ORIGIN_GUC)
> >	err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
> >	if (err)
> >		err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
> >  #undef done
> > +	if (!intel_guc_ct_enabled(ct))
> > +		err = -ECANCELED;
>
> Also, I really don't like intel_guc_ct_enabled() being called in two
> places. Is there a possibility that intel_guc_ct_enabled() can return false
> in the first place (causing the wait to exit) and then return true in the
> second place (so we don't return -ECANCELED)?
>
> Is it possible to change the status of the request to something else from
> intel_guc_ct_disable() (or wherever ct->enabled is set to false) rather
> than introducing intel_guc_ct_enabled() checks here. Changing the status of
> the request when CT goes down would cause the wait's to exit here. And then
> we can check that special request status signifying CT went down?

I think there are free bits in the request status fields which can be
used. But setting the request status say from intel_guc_ct_enabled() might
not be straightforward since you have to locate waiting requests and also
there may be multiple such requests (waiting in different threads).

Maybe an easier way might be to do something like:

bool foo(ct, req)
{
	if (!intel_guc_ct_enabled(ct)) {
		req->status = CT_WENT_AWAY;
		return true;
	}
	return false;
}

Now in your patch we can substitute foo() instead of
!intel_guc_ct_enabled(ct) so that we have:

 #define done \
    (foo() || FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
     GUC_HXG_ORIGIN_GUC)

And then check for req->status == CT_WENT_AWAY (most likely in ct_send()).

  parent reply	other threads:[~2022-06-14 20:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 17:21 [Intel-gfx] [PATCH] drm/i915/guc: Check ctx while waiting for response Zhanjun Dong
2022-06-02 17:21 ` Zhanjun Dong
2022-06-02 17:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-06-02 18:05 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-02 22:58 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-06-14 15:34 ` [Intel-gfx] [PATCH] " Teres Alexis, Alan Previn
2022-06-14 16:10 ` Michal Wajdeczko
2022-06-14 16:21 ` Jani Nikula
2022-06-14 16:21   ` Jani Nikula
2022-06-14 16:28 ` Dixit, Ashutosh
2022-06-14 16:28   ` Dixit, Ashutosh
2022-06-14 18:42   ` [Intel-gfx] " Dong, Zhanjun
2022-06-14 18:42     ` Dong, Zhanjun
2022-06-14 20:01   ` Dixit, Ashutosh [this message]
2022-06-14 20:01     ` Dixit, Ashutosh

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=87y1xzf20d.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=alan.previn.teres.alexis@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=zhanjun.dong@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.