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 at 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 at ffwll.ch Mobile: +41 (0)79 365 57 48
