drm/i915: Serialise updates to GGTT with access through GGTT on Braswell
authorChris Wilson <chris@chris-wilson.co.uk>
Fri, 23 Oct 2015 17:43:32 +0000 (18:43 +0100)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 17 Nov 2015 16:36:01 +0000 (17:36 +0100)
commit5bab6f60cb4d1417ad7c599166bcfec87529c1a2
treebd16fd1edc1426768b39b3d5495fa4778a8a41d7
parent14631e9d740a2353c4b5734716c84a84e0b1c075
drm/i915: Serialise updates to GGTT with access through GGTT on Braswell

When accessing through the GTT from one CPU whilst concurrently updating
the GGTT PTEs in another thread, the hardware likes to return random
data. As we have strong serialisation prevent us from modifying the PTE
of an active GTT mmapping, we have to conclude that it whilst modifying
other PTE's that error occurs. (I have not looked for any pattern such
as modifying PTE within the same page or cacheline as active PTE -
though checking whether revoking neighbouring objects should be enough
to test that theory.) The corruption also seems restricted to Braswell
and disappears with maxcpus=0. This patch stops all access through the
GTT by other CPUs when we update any PTE by stopping the machine around
the GGTT update.

Note that splitting up the 64 bit write into two 32 bit writes was
tried and found to fail too.

Testcase: igt/gem_concurrent_blit
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89079
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about 2x 32bits failing too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/Kconfig
drivers/gpu/drm/i915/i915_gem_gtt.c