From: Imre Deak <imre.deak@intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH] drm/i915: run intel_uncore_early_sanitize earlier on resume on non-VLV
Date: Mon, 20 Oct 2014 13:20:50 +0300 [thread overview]
Message-ID: <1413800450.18095.16.camel@intelbox> (raw)
In-Reply-To: <1413572490-2129-1-git-send-email-przanoni@gmail.com>
On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> As far as I understand, intel_uncore_early_sanitize() was supposed to
> be ran before any register access, but currently
> intel_resume_prepare() is ran earlier, and it does register
> access. I don't think it should be safe to be calling
> I915_{READ,WRITE} without calling intel_uncore_early_sanitize() first.
>
> One of the problems we currently have is that when we suspend/resume
> BDW, the FPGA_DBG_RM_NOCLAIM bit becomes 1, so we end up printing an
> "unclaimed register" message on resume, but this message doesn't
> really seem to have been triggered by our driver or user space, since
> the bit was not there before suspending, and gets there just after
> resuming, before any of our own register accesses. So calling
> intel_uncore_early_sanitize() as a first thing will allow us to stop
> printing the error message, fixing the "bug".
>
> v2: VLV is an exception to the early_sanitize() rule: it needs to do
> stuff before calling early_sanitize(), so instead of calling it
> earlier for every platform, we call it earlier for non-VLV by adding
> the early_sanitize() call inside intel_resume_prepare(). This doesn't
> look like the most-beautiful-solution-ever, but, well, at least it
> fixes the bug. (Imre)
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Imre Deak <imre.deak@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83094
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a05a1d0..f6d28f2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -669,7 +669,6 @@ static int i915_drm_thaw_early(struct drm_device *dev)
> if (ret)
> DRM_ERROR("Resume prepare failed: %d,Continuing resume\n", ret);
>
> - intel_uncore_early_sanitize(dev, true);
> intel_uncore_sanitize(dev);
> intel_power_domains_init_hw(dev_priv);
>
> @@ -1049,6 +1048,8 @@ static int snb_resume_prepare(struct drm_i915_private *dev_priv,
>
> if (rpm_resume)
> intel_init_pch_refclk(dev);
> + else
> + intel_uncore_early_sanitize(dev, true);
>
> return 0;
> }
> @@ -1056,6 +1057,9 @@ static int snb_resume_prepare(struct drm_i915_private *dev_priv,
> static int hsw_resume_prepare(struct drm_i915_private *dev_priv,
> bool rpm_resume)
> {
> + if (!rpm_resume)
> + intel_uncore_early_sanitize(dev_priv->dev, true);
> +
> hsw_disable_pc8(dev_priv);
>
> return 0;
> @@ -1421,6 +1425,9 @@ static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
> i915_gem_restore_fences(dev);
> }
>
> + if (!rpm_resume)
> + intel_uncore_early_sanitize(dev, true);
> +
> return ret;
> }
>
You also need to call intel_uncore_early_sanitize() from
intel_resume_prepare() for the rest of the platforms. With that fixed:
Reviewed-by: Imre Deak <imre.deak@intel.com>
Looking at the result, I agree it's not the nicest, so yet another way
to reduce the clutter would be to have the following instead in
i915_drm_thaw_early():
intel_resume_early_prepare()
intel_uncore_early_sanitize()
intel_resume_prepare()
and do the early steps for VLV in intel_resume_early_prepare(). I'm ok
with both solutions.
--Imre
next prev parent reply other threads:[~2014-10-20 10:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-17 19:01 [PATCH] drm/i915: run intel_uncore_early_sanitize earlier on resume on non-VLV Paulo Zanoni
2014-10-20 10:20 ` Imre Deak [this message]
2014-10-21 17:05 ` Daniel Vetter
2014-10-22 11:20 ` Imre Deak
2014-10-22 19:01 ` Paulo Zanoni
2014-10-23 10:56 ` [PATCH 1/2] drm/i915: kill intel_resume_prepare() Paulo Zanoni
2014-10-23 10:56 ` [PATCH 2/2] drm/i915: run hsw_disable_pc8() later on resume Paulo Zanoni
2014-10-23 12:13 ` Daniel Vetter
2014-10-27 19:54 ` [PATCH 1/2] drm/i915: kill intel_resume_prepare() Paulo Zanoni
2014-10-27 19:54 ` [PATCH 2/2] drm/i915: run hsw_disable_pc8() later on resume Paulo Zanoni
2014-10-28 13:12 ` [PATCH 1/2] drm/i915: kill intel_resume_prepare() Imre Deak
2014-10-28 13:43 ` Paulo Zanoni
2014-10-28 14:47 ` Imre Deak
2014-11-03 11:13 ` Daniel Vetter
2014-10-23 12:16 ` [PATCH] drm/i915: run intel_uncore_early_sanitize earlier on resume on non-VLV Daniel Vetter
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=1413800450.18095.16.camel@intelbox \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=przanoni@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox