On 28/06/16 11:37, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.

Fixes: 0351b93992aa ("drm/i915: Do not lie about atomic timeout granularity")
CC: Chris Wilson <[email protected]>
CC: Tvrtko Ursulin <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
---
  drivers/gpu/drm/i915/intel_display.c | 8 ++++----
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0312472..d902a70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9534,8 +9534,8 @@ static void hsw_disable_lcpll(struct drm_i915_private 
*dev_priv,
                val |= LCPLL_CD_SOURCE_FCLK;
                I915_WRITE(LCPLL_CTL, val);

-               if (wait_for_atomic_us(I915_READ(LCPLL_CTL) &
-                                      LCPLL_CD_SOURCE_FCLK_DONE, 1))
+               if (wait_for_us(I915_READ(LCPLL_CTL) &
+                               LCPLL_CD_SOURCE_FCLK_DONE, 1))
                        DRM_ERROR("Switching to FCLK failed\n");

                val = I915_READ(LCPLL_CTL);
@@ -9608,8 +9608,8 @@ static void hsw_restore_lcpll(struct drm_i915_private 
*dev_priv)
                val &= ~LCPLL_CD_SOURCE_FCLK;
                I915_WRITE(LCPLL_CTL, val);

-               if (wait_for_atomic_us((I915_READ(LCPLL_CTL) &
-                                       LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
+               if (wait_for_us((I915_READ(LCPLL_CTL) &
+                                LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
                        DRM_ERROR("Switching back to LCPLL failed\n");
        }



This one is also on a mutex-taking path so looks correct to me.

Reviewed-by: Tvrtko Ursulin <[email protected]>

Since it just a 1us timeout, as I wrote in another reply I can follow up with a patch to implement those more efficiently. Does not make anything worse in the meantime unless operation times out which is not critical.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to