Re: [PATCH] drm/i915: Sanitize the output registers after resume

[Chris Wilson <chris@chris-wilson.co.uk>]

On Tue, 12 Apr 2011 17:00:05 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Tue, 12 Apr 2011 18:06:51 +0100
> Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 
> > Similar to booting, we need to inspect the state left by the BIOS and
> > remove any conflicting bits before we take over. The example reported by
> > Seth Forshee is very similar to the bug we encountered with the state left
> > by grub2, that the crtc pipe<->planning mapping was reversed from our
> > expectations and so we failed to turn off the outputs when booting or,
> > in this case, resuming. This may be in fact the same bug, but triggered
> > at resume time.
> > 
> > This patch rearranges the code we already have to clear up the
> > conflicting state upon init and calls it from reset (which is called
> > after we have lost control of the hardware, i.e. along both the boot and
> > resume paths) instead.
> > 
> > Reported-and-tested-by: Seth Forshee <seth.forshee@canonical.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: stable@kernel.org
> > ---
> 
> It's a bigger change, but I'd really rather we have functions to probe
> the existing config and copy it into our mode config structures.  That
> way we can re-use the code to minimize flicker and transitions, and
> potentially just leave things alone if the config is valid (it should
> be since the BIOS provided it) and we just need to switch the fb around
> or disable VGA.

On the one hand, we should just be able to trust a BIOS config, right? On
the other hand did you just see what that BIOS did to Sitosfe's machine?
Or the PGTBL_ERs it generates on other machines?

Though we can reduce this particular issue by aligning ourselves better
with the state left by the BIOS, I don't think we can lose a function
whose job it is to make sure that the hw state is consistent with KMS. And
that function needs to be called whenever we takeover from the BIOS -
which is the purpose of this patch.

At the moment, we have a real problem where outputs are continuing to use
GTT as we rewrite it from underneath them. The simplest solution for that
is to disable the outputs right at the start. The next step is then to
recreate the GEM and KMS state currently occupied by the BIOS and preserve
that across the takeover.  So yes, to do it completely flicker free is a
much harder job.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre