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
Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Check for ct enabled while waiting for response
Date: Mon, 25 Jul 2022 11:18:40 -0700 [thread overview]
Message-ID: <87k081ginz.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20220715211313.143645-1-zhanjun.dong@intel.com>
On Fri, 15 Jul 2022 14:13:13 -0700, Zhanjun Dong wrote:
>
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct intel_guc_ct *ct, struct ct_request *req, u32 *status)
> {
> int err;
> + bool ct_enabled;
>
> /*
> * Fast commands should complete in less than 10us, so sample quickly
> @@ -481,12 +483,15 @@ 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)) == \
> + (!(ct_enabled = 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 (!ct_enabled)
> + err = -ENODEV;
Good, -ENODEV seems to be the correct return value in this case.
>
> *status = req->status;
> return err;
> @@ -703,11 +708,18 @@ static int ct_send(struct intel_guc_ct *ct,
>
> intel_guc_notify(ct_to_guc(ct));
>
> - err = wait_for_ct_request_update(&request, status);
> + err = wait_for_ct_request_update(ct, &request, status);
> g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
> if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> - action[0], request.fence);
> + if (err == -ENODEV)
> + /* wait_for_ct_request_update returns -ENODEV on reset/suspend in progress.
> + * In this case, output is debug rather than error info
> + */
> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
A nit but I would probably prefer to move the CT_DEBUG() inside
wait_for_ct_request_update() (so we only keep 'if (err != -ENODEV)' checks
here) though it would mean adding the action argument also to
wait_for_ct_request_update().
In any case, since we have discussed this patch ad nauseam previously, this
is now:
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
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
Subject: Re: [PATCH] drm/i915/guc: Check for ct enabled while waiting for response
Date: Mon, 25 Jul 2022 11:18:40 -0700 [thread overview]
Message-ID: <87k081ginz.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20220715211313.143645-1-zhanjun.dong@intel.com>
On Fri, 15 Jul 2022 14:13:13 -0700, Zhanjun Dong wrote:
>
> -static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> +static int wait_for_ct_request_update(struct intel_guc_ct *ct, struct ct_request *req, u32 *status)
> {
> int err;
> + bool ct_enabled;
>
> /*
> * Fast commands should complete in less than 10us, so sample quickly
> @@ -481,12 +483,15 @@ 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)) == \
> + (!(ct_enabled = 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 (!ct_enabled)
> + err = -ENODEV;
Good, -ENODEV seems to be the correct return value in this case.
>
> *status = req->status;
> return err;
> @@ -703,11 +708,18 @@ static int ct_send(struct intel_guc_ct *ct,
>
> intel_guc_notify(ct_to_guc(ct));
>
> - err = wait_for_ct_request_update(&request, status);
> + err = wait_for_ct_request_update(ct, &request, status);
> g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
> if (unlikely(err)) {
> - CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> - action[0], request.fence);
> + if (err == -ENODEV)
> + /* wait_for_ct_request_update returns -ENODEV on reset/suspend in progress.
> + * In this case, output is debug rather than error info
> + */
> + CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB is disabled\n",
> + action[0], request.fence);
> + else
> + CT_ERROR(ct, "No response for request %#x (fence %u)\n",
> + action[0], request.fence);
A nit but I would probably prefer to move the CT_DEBUG() inside
wait_for_ct_request_update() (so we only keep 'if (err != -ENODEV)' checks
here) though it would mean adding the action argument also to
wait_for_ct_request_update().
In any case, since we have discussed this patch ad nauseam previously, this
is now:
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
next prev parent reply other threads:[~2022-07-25 18:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 21:13 [Intel-gfx] [PATCH] drm/i915/guc: Check for ct enabled while waiting for response Zhanjun Dong
2022-07-15 21:13 ` Zhanjun Dong
2022-07-16 17:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Check for ct enabled while waiting for response (rev2) Patchwork
2022-07-16 20:59 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-07-22 16:47 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Check for ct enabled while waiting for response (rev3) Patchwork
2022-07-22 19:25 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-07-25 18:18 ` Dixit, Ashutosh [this message]
2022-07-25 18:18 ` [PATCH] drm/i915/guc: Check for ct enabled while waiting for response Dixit, Ashutosh
-- strict thread matches above, loose matches on Subject: below --
2022-06-16 22:01 [Intel-gfx] " Zhanjun Dong
2022-06-17 4:42 ` Dixit, Ashutosh
2022-06-17 4:42 ` Dixit, Ashutosh
2022-06-17 4:50 ` Dixit, Ashutosh
2022-07-12 19:47 ` Dixit, Ashutosh
2022-07-13 21:45 ` Dong, Zhanjun
2022-07-13 21:45 ` Dong, Zhanjun
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=87k081ginz.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@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.