From mboxrd@z Thu Jan 1 00:00:00 1970 From: Imre Deak 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 Message-ID: <1413800450.18095.16.camel@intelbox> References: <1413572490-2129-1-git-send-email-przanoni@gmail.com> Reply-To: imre.deak@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 82A046E074 for ; Mon, 20 Oct 2014 03:20:54 -0700 (PDT) In-Reply-To: <1413572490-2129-1-git-send-email-przanoni@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Paulo Zanoni Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni List-Id: intel-gfx@lists.freedesktop.org On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > 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 > Cc: Imre Deak > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83094 > Signed-off-by: Paulo Zanoni > --- > 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 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