Re: [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Jun 12, 2012 at 12:58:20PM +0100, Chris Wilson wrote:
> On Tue, 12 Jun 2012 11:43:50 +0000, "Singh, Satyeshwar" <satyeshwar.singh@intel.com> wrote:
> > Hi,
> > I just want to confirm something here. We have a situation where we draw a splash screen through our firmware's graphics component (UEFI GOP driver) onto its frame buffer which resides in stolen memory. When we transition from firmware to the kernel, we would like to ensure that the same splash screen seamlessly continues to be displayed so we remap the pages from stolen memory into GTT. If we have purged firmware framebuffers before claiming the gtt, then would we have not essentially lost the chance to remap those pages?
> 
> That's a separate issue. What this patch is addressing is removing a
> conflicting fbdev driver. If you have such a driver loaded all bets are
> off concerning the state of memory from the transition of UEFI to KMS
> (rule: don't use more one driver for the same hw). The challenge of
> preserving the contents and mode of UEFI is the task of Jesse's fastboot
> work. As noted elsewhere, using the GOP queries might simplify the task
> of reading back hw state -- except that we need such information anyway
> whether or not we have a UEFI system.

Actually, this patch should also help in kicking the native uefi
framebuffer driver - in case people use such a thing. But otherwise Chris
is right - preserving the existing output state and framebuffer contents
is a fully orthogonal issue. This patch only solves driver arbitrage
within the linux kernel.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48