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 Date: Thu, 16 Oct 2014 19:04:23 +0300 Message-ID: <1413475463.11611.13.camel@ideak-mobl> References: <1412876816-2313-1-git-send-email-przanoni@gmail.com> <1412940336.4638.11.camel@intelbox> 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 mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 60F066E2B0 for ; Thu, 16 Oct 2014 09:07:05 -0700 (PDT) In-Reply-To: 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 Graphics Development , Paulo Zanoni List-Id: intel-gfx@lists.freedesktop.org On Wed, 2014-10-15 at 16:07 -0300, Paulo Zanoni wrote: > 2014-10-10 8:25 GMT-03:00 Imre Deak : > > On Thu, 2014-10-09 at 14:46 -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". > > > > One issue is that intel_uncore_early_sanitize() uses forcewake, which is > > enabled only in prepare resume for VLV (vlv_allow_gt_wake()). Maybe > > FPGA_DBG could be reset separately before the rest? > > It doesn't "use" forcewake, it calls intel_uncore_forcewake_reset(). Hm, right I only remembered that because of "drm/i915: check for GT faults during S3 resume and S4 restore too" on the mailing list, but it's not yet merged. > Shouldn't we move the vlv code (e.g., vlv_allow_gt_wake()) to inside > intel_uncore_forcewake_reset() instead? > > To my understanding, it doesn't make sense to call anything at all > before intel_uncore_early_sanitize()... On VLV we need to do the steps in the resume_prepare handler first. Also we don't want to call vlv_allow_gt_wake() during driver init. But yes, I see that for other platforms it makes sense to move intel_uncore_early_sanitize() earlier. One way would be to call it from resume_prepare for each platform at the proper place in case of system resume. > > > >> > >> 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 | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> Maybe we need to move even more code up? > >> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > >> index a05a1d0..dffb173 100644 > >> --- a/drivers/gpu/drm/i915/i915_drv.c > >> +++ b/drivers/gpu/drm/i915/i915_drv.c > >> @@ -665,11 +665,11 @@ static int i915_drm_thaw_early(struct drm_device *dev) > >> struct drm_i915_private *dev_priv = dev->dev_private; > >> int ret; > >> > >> + intel_uncore_early_sanitize(dev, true); > >> ret = intel_resume_prepare(dev_priv, false); > >> 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); > >> > > > > > > >