aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2016-11-07 06:01:28 -0500
committerChris Wilson <chris@chris-wilson.co.uk>2016-11-07 07:25:50 -0500
commit767a222e47cc13239d38018887f911fec06169ea (patch)
tree3884ab422df685233236e4857046368872cbf61b
parent0ef723cbceb6dce8116e75d44c5b8679b2eba69a (diff)
drm/i915: Limit Valleyview and earlier to only using mappable scanout
Valleyview appears to be limited to only scanning out from the first 512MiB of the Global GTT. Lets presume that this behaviour was inherited from the display block copied from g4x (not Ironlake) and all earlier generations are similarly affected, though testing suggests different symptoms. For simplicity, impose that these platforms must scanout from the mappable region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this catches Cherryview which does not appear to be limited to the low aperture for its scanout.) v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about limiting this workaround to the old style of display engine. v3: Update changelog to reflect testing by Ville Syrjälä v4: Include the changes to the comments as well Reported-by: Luis Botello <luis.botello.ortega@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036 Fixes: 2efb813d5388 ("drm/i915: Fallback to using unmappable memory for scanout") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Akash Goel <akash.goel@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20161107110128.28762-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com
-rw-r--r--drivers/gpu/drm/i915/i915_gem.c18
1 files changed, 16 insertions, 2 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33445ffba2c0..490fd302bd1a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3608,8 +3608,22 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
3608 if (view->type == I915_GGTT_VIEW_NORMAL) 3608 if (view->type == I915_GGTT_VIEW_NORMAL)
3609 vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, 3609 vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
3610 PIN_MAPPABLE | PIN_NONBLOCK); 3610 PIN_MAPPABLE | PIN_NONBLOCK);
3611 if (IS_ERR(vma)) 3611 if (IS_ERR(vma)) {
3612 vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, 0); 3612 struct drm_i915_private *i915 = to_i915(obj->base.dev);
3613 unsigned int flags;
3614
3615 /* Valleyview is definitely limited to scanning out the first
3616 * 512MiB. Lets presume this behaviour was inherited from the
3617 * g4x display engine and that all earlier gen are similarly
3618 * limited. Testing suggests that it is a little more
3619 * complicated than this. For example, Cherryview appears quite
3620 * happy to scanout from anywhere within its global aperture.
3621 */
3622 flags = 0;
3623 if (HAS_GMCH_DISPLAY(i915))
3624 flags = PIN_MAPPABLE;
3625 vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
3626 }
3613 if (IS_ERR(vma)) 3627 if (IS_ERR(vma))
3614 goto err_unpin_display; 3628 goto err_unpin_display;
3615 3629