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
next prev parent 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).