On Tue, Mar 19, 2013 at 06:13:09PM +0100, Daniel Vetter wrote: > On Tue, Mar 19, 2013 at 5:56 PM, Jesse Barnes <jbar...@virtuousgeek.org> > wrote: > >> > 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 ;-) > > > > Hm yeah haven't tested that at all. One typical kind of suspend will > > happen after DPMS off when the machine has been idle for some period. > > When it comes back up the user will probably want to see the display. > > But we don't have to enforce that on the kernel side; we can leave it > > to userspace. > > Note that this isn't about dpms state in general, we'll take care of > that. The problem is with intermediate dpms levels, which requires us > to keep the pipe partially running. If you force-restore such a thing > we'll end up at dpms ON. Which isn't quite what we want. > > Otoh it's old hw, so I don't think we need to spill too many brain > cycles on this issue. But if we do fix it, I think we should implement > proper support to read out that hw state and cross-check it - > otherwise it's pretty much guaranteed to be broken.
Ajax just submitted a patch to fix restoring of intermediate dpms levels, so we should be good here. Another idea for safe/restore around suspend which should just work is loop over all connectors and adjust the dpms state (and safe just that piece somewhere). That way we get nice implicit coverag of our dpms code while doing suspends and suspend doesn't need anything in addition infrastructure wise. The only downside is that we need to make the power wells stuff work with dpms, too. But that's a requirement, anyway. Now the real reason for writing this mail: 3.10 feature merge is drawing to a close (in about a month I think) and imo we should get switchless resume in a few weeks ahead. That way we can give it a decent beating before it reaches Linus' upstream git. And I like switchless resume a lot. So what's your plan here? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
