On Tue, 12 Apr 2011 18:06:51 +0100 Chris Wilson <[email protected]> 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 <[email protected]> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796 > Signed-off-by: Chris Wilson <[email protected]> > Cc: [email protected] > --- 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. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
