1. 10 Jul, 2013 3 commits
    • Chris Wilson's avatar
      drm/i915: Fix incoherence with fence updates on Sandybridge+ · d18b9619
      Chris Wilson authored
      This hopefully fixes the root cause behind the workaround added in
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      Thanks to further investigation by Jon Bloomfield, he realised that
      the 64-bit register might be broken up by the hardware into two 32-bit
      writes (a problem we have encountered elsewhere). This non-atomicity
      would then cause an issue where a second thread would see an
      intermediate register state (new high dword, old low dword), and this
      register would randomly be used in preference to its own thread register.
      This would cause the second thread to read from and write into a fairly
      random tiled location.  Breaking the operation into 3 explicit 32-bit
      updates (first disable the fence, poke the upper bits, then poke the lower
      bits and enable) ensures that, given proper serialisation between the
      32-bit register write and the memory transfer, that the fence value is
      always consistent.
      
      Armed with this knowledge, we can explain how the previous workaround
      work. The key to the corruption is that a second thread sees an
      erroneous fence register that conflicts and overrides its own. By
      serialising the fence update across all CPUs, we have a small window
      where no GTT access is occurring and so hide the potential corruption.
      This also leads to the conclusion that the earlier workaround was
      incomplete.
      
      v2: Be overly paranoid about the order in which fence updates become
      visible to the GPU to make really sure that we turn the fence off before
      doing the update, and then only switch the fence on afterwards.
      Signed-off-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d18b9619
    • Chris Wilson's avatar
      drm/i915: Fix write-read race with multiple rings · 02978ff5
      Chris Wilson authored
      Daniel noticed a problem where is we wrote to an object with ring A in
      the middle of a very long running batch, then executed a quick batch on
      ring B before a batch that reads from the same object, its obj->ring would
      now point to ring B, but its last_write_seqno would be still relative to
      ring A. This would allow for the user to read from the object before the
      GPU had completed the write, as set_domain would only check that ring B
      had passed the last_write_seqno.
      
      To fix this simply (and inelegantly), we bump the last_write_seqno when
      switching rings so that the last_write_seqno is always relative to the
      current obj->ring.
      
      This fixes igt/tests/gem_write_read_ring_switch.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about the newly created igt which exercises this
      bug.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      02978ff5
    • Guenter Roeck's avatar
      Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" · c11e5f35
      Guenter Roeck authored
      This patch partially reverts commit 36ec8f87 for
      IvyBridge CPUs.
      
      The original commit results in repeated 'Timed out waiting for forcewake old
      ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
      with i7-3770K CPU. It ultimately results in a hangup if the system is highly
      loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
      
      Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
      this condition can result in secondary issues.
      
      v2: Only revert patch for Ivybridge CPUs
          Issue info message if mt forcewake is disabled on Ivybridge
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c11e5f35
  2. 09 Jul, 2013 4 commits
  3. 04 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: reinit status page registers after gpu reset · 035dc1e0
      Daniel Vetter authored
      This fixes gpu reset on my gm45 - without this patch the bsd thing is
      forever stuck since the seqno updates never reach the status page.
      
      Tbh I have no idea how this ever worked without rewriting the hws
      registers after a gpu reset.
      
      To satisfy my OCD also give the functions a bit more consistent names:
      - Use status_page everywhere, also for the physical addressed one.
      - Use init for the allocation part and setup for the register setup
        part consistently.
      
      Long term I'd really like to share the hw init parts completely
      between gpu reset, resume and driver load, i.e. to call
      i915_gem_init_hw instead of the individual pieces we might need.
      
      v2: Add the missing paragraph to the commit message about what bug
      exactly this patch here fixes.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65495
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarlu hua <huax.lu@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      035dc1e0
  4. 02 Jul, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Don't try to tear down the stolen drm_mm if it's not there · 446f8d81
      Daniel Vetter authored
      Every other place properly checks whether we've managed to set
      up the stolen allocator at boot-up properly, with the exception
      of the cleanup code. Which results in an ugly
      
      *ERROR* Memory manager not clean. Delaying takedown
      
      at module unload time since the drm_mm isn't initialized at all.
      
      v2: While at it check whether the stolen drm_mm is initialized instead
      of the more obscure stolen_base == 0 check.
      
      v3: Fix up the logic. Also we need to keep the stolen_base check in
      i915_gem_object_create_stolen_for_preallocated since that can be
      called before stolen memory is fully set up. Spotted by Chris Wilson.
      
      v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
      the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
      allocatot must already be initialized when calling that function (if
      we indeed have stolen memory).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Tested-by: lu hua <huax.lu@intel.com> (v3)
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      446f8d81
  5. 01 Jul, 2013 31 commits