From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 07/11] drm/i915: Tidy i915_gem_suspend()
Date: Tue, 10 Jul 2018 13:01:41 +0300 [thread overview]
Message-ID: <87zhyzs92y.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20180709130208.11730-7-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> In the next patch, we will make a fairly minor change to flush
> outstanding resets before suspend. In order to keep churn to a minimum
> in that functional patch, we fix up the comments and coding style now.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 50 +++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b730a53b426b..6a1bb88b5730 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5029,32 +5029,32 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
> mutex_unlock(&i915->drm.struct_mutex);
> }
>
> -int i915_gem_suspend(struct drm_i915_private *dev_priv)
> +int i915_gem_suspend(struct drm_i915_private *i915)
> {
> - struct drm_device *dev = &dev_priv->drm;
> int ret;
>
> GEM_TRACE("\n");
>
> - intel_runtime_pm_get(dev_priv);
> - intel_suspend_gt_powersave(dev_priv);
> + intel_runtime_pm_get(i915);
> + intel_suspend_gt_powersave(i915);
>
> - mutex_lock(&dev->struct_mutex);
> + mutex_lock(&i915->drm.struct_mutex);
>
> - /* We have to flush all the executing contexts to main memory so
> + /*
> + * We have to flush all the executing contexts to main memory so
> * that they can saved in the hibernation image. To ensure the last
> * context image is coherent, we have to switch away from it. That
> - * leaves the dev_priv->kernel_context still active when
> + * leaves the i915->kernel_context still active when
> * we actually suspend, and its image in memory may not match the GPU
> * state. Fortunately, the kernel_context is disposable and we do
> * not rely on its state.
> */
> - if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
> - ret = i915_gem_switch_to_kernel_context(dev_priv);
> + if (!i915_terminally_wedged(&i915->gpu_error)) {
> + ret = i915_gem_switch_to_kernel_context(i915);
> if (ret)
> goto err_unlock;
>
> - ret = i915_gem_wait_for_idle(dev_priv,
> + ret = i915_gem_wait_for_idle(i915,
> I915_WAIT_INTERRUPTIBLE |
> I915_WAIT_LOCKED |
> I915_WAIT_FOR_IDLE_BOOST,
> @@ -5062,33 +5062,35 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
> if (ret && ret != -EIO)
> goto err_unlock;
>
> - assert_kernel_context_is_current(dev_priv);
> + assert_kernel_context_is_current(i915);
> }
> - mutex_unlock(&dev->struct_mutex);
> + mutex_unlock(&i915->drm.struct_mutex);
>
> - intel_uc_suspend(dev_priv);
> + intel_uc_suspend(i915);
>
> - cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
> - cancel_delayed_work_sync(&dev_priv->gt.retire_work);
> + cancel_delayed_work_sync(&i915->gpu_error.hangcheck_work);
> + cancel_delayed_work_sync(&i915->gt.retire_work);
>
> - /* As the idle_work is rearming if it detects a race, play safe and
> + /*
> + * As the idle_work is rearming if it detects a race, play safe and
> * repeat the flush until it is definitely idle.
> */
> - drain_delayed_work(&dev_priv->gt.idle_work);
> + drain_delayed_work(&i915->gt.idle_work);
>
> - /* Assert that we sucessfully flushed all the work and
> + /*
> + * Assert that we successfully flushed all the work and
> * reset the GPU back to its idle, low power state.
> */
> - WARN_ON(dev_priv->gt.awake);
> - if (WARN_ON(!intel_engines_are_idle(dev_priv)))
> - i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
> + WARN_ON(i915->gt.awake);
> + if (WARN_ON(!intel_engines_are_idle(i915)))
> + i915_gem_set_wedged(i915); /* no hope, discard everything */
>
> - intel_runtime_pm_put(dev_priv);
> + intel_runtime_pm_put(i915);
> return 0;
>
> err_unlock:
> - mutex_unlock(&dev->struct_mutex);
> - intel_runtime_pm_put(dev_priv);
> + mutex_unlock(&i915->drm.struct_mutex);
> + intel_runtime_pm_put(i915);
> return ret;
> }
>
> --
> 2.18.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-07-10 10:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 13:01 [PATCH 01/11] drm/i915/selftests: Prevent background reaping of active objects Chris Wilson
2018-07-09 13:01 ` [PATCH 02/11] drm/i915: Only reset hangcheck at the start of an activity cycle Chris Wilson
2018-07-09 14:13 ` Mika Kuoppala
2018-07-09 14:27 ` Chris Wilson
2018-07-09 14:35 ` Mika Kuoppala
2018-07-09 13:02 ` [PATCH 03/11] drm/i915: Stop tracking MRU activity on VMA Chris Wilson
2018-07-10 12:19 ` Tvrtko Ursulin
2018-07-10 12:37 ` Chris Wilson
2018-07-10 16:01 ` Tvrtko Ursulin
2018-07-09 13:02 ` [PATCH 04/11] drm/i915: Introduce i915_address_space.mutex Chris Wilson
2018-07-09 13:02 ` [PATCH 05/11] drm/i915: Move fence register tracking to GGTT Chris Wilson
2018-07-09 13:02 ` [PATCH 06/11] drm/i915: Convert fences to use a GGTT lock rather than struct_mutex Chris Wilson
2018-07-09 13:02 ` [PATCH 07/11] drm/i915: Tidy i915_gem_suspend() Chris Wilson
2018-07-10 10:01 ` Mika Kuoppala [this message]
2018-07-09 13:02 ` [PATCH 08/11] drm/i915: Move fence-reg interface to i915_gem_fence_reg.h Chris Wilson
2018-07-10 10:02 ` Mika Kuoppala
2018-07-09 13:02 ` [PATCH 09/11] drm/i915: Dynamically allocate the array of drm_i915_gem_fence_reg Chris Wilson
2018-07-09 13:02 ` [PATCH 10/11] drm/i915: Pull all the reset functionality together into i915_reset.c Chris Wilson
2018-07-09 13:02 ` [PATCH 11/11] drm/i915: Remove GPU reset dependence on struct_mutex Chris Wilson
2018-07-09 13:38 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/selftests: Prevent background reaping of active objects Patchwork
2018-07-09 13:43 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-07-09 13:48 ` [PATCH 01/11] " Mika Kuoppala
2018-07-09 13:54 ` Chris Wilson
2018-07-09 13:53 ` ✓ Fi.CI.BAT: success for series starting with [01/11] " Patchwork
2018-07-09 19:12 ` ✗ Fi.CI.IGT: 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=87zhyzs92y.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--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 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.