drm/i915/guc: Do not wait for firmware load atomically
authorTvrtko Ursulin <tvrtko.ursulin@intel.com>
Thu, 11 Feb 2016 10:27:31 +0000 (10:27 +0000)
committerTvrtko Ursulin <tvrtko.ursulin@intel.com>
Mon, 15 Feb 2016 16:10:19 +0000 (16:10 +0000)
It does not look like this code needs to wait atomically?

Higher in the call chain it calls the GEM API and I do
not see that the section is under any spin locks or such.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
drivers/gpu/drm/i915/intel_guc_loader.c

index 3accd91..82a3c03 100644 (file)
@@ -199,7 +199,7 @@ static void set_guc_init_params(struct drm_i915_private *dev_priv)
  * the value matches either of two values representing completion
  * of the GuC boot process.
  *
- * This is used for polling the GuC status in a wait_for_atomic()
+ * This is used for polling the GuC status in a wait_for()
  * loop below.
  */
 static inline bool guc_ucode_response(struct drm_i915_private *dev_priv,
@@ -259,14 +259,14 @@ static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv)
        I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE | START_DMA));
 
        /*
-        * Spin-wait for the DMA to complete & the GuC to start up.
+        * Wait for the DMA to complete & the GuC to start up.
         * NB: Docs recommend not using the interrupt for completion.
         * Measurements indicate this should take no more than 20ms, so a
         * timeout here indicates that the GuC has failed and is unusable.
         * (Higher levels of the driver will attempt to fall back to
         * execlist mode if this happens.)
         */
-       ret = wait_for_atomic(guc_ucode_response(dev_priv, &status), 100);
+       ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
 
        DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
                        I915_READ(DMA_CTRL), status);