On Mon, Mar 18, 2013 at 6:42 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote: > On Mon, 18 Mar 2013 08:49:07 +0100 > Daniel Vetter <daniel at ffwll.ch> wrote: > >> On Tue, Feb 19, 2013 at 12:11:41PM -0800, Jesse Barnes wrote: >> > With the other bits in place, we can do this safely. >> > >> > v2: disable backlight on suspend to prevent premature enablement on resume >> > >> > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org> >> > --- >> > drivers/gpu/drm/i915/i915_drv.c | 12 +++++++++--- >> > drivers/gpu/drm/i915/intel_fb.c | 3 +++ >> > 2 files changed, 12 insertions(+), 3 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c >> > index c5b8c81..e76b038 100644 >> > --- a/drivers/gpu/drm/i915/i915_drv.c >> > +++ b/drivers/gpu/drm/i915/i915_drv.c >> > @@ -492,9 +492,10 @@ static int i915_drm_freeze(struct drm_device *dev) >> > >> > cancel_delayed_work_sync(&dev_priv->rps.delayed_resume_work); >> > >> > - intel_modeset_disable(dev); >> >> As discussed in person last week, simply dropping this will probably kill >> S0i3 support. > > Not really, since DPMS will be off in that case too generally, but it > does make testing harder. Hm, where do we do that currently? Without fbcon I don't see it, and we can't really rely on userspace to get this right I guess ... > I think it just needs to be a low level call to crtc disable on each > pipe, otherwise we'll zap the state we're trying to save. That just reminded me that we also should restore the right dpms state I think. At least I'm not too sure whether we'll currently do that (and whether the modeset state tracker would catch it). Otoh dpms standby/suspend died with gen4 ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
