From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt Date: Tue, 12 Jun 2012 14:16:45 +0200 Message-ID: <20120612121645.GA20807@phenom.ffwll.local> References: <1339489445-29108-1-git-send-email-daniel.vetter@ffwll.ch> <1339493297-23829-1-git-send-email-daniel.vetter@ffwll.ch> <95427A2E42F76A40B7520C17720417F00F36060A@FMSMSX102.amr.corp.intel.com> <1339502305_11172@CP5-2952> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by gabe.freedesktop.org (Postfix) with ESMTP id B1C799E7BC for ; Tue, 12 Jun 2012 05:17:10 -0700 (PDT) Received: by bkwj4 with SMTP id j4so5538304bkw.36 for ; Tue, 12 Jun 2012 05:17:09 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1339502305_11172@CP5-2952> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: Intel Graphics Development , Ben Widawsky , Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Tue, Jun 12, 2012 at 12:58:20PM +0100, Chris Wilson wrote: > On Tue, 12 Jun 2012 11:43:50 +0000, "Singh, Satyeshwar" 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