On Tue, May 17, 2016 at 06:43:25PM +0300, Mika Kuoppala wrote:
> If the condition we are after doesn't happen, start to sleep
> longer and longer periods to save power. But never sleep more than 1/5th
> of the timeout value. Convert few remaining callsites to use this generic
> macro instead of letting them specifying their own sleeping periods.
> This results in only one generic wait_for across all callsites so
> we can remove the macro specifying the sleep period.
> 
> Signed-off-by: Mika Kuoppala <mika.kuopp...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |  4 ++--
>  drivers/gpu/drm/i915/intel_drv.h | 15 ++++++++++-----
>  drivers/gpu/drm/i915/intel_psr.c |  6 +++---
>  3 files changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a32617469816..b14761f585e9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1699,8 +1699,8 @@ static void wait_panel_status(struct intel_dp *intel_dp,
>                       I915_READ(pp_stat_reg),
>                       I915_READ(pp_ctrl_reg));
>  
> -     if (_wait_for_ms((I915_READ(pp_stat_reg) & mask) == value,
> -                      5 * MSEC_PER_SEC, 10 * USEC_PER_MSEC))
> +     if (wait_for((I915_READ(pp_stat_reg) & mask) == value,
> +                  5 * MSEC_PER_SEC))
>               DRM_ERROR("Panel status timeout: status %08x control %08x\n",
>                               I915_READ(pp_stat_reg),
>                               I915_READ(pp_ctrl_reg));
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index c225605c727c..1b03461e75e4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -50,7 +50,7 @@
>   * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
>   * added.
>   */
> -#define __wait_for_ms(COND, TIMEOUT_MS, SLEEP_US, SPIN_COUNT) ({     \
> +#define __wait_for_ms(COND, TIMEOUT_MS, SPIN_COUNT) ({                       
> \
>       const unsigned long timeout__ =                                 \
>               jiffies + msecs_to_jiffies(TIMEOUT_MS) + 1;             \
>       unsigned int c__ = 0;                                           \
> @@ -64,9 +64,15 @@
>               }                                                       \
>                                                                       \
>               if (++c__ > (SPIN_COUNT) &&                             \
> -                 (SLEEP_US) &&                                       \
> +                 (TIMEOUT_MS) &&                                     \
>                   drm_can_sleep()) {                                  \
> -                     usleep_range((SLEEP_US), (SLEEP_US) * 2);       \
> +                     /* Limit max nap to 1/4 of timeout */           \
> +                     unsigned int s__ =                              \
> +                             clamp_val(c__ * 2 * USEC_PER_MSEC,      \
> +                                 TIMEOUT_MS * 250,                   \
> +                                   MAX_UDELAY_MS);                   \

I don't think this does what you mean, or your commit description is off.
You claim that you'll never sleep more than 1/5 of the full timeout, but
TIMEOUT_MS*250 is 1/4th, and you use it as the minimum argument. I think
what you really want here is

min(min(c__* 2 * USEC_PER_MSEC, TIMEOUT_MS * 250),
        MAX_UDELAY_MS * USEC_PER_MSEC);


Also 2 * SPIN_COUNT ms sleeping for the first time seems a bit excessive
(and is much larger than the max usleep delay on may platforms), many of
our timeouts are in the 100usec range. Imo exponential backoff works
better,
i.e.

100 << (c__ - SPIN_COUNT)

That means sleep times of 100us, 200us, 400us, 800 us ...

Or do I completely misread the math here? Maybe also split up things into
a few lines, i.e. first compute the timout, then clamp with min as needed.
-Daniel

> +                                                                     \
> +                     usleep_range(s__ >> 1, s__);                    \
>               } else {                                                \
>                       cpu_relax();                                    \
>               }                                                       \
> @@ -74,8 +80,7 @@
>       ret__;                                                          \
>  })
>  
> -#define wait_for(COND, MS)  __wait_for_ms((COND), (MS), 1 * USEC_PER_MSEC, 5)
> -#define _wait_for_ms(COND, MS, US)  __wait_for_ms((COND), (MS), (US), 5)
> +#define wait_for(COND, MS)  __wait_for_ms((COND), (MS), 5)
>  
>  /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
>  #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 0ceb2026835e..912312b79eda 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -506,9 +506,9 @@ static void hsw_psr_disable(struct intel_dp *intel_dp)
>                          I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
>  
>               /* Wait till PSR is idle */
> -             if (_wait_for_ms((I915_READ(EDP_PSR_STATUS_CTL) &
> -                               EDP_PSR_STATUS_STATE_MASK) == 0,
> -                              2 * MSEC_PER_SEC, 10 * USEC_PER_MSEC))
> +             if (wait_for((I915_READ(EDP_PSR_STATUS_CTL) &
> +                           EDP_PSR_STATUS_STATE_MASK) == 0,
> +                          2 * MSEC_PER_SEC))
>                       DRM_ERROR("Timed out waiting for PSR Idle State\n");
>  
>               dev_priv->psr.active = false;
> -- 
> 2.5.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to