From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete
Date: Fri, 7 Apr 2023 07:04:06 -0400 [thread overview]
Message-ID: <ZC/4puC4sAanEGjE@intel.com> (raw)
In-Reply-To: <20230406044522.3108359-4-ashutosh.dixit@intel.com>
On Wed, Apr 05, 2023 at 09:45:22PM -0700, Ashutosh Dixit wrote:
> Instead of erroring out when GuC reset is in progress, block waiting for
> GuC reset to complete which is a more reasonable uapi behavior.
>
> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9ab8971679fe3..4343efb48e61b 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -51,6 +51,7 @@ struct hwm_drvdata {
> char name[12];
> int gt_n;
> bool reset_in_progress;
> + wait_queue_head_t wqh;
> };
>
> struct i915_hwmon {
> @@ -400,10 +401,15 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> int ret = 0;
> u32 nval;
>
> +retry:
> mutex_lock(&hwmon->hwmon_lock);
> if (hwmon->ddat.reset_in_progress) {
> - ret = -EAGAIN;
> - goto unlock;
> + mutex_unlock(&hwmon->hwmon_lock);
> + ret = wait_event_interruptible(ddat->wqh,
> + !hwmon->ddat.reset_in_progress);
this is indeed very clever!
maybe just use the timeout version to be on the safeside and then return the
-EAGAIN on timeout?
my fear is probably due to the lack of knowledge on this wait queue, but
I'm wondering what could go wrong if due to some funny race you enter this
check right after wake_up_all below has passed and then you will be here
indefinitely waiting...
> + if (ret)
> + return ret;
> + goto retry;
> }
> wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
>
> @@ -426,7 +432,6 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, nval);
> exit:
> intel_runtime_pm_put(ddat->uncore->rpm, wakeref);
> -unlock:
> mutex_unlock(&hwmon->hwmon_lock);
> return ret;
> }
> @@ -508,6 +513,7 @@ void i915_hwmon_power_max_restore(struct drm_i915_private *i915, bool old)
> intel_uncore_rmw(hwmon->ddat.uncore, hwmon->rg.pkg_rapl_limit,
> PKG_PWR_LIM_1_EN, old ? PKG_PWR_LIM_1_EN : 0);
> hwmon->ddat.reset_in_progress = false;
> + wake_up_all(&hwmon->ddat.wqh);
>
> mutex_unlock(&hwmon->hwmon_lock);
> }
> @@ -784,6 +790,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> ddat->uncore = &i915->uncore;
> snprintf(ddat->name, sizeof(ddat->name), "i915");
> ddat->gt_n = -1;
> + init_waitqueue_head(&ddat->wqh);
>
> for_each_gt(gt, i915, i) {
> ddat_gt = hwmon->ddat_gt + i;
> --
> 2.38.0
>
next prev parent reply other threads:[~2023-04-07 11:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 4:45 [Intel-gfx] [PATCH v4 0/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware Ashutosh Dixit
2023-04-06 4:45 ` [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write Ashutosh Dixit
2023-04-07 11:08 ` Rodrigo Vivi
2023-04-06 4:45 ` [Intel-gfx] [PATCH 2/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware Ashutosh Dixit
2023-04-06 9:16 ` kernel test robot
2023-04-07 11:08 ` Rodrigo Vivi
2023-04-10 22:17 ` Dixit, Ashutosh
2023-04-06 4:45 ` [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete Ashutosh Dixit
2023-04-07 11:04 ` Rodrigo Vivi [this message]
2023-04-10 22:40 ` Dixit, Ashutosh
2023-04-06 5:15 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Disable PL1 power limit when loading GuC firmware Patchwork
2023-04-06 5:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-06 17:42 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2023-04-10 22:35 [Intel-gfx] [PATCH 0/3] " Ashutosh Dixit
2023-04-10 22:35 ` [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete Ashutosh Dixit
2023-04-18 5:35 ` Rodrigo Vivi
2023-04-18 17:23 ` Dixit, Ashutosh
2023-04-19 19:40 ` Rodrigo Vivi
2023-04-19 22:13 ` Dixit, Ashutosh
2023-04-20 15:45 ` Rodrigo Vivi
2023-04-19 13:21 ` Tvrtko Ursulin
2023-04-19 22:10 ` Dixit, Ashutosh
2023-04-20 7:57 ` Tvrtko Ursulin
2023-04-20 15:43 ` Rodrigo Vivi
2023-04-20 16:26 ` Dixit, Ashutosh
2023-04-20 16:40 [Intel-gfx] [PATCH v6 0/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware Ashutosh Dixit
2023-04-20 16:40 ` [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete Ashutosh Dixit
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=ZC/4puC4sAanEGjE@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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