On Mon, Nov 23, 2015 at 04:10:58PM -0800, Matt Roper wrote: > On Mon, Nov 23, 2015 at 04:53:55PM +0000, Chris Wilson wrote: > > On Mon, Nov 23, 2015 at 08:48:32AM -0800, Matt Roper wrote: > > > If we fail to reconstruct the BIOS fb (e.g., because the FB is too > > > large), we'll be left with plane state that indicates the primary plane > > > is visible yet has a NULL fb. This mismatch causes problems later on > > > (e.g., for the watermark code). Since we've failed to reconstruct the > > > BIOS FB, the best solution is to just disable the primary plane and > > > pretend the BIOS never had it enabled. > > > > > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxx> > > > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > > > > There are a bunch of bugzillas open about this as it is a regression > > from about 3.2. > > -Chris > > > > Do you happen to know any of the bug ID's off the top of your head (or > keywords to look for)? I skimmed through the bug list, but the only one > that jumped out at me as possibly related is > > https://bugs.freedesktop.org/show_bug.cgi?id=91751 > ("Display still active even though primary plane is disabled and kills > the GPU") Errors like https://bugs.freedesktop.org/show_bug.cgi?id=89319 or GPU hangs on takeover like https://bugs.freedesktop.org/show_bug.cgi?id=87677 https://bugs.freedesktop.org/show_bug.cgi?id=89146 https://bugs.freedesktop.org/show_bug.cgi?id=91653 from a quick search -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
