[Intel-gfx] Doing restore by setting modes

[Jesse Barnes]

On Sun, 10 May 2009 16:23:32 +1000
Dave Airlie <airlied at gmail.com> wrote:

> On Sun, May 10, 2009 at 10:15 AM, Jesse Barnes
> <jbarnes at virtuousgeek.org> wrote:
> > On Sat, 09 May 2009 15:10:00 -0700
> > Keith Packard <keithp at keithp.com> wrote:
> >
> >> I'm having trouble with Display Port suspend/resume -- configuring
> >> the output is fairly tricky and depends on doing things in the
> >> right order at the right time. At this point, on resume, the
> >> display refuses to re-train, so you're left with a black screen.
> >> Setting the screen to a different mode and back to the preferred
> >> mode fixes it, unlike everything else I've tried (including
> >> turning it off and back on).
> >>
> >> I'm wondering if we shouldn't just bail on much of the
> >> suspend/resume code and have resume just re-configure outputs
> >> using the existing output configuration code. Seems like that
> >> would result in less code and fewer inconsistencies between the
> >> resume and normal modeset paths.
> >
> > Yeah, that's been on the TODO list for awhile now.  Though I think
> > we may need to keep the current code for non-KMS configs.
> >
> > We'll also need to keep around a chunk of register save/restore for
> > the global, non-mode setting related state, but that should be
> > fairly small compared to all the mode stuff.
> >
> > The KMS save/restore could probably be generic too; we just need to
> > save the current mode_config and re-apply it at resume time.
> >
> 
> Code should already be there.
> 
> radeon works like that, there is a helper fn for forcing the modeset.

I only looked briefly, but it appeared we only tracked the kernel fb
config, not the last user config.  So yes the code to set the modes is
there but we don't track the user config across suspend/resume afaik.

-- 
Jesse Barnes, Intel Open Source Technology Center