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. -Chris -- Chris Wilson, Intel Open Source Technology Centre
