stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix init_clock_gating for resume
Date: Mon, 13 Nov 2017 22:46:10 +0200	[thread overview]
Message-ID: <20171113204610.GX10981@intel.com> (raw)
In-Reply-To: <20171113190131.t4673jf5mbokqe22@intel.com>

On Mon, Nov 13, 2017 at 11:01:31AM -0800, Rodrigo Vivi wrote:
> On Mon, Nov 13, 2017 at 02:50:28PM +0000, Ville Syrjala wrote:
> > From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > 
> > Moving the init_clock_gating() call from intel_modeset_init_hw() to
> > intel_modeset_gem_init() had an unintended effect of not applying
> > some workarounds on resume. This, for example, cause some kind of
> > corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS
> > screen after hibernation. Fix the problem by explicitly calling
> > init_clock_gating() from the resume path.
> > 
> > I really hope this doesn't break something else again...
> > 
> > Cc: stable@vger.kernel.org
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was")
> > Signed-off-by: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index 9df7b5d59a94..0023fb17899f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1707,6 +1707,7 @@ static int i915_drm_resume(struct drm_device *dev)
> >  
> >  	intel_guc_resume(dev_priv);
> >  
> > +	intel_init_clock_gating(dev_priv);
> >  	intel_modeset_init_hw(dev);
> 
> Few questions:
> 
> Any reason why here we have it before init_hw while on finish_reset
> we have it after init_hw?

Just me being lazy and not checking where I put it in the display reset
path.

> 
> Also, what about the case on modeset_init? Do we need there?
> If yes, shouldn't we move the call entirely to intel-modeset_init_hw?

I moved it there in commit b7048ea12fbb ("drm/i915: Do
.init_clock_gating() earlier to avoid it clobbering watermarks")
but that broke some GT workarounds, hence I had to move it back to
somewhere later in commit 6ac43272768c ("drm/i915: Move init_clock_gating()
back to where it was"). And that in turn broke my IVB LVDS :(

It's rather hard to win here.

> 
> Also, do we still need now the call on vlv_resume_prepare?
> and on i915_gem_init?

gem_init() yes. The vlv_resume_prepare() not sure. The theory there
seems to be that on VLV the settings can get clobbered by a runtime
suspend. Whereas with other platforms we seem to be assuming that
they're preserved.

Whether that's what really happens I'm not 100% sure. I think it may
very well be that VLV does lose a bunch of things in S0ix. We even have
that vlv_{save,restore}_gunit_s0ix_state() thing to avoid some other
things getting lost. CHV added a save/restore engine of some sort
that should take care of more things automagically, so not sure if
it actually needs the init_clock_gating either. OTOH maybe we should
just start playing it safe an do the init_clock_gating() unconditionally
in runtime resume? We already seem to be doing that with init_swizzle().

-- 
Ville Syrj�l�
Intel OTC

  reply	other threads:[~2017-11-13 20:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 14:50 [PATCH] drm/i915: Fix init_clock_gating for resume Ville Syrjala
2017-11-13 19:01 ` [Intel-gfx] " Rodrigo Vivi
2017-11-13 20:46   ` Ville Syrjälä [this message]
2017-11-13 21:01     ` Rodrigo Vivi
2017-11-16 16:02 ` [PATCH v2] " Ville Syrjala
2017-11-16 16:14   ` Chris Wilson
2017-11-20 13:02     ` Ville Syrjälä

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=20171113204610.GX10981@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).