summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_gem_dmabuf.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2013-03-05 14:52:39 +0000
committerDaniel Vetter <daniel.vetter@ffwll.ch>2013-03-27 17:13:43 +0100
commit693db1842d864ca2771e881127cdb4d09979758b (patch)
treeb937cd3efa7f6c8ca6304f75fbfc0f4054b2ff24 /drivers/gpu/drm/i915/i915_gem_dmabuf.c
parent4f770a5bee04566e63f3a826a15c24bccaa124e8 (diff)
downloadtalos-obmc-linux-693db1842d864ca2771e881127cdb4d09979758b.tar.gz
talos-obmc-linux-693db1842d864ca2771e881127cdb4d09979758b.zip
drm/i915: Apply alignment restrictions on scanout surfaces for VT-d
From the w/a database: 'To prevent false VT-d type 6 error: The primary display plane must be 256KiB aligned, and require an extra 128 PTEs of padding afterward; The sprites planes must be 128KiB aligned, and require an extra 64 PTEs of padding afterward; The cursors must be 64KiB aligned, and require an extra 2 PTEs of padding afterward.' As we use the same function to pin the primary and sprite planes, we can simply use the more strict requirements for scanouts for both. Instead of using explicit padding PTEs following the scanout objects, we should be able to use the scratch page that is always mapped into the unused PTEs to avoid the VT-d error. References: https://bugs.freedesktop.org/show_bug.cgi?id=59626 References: https://bugs.freedesktop.org/show_bug.cgi?id=59627 References: https://bugs.freedesktop.org/show_bug.cgi?id=59631 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Apply s/vtd_wa/vtd_scanout_wa/ bikeshed since Damien likes it, too.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/i915_gem_dmabuf.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud