drm/i915: don't use the first stolen page on Broadwell

The spec says we just can't use it.

v2:
  - Add WA name (Ville).
  - Add a big comment explaining that we still didn't fix the problem
    where we inherit a framebuffer on the first page (Chris, Ville).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
Paulo Zanoni 2015-09-23 12:52:22 -03:00 committed by Daniel Vetter
parent b26d3ea323
commit 1ca36d4cb3

View file

@ -51,6 +51,11 @@ int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *dev_priv,
if (!drm_mm_initialized(&dev_priv->mm.stolen))
return -ENODEV;
/* See the comment at the drm_mm_init() call for more about this check.
* WaSkipStolenMemoryFirstPage:bdw,chv (incomplete) */
if (INTEL_INFO(dev_priv)->gen == 8 && start < 4096)
start = 4096;
mutex_lock(&dev_priv->mm.stolen_lock);
ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, node, size,
alignment, start, end,
@ -393,7 +398,17 @@ int i915_gem_init_stolen(struct drm_device *dev)
dev_priv->gtt.stolen_usable_size = dev_priv->gtt.stolen_size -
reserved_total;
/* Basic memrange allocator for stolen space */
/*
* Basic memrange allocator for stolen space.
*
* TODO: Notice that some platforms require us to not use the first page
* of the stolen memory but their BIOSes may still put the framebuffer
* on the first page. So we don't reserve this page for now because of
* that. Our current solution is to just prevent new nodes from being
* inserted on the first page - see the check we have at
* i915_gem_stolen_insert_node_in_range(). We may want to fix the fbcon
* problem later.
*/
drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_usable_size);
return 0;