1. 18 11月, 2015 1 次提交
    • C
      drm/i915: Serialise updates to GGTT with access through GGTT on Braswell · 5bab6f60
      Chris Wilson 提交于
      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=89079Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add note about 2x 32bits failing too.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5bab6f60
  2. 17 11月, 2015 3 次提交
  3. 16 11月, 2015 7 次提交
  4. 13 11月, 2015 2 次提交
  5. 12 11月, 2015 17 次提交
  6. 11 11月, 2015 5 次提交
  7. 10 11月, 2015 5 次提交