[Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

[Ville Syrjälä]

On Fri, May 20, 2016 at 04:06:17PM +0300, David Weinehall wrote:
> On Sat, May 07, 2016 at 09:18:24PM +0300, Ville Syrjälä wrote:
> > On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> > > On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrjala at linux.intel.com wrote:
> > > > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
> > > >  static int i915_drm_resume(struct drm_device *dev)
> > > >  {
> > > >  	struct drm_i915_private *dev_priv = dev->dev_private;
> > > > +	int ret;
> > > >  
> > > >  	disable_rpm_wakeref_asserts(dev_priv);
> > > >  
> > > > +	ret = i915_ggtt_enable_hw(dev);
> > > > +	if (ret)
> > > > +		DRM_ERROR("failed to re-enable GGTT\n");
> > > 
> > > Would it not be fatal for resume as well? Failure means we can't use the
> > > GGTT, so all subsequent writes will be going into a random address.
> > 
> > Yeah, I assume things would blow up. The question is however, what can
> > we do in this case? We'd basically have to shut the entire driver down.
> > I don't think we have a way to do that?
> 
> panic() seems like the answer here.  If we risk scribbling into
> random memory we should make sure that we just drop everything.

Yeah, maybe. OTOH I really hate it when resume gives you hung machine, a
bit of memory corruption might be preferable. I wonder if we could
force a remount-ro for all disks to at least avoid scribbling over
anything permanently. But this might all be entirely theoretical, and
this will never happen. The fake agp code just ignored the return value
and peopled seemed happy.

-- 
Ville Syrjälä
Intel OTC