[Intel-gfx] [PATCH] i915: suspend/resume GEM when KMS is active

[Jesse Barnes]

On Wednesday, February 18, 2009 3:23 am Dave Airlie wrote:
> On Wed, Feb 18, 2009 at 10:56 AM, Jesse Barnes <jbarnes at virtuousgeek.org> 
wrote:
> > On Tuesday, February 17, 2009 4:30 pm Dave Airlie wrote:
> >> On Wed, Feb 18, 2009 at 9:54 AM, Eric Anholt <eric at anholt.net> wrote:
> >> > On Tue, 2009-02-17 at 15:36 -0800, Jesse Barnes wrote:
> >> >> On Tuesday, February 17, 2009 3:13 pm Jesse Barnes wrote:
> >> >> > In the KMS case, we need to suspend/resume GEM as well.  So on
> >> >> > suspend, make sure we idle GEM and stop any new rendering from
> >> >> > coming in, and on resume, re-init the framebuffer and clear the
> >> >> > suspended flag.
> >> >> >
> >> >> > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> >> >>
> >> >> Oops should have included the IRQ bits as well.  We need to do this t
> >> >> properly tear down vblank state and make sure no interrupts come in
> >> >> either after suspend or before resume while the machine is still
> >> >> running.
> >> >>
> >> >> Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> >> >
> >> > Could we please create a new i915_gem_idle()-like path for the suspend
> >> > that actually waits, instead of spinning for a short while and giving
> >> > up?  I'd really like the BUG_ON from the timeout in that function (the
> >> > timeout being there to handle exiting your hung X Server) to stay out
> >> > of KMS.
> >>
> >> Please don't wait forever, give up after a while, and don't BUG_ON in
> >> the suspend path
> >> no-one will ever see it.
> >
> > Yeah we'll want to note the hang, and maybe abort the suspend, but
> > definitely not wait forever.
>
> aborting suspend is also not the answer, laptop close + shove in bag
> scenario.

Well then neither is spinning forever, so we're stuck with the current timeout 
loop.  But I don't see a BUG_ON in that path, just a bunch of WARN_ONs, so 
maybe the last patch is ok.

Jesse

-- 
Jesse Barnes, Intel Open Source Technology Center