linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Sean Paul <seanpaul@chromium.org>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: seanpaul@google.com, "David Airlie" <airlied@linux.ie>,
	linux-kernel@vger.kernel.org,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	daniel.vetter@intel.com
Subject: Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines
Date: Tue, 05 Dec 2017 23:09:01 +0000	[thread overview]
Message-ID: <151251534148.3497.565078431241355506@mail.alporthouse.com> (raw)
In-Reply-To: <20171205051513.8603-3-seanpaul@chromium.org>

Quoting Sean Paul (2017-12-05 05:15:01)
> This patch adds a little more control to a couple wait_for routines such
> that we can avoid open-coding read/wait/timeout patterns which:
>  - need the value of the register after the wait_for
>  - run arbitrary operation for the read portion
> 
> This patch also chooses the correct sleep function (based on
> timers-howto.txt) for the polling interval the caller specifies.
> 
> Changes in v2:
> - Added to the series
> Changes in v3:
> - Rebased on drm-intel-next-queued and the new Wmin/max _wait_for
> - Removed msleep option
> 
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> ---
>  drivers/gpu/drm/i915/intel_drv.h    | 17 ++++++++++-------
>  drivers/gpu/drm/i915/intel_uncore.c | 23 ++++++++++++++++-------
>  drivers/gpu/drm/i915/intel_uncore.h | 14 +++++++++++++-
>  3 files changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 64426d3e078e..852b3d161754 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,20 +41,21 @@
>  #include <drm/drm_atomic.h>
>  
>  /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
>   *
> - * Does the right thing for modeset paths when run under kdgb or similar atomic
> - * contexts. Note that it's important that we check the condition again after
> - * having timed out, since the timeout could be due to preemption or similar and
> - * we've never had a chance to check the condition before the timeout.
> + * Macro to help avoid open coding check/wait/timeout patterns. Note that it's
> + * important that we check the condition again after having timed out, since the
> + * timeout could be due to preemption or similar and we've never had a chance to
> + * check the condition before the timeout.
>   */
> -#define _wait_for(COND, US, Wmin, Wmax) ({ \
> +#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
>         unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
>         long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
>         int ret__;                                                      \
>         might_sleep();                                                  \
>         for (;;) {                                                      \
>                 bool expired__ = time_after(jiffies, timeout__);        \
> +               OP;                                                     \
>                 if (COND) {                                             \
>                         ret__ = 0;                                      \
>                         break;                                          \
> @@ -70,7 +71,9 @@
>         ret__;                                                          \
>  })
>  
> -#define wait_for(COND, MS)     _wait_for((COND), (MS) * 1000, 10, 1000)
> +#define _wait_for(COND, US, Wmin, Wmax)        __wait_for(;, (COND), (US), (Wmin), \
> +                                                  (Wmax))

Hmm, doesn't an empty OP (__wait_for(, ...)) work?

> +int __intel_wait_for_register(struct drm_i915_private *dev_priv,
>                             i915_reg_t reg,
>                             u32 mask,
>                             u32 value,
> -                           unsigned int timeout_ms)
> +                           unsigned int fast_timeout_us,
> +                           unsigned int slow_timeout_ms,
> +                           u32 *out_value)
>  {
>         unsigned fw =
>                 intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
>         int ret;
> +       u32 reg_value;

Before int ret; Try to avoid building a Christmas tree if possible.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

  parent reply	other threads:[~2017-12-05 23:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05  5:14 [PATCH v3 0/9] drm/i915: Implement HDCP Sean Paul
2017-12-05  5:15 ` [PATCH v3 1/9] drm: Fix link-status kerneldoc line lengths Sean Paul
2017-12-05  5:15 ` [PATCH v3 2/9] drm/i915: Add more control to wait_for routines Sean Paul
2017-12-05 17:13   ` Daniel Vetter
2017-12-05 23:09   ` Chris Wilson [this message]
2017-12-05  5:15 ` [PATCH v3 3/9] drm: Add Content Protection property Sean Paul
2017-12-05  8:07   ` Hans Verkuil
2017-12-05 15:27     ` [Intel-gfx] " Daniel Vetter
2017-12-05 15:34   ` Daniel Vetter
2017-12-05 15:40     ` [Intel-gfx] " Chris Wilson
2017-12-05  5:15 ` [PATCH v3 4/9] drm: Add some HDCP related #defines Sean Paul
2017-12-05 23:12   ` [Intel-gfx] " Chris Wilson
2017-12-06 15:01     ` Alex Deucher
2017-12-05  5:15 ` [PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation Sean Paul
2017-12-05  9:06   ` Ramalingam C
2017-12-05 17:00   ` Daniel Vetter
2017-12-05  5:15 ` [PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature Sean Paul
2017-12-05 17:01   ` [Intel-gfx] " Daniel Vetter
2017-12-05 17:33   ` Ville Syrjälä
2017-12-05  5:15 ` [PATCH v3 7/9] drm/i915: Add function to output Aksv over GMBUS Sean Paul
2017-12-05 17:02   ` [Intel-gfx] " Daniel Vetter
2017-12-05  5:15 ` [PATCH v3 8/9] drm/i915: Implement HDCP for HDMI Sean Paul
2017-12-05 17:06   ` Daniel Vetter
2017-12-05  5:15 ` [PATCH v3 9/9] drm/i915: Implement HDCP for DisplayPort Sean Paul
2017-12-05 14:30   ` Ramalingam C
2017-12-05 17:12   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=151251534148.3497.565078431241355506@mail.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=seanpaul@chromium.org \
    --cc=seanpaul@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).