public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: "Singh, Satyeshwar" <satyeshwar.singh@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt
Date: Tue, 12 Jun 2012 12:58:20 +0100	[thread overview]
Message-ID: <1339502305_11172@CP5-2952> (raw)
In-Reply-To: <95427A2E42F76A40B7520C17720417F00F36060A@FMSMSX102.amr.corp.intel.com>

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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2012-06-12 11:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 15:07 [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt Daniel Vetter
2012-06-11 15:35 ` Ville Syrjälä
2012-06-11 16:13   ` Daniel Vetter
2012-06-11 16:28     ` Daniel Vetter
2012-06-11 23:43       ` Ben Widawsky
2012-06-12  8:12         ` Daniel Vetter
2012-06-12  8:24         ` Daniel Vetter
2012-06-12  8:43           ` Daniel Vetter
2012-06-12  9:28           ` Daniel Vetter
2012-06-12 11:43             ` Singh, Satyeshwar
2012-06-12 11:58               ` Chris Wilson [this message]
2012-06-12 12:16                 ` Daniel Vetter
2012-06-13 11:30             ` Daniel Vetter
2012-06-12  8:52       ` Chris Wilson
2012-06-11 15:58 ` Jani Nikula
  -- strict thread matches above, loose matches on Subject: below --
2012-07-01 15:09 Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1339502305_11172@CP5-2952 \
    --to=chris@chris-wilson.co.uk \
    --cc=ben@bwidawsk.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=satyeshwar.singh@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox