summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_gem.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2016-08-18 16:16:46 (GMT)
committerChris Wilson <chris@chris-wilson.co.uk>2016-08-18 21:36:43 (GMT)
commit31a39207f04a37324d70ff5665fd19d3a75b39c1 (patch)
tree1eef17d52959b88908248b67a46c295a74a19276 /drivers/gpu/drm/i915/i915_gem.c
parent18034584784168c73bc8dd57104ea48c42f38527 (diff)
downloadlinux-31a39207f04a37324d70ff5665fd19d3a75b39c1.tar.xz
drm/i915: Cache kmap between relocations
When doing relocations, we have to obtain a mapping to the page containing the target address. This is either a kmap or iomap depending on GPU and its cache coherency. Neighbouring relocation entries are typically within the same page and so we can cache our kmapping between them and avoid those pesky TLB flushes. Note that there is some sleight-of-hand in how the slow relocate works as the reloc_entry_cache implies pagefaults disabled (as we are inside a kmap_atomic section). However, the slow relocate code is meant to be the fallback from the atomic fast path failing. Fortunately it works as we already have performed the copy_from_user for the relocation array (no more pagefaults there) and the kmap_atomic cache is enabled after we have waited upon an active buffer (so no more sleeping in atomic). Magic! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-7-chris@chris-wilson.co.uk
Diffstat (limited to 'drivers/gpu/drm/i915/i915_gem.c')
0 files changed, 0 insertions, 0 deletions