From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: linux-kernel@vger.kernel.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
Dibin Moolakadan Subrahmanian
<dibin.moolakadan.subrahmanian@intel.com>,
Imre Deak <imre.deak@intel.com>,
David Laight <david.laight.linux@gmail.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Matt Wagantall <mattw@codeaurora.org>,
Dejin Zheng <zhengdejin5@gmail.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v2 1/4] iopoll: Generalize read_poll_timeout() into poll_timeout_us()
Date: Tue, 15 Jul 2025 21:20:58 +0300 [thread overview]
Message-ID: <aHacCnkuMCwNYin8@intel.com> (raw)
In-Reply-To: <20250708131634.1524-1-ville.syrjala@linux.intel.com>
On Tue, Jul 08, 2025 at 04:16:34PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> While read_poll_timeout() & co. were originally introduced just
> for simple I/O usage scenarios they have since been generalized to
> be useful in more cases.
>
> However the interface is very cumbersome to use in the general case.
> Attempt to make it more flexible by combining the 'op', 'var' and
> 'args' parameter into just a single 'op' that the caller can fully
> specify.
>
> For example i915 has one case where one might currently
> have to write something like:
> ret = read_poll_timeout(drm_dp_dpcd_read_byte, err,
> err || (status & mask),
> 0 * 1000, 200 * 1000, false,
> aux, DP_FEC_STATUS, &status);
> which is practically illegible, but with the adjusted macro
> we do:
> ret = poll_timeout_us(err = drm_dp_dpcd_read_byte(aux, DP_FEC_STATUS, &status),
> err || (status & mask),
> 0 * 1000, 200 * 1000, false);
> which much easier to understand.
>
> One could even combine the 'op' and 'cond' parameters into
> one, but that might make the caller a bit too unwieldly with
> assignments and checks being done on the same statement.
>
> This makes poll_timeout_us() closer to the i915 __wait_for()
> macro, with the main difference being that __wait_for() uses
> expenential backoff as opposed to the fixed polling interval
> used by poll_timeout_us(). Eventually we might be able to switch
> (at least most of) i915 to use poll_timeout_us().
>
> v2: Fix typos (Jani)
> Fix delay_us docs for poll_timeout_us_atomic() (Jani)
>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: David Laight <david.laight.linux@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Matt Wagantall <mattw@codeaurora.org>
> Cc: Dejin Zheng <zhengdejin5@gmail.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: intel-xe@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> include/linux/iopoll.h | 110 +++++++++++++++++++++++++++++------------
> 1 file changed, 78 insertions(+), 32 deletions(-)
Any thoughs how we should get this stuff in? Jani will need it for
some i915 stuff once he returns from vacation, so I could just push
it into drm-intel-next...
Are people OK with that, or is there a better tree that could pick
this up?
>
> diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
> index 91324c331a4b..440aca5b4b59 100644
> --- a/include/linux/iopoll.h
> +++ b/include/linux/iopoll.h
> @@ -14,41 +14,38 @@
> #include <linux/io.h>
>
> /**
> - * read_poll_timeout - Periodically poll an address until a condition is
> - * met or a timeout occurs
> - * @op: accessor function (takes @args as its arguments)
> - * @val: Variable to read the value into
> - * @cond: Break condition (usually involving @val)
> - * @sleep_us: Maximum time to sleep between reads in us (0 tight-loops). Please
> - * read usleep_range() function description for details and
> + * poll_timeout_us - Periodically poll and perform an operation until
> + * a condition is met or a timeout occurs
> + *
> + * @op: Operation
> + * @cond: Break condition
> + * @sleep_us: Maximum time to sleep between operations in us (0 tight-loops).
> + * Please read usleep_range() function description for details and
> * limitations.
> * @timeout_us: Timeout in us, 0 means never timeout
> - * @sleep_before_read: if it is true, sleep @sleep_us before read.
> - * @args: arguments for @op poll
> + * @sleep_before_op: if it is true, sleep @sleep_us before operation.
> *
> * When available, you'll probably want to use one of the specialized
> * macros defined below rather than this macro directly.
> *
> - * Returns: 0 on success and -ETIMEDOUT upon a timeout. In either
> - * case, the last read value at @args is stored in @val. Must not
> + * Returns: 0 on success and -ETIMEDOUT upon a timeout. Must not
> * be called from atomic context if sleep_us or timeout_us are used.
> */
> -#define read_poll_timeout(op, val, cond, sleep_us, timeout_us, \
> - sleep_before_read, args...) \
> +#define poll_timeout_us(op, cond, sleep_us, timeout_us, sleep_before_op) \
> ({ \
> u64 __timeout_us = (timeout_us); \
> unsigned long __sleep_us = (sleep_us); \
> ktime_t __timeout = ktime_add_us(ktime_get(), __timeout_us); \
> might_sleep_if((__sleep_us) != 0); \
> - if (sleep_before_read && __sleep_us) \
> + if ((sleep_before_op) && __sleep_us) \
> usleep_range((__sleep_us >> 2) + 1, __sleep_us); \
> for (;;) { \
> - (val) = op(args); \
> + op; \
> if (cond) \
> break; \
> if (__timeout_us && \
> ktime_compare(ktime_get(), __timeout) > 0) { \
> - (val) = op(args); \
> + op; \
> break; \
> } \
> if (__sleep_us) \
> @@ -59,17 +56,16 @@
> })
>
> /**
> - * read_poll_timeout_atomic - Periodically poll an address until a condition is
> - * met or a timeout occurs
> - * @op: accessor function (takes @args as its arguments)
> - * @val: Variable to read the value into
> - * @cond: Break condition (usually involving @val)
> - * @delay_us: Time to udelay between reads in us (0 tight-loops). Please
> - * read udelay() function description for details and
> + * poll_timeout_us_atomic - Periodically poll and perform an operation until
> + * a condition is met or a timeout occurs
> + *
> + * @op: Operation
> + * @cond: Break condition
> + * @delay_us: Time to udelay between operations in us (0 tight-loops).
> + * Please read udelay() function description for details and
> * limitations.
> * @timeout_us: Timeout in us, 0 means never timeout
> - * @delay_before_read: if it is true, delay @delay_us before read.
> - * @args: arguments for @op poll
> + * @delay_before_op: if it is true, delay @delay_us before operation.
> *
> * This macro does not rely on timekeeping. Hence it is safe to call even when
> * timekeeping is suspended, at the expense of an underestimation of wall clock
> @@ -78,27 +74,26 @@
> * When available, you'll probably want to use one of the specialized
> * macros defined below rather than this macro directly.
> *
> - * Returns: 0 on success and -ETIMEDOUT upon a timeout. In either
> - * case, the last read value at @args is stored in @val.
> + * Returns: 0 on success and -ETIMEDOUT upon a timeout.
> */
> -#define read_poll_timeout_atomic(op, val, cond, delay_us, timeout_us, \
> - delay_before_read, args...) \
> +#define poll_timeout_us_atomic(op, cond, delay_us, timeout_us, \
> + delay_before_op) \
> ({ \
> u64 __timeout_us = (timeout_us); \
> s64 __left_ns = __timeout_us * NSEC_PER_USEC; \
> unsigned long __delay_us = (delay_us); \
> u64 __delay_ns = __delay_us * NSEC_PER_USEC; \
> - if (delay_before_read && __delay_us) { \
> + if ((delay_before_op) && __delay_us) { \
> udelay(__delay_us); \
> if (__timeout_us) \
> __left_ns -= __delay_ns; \
> } \
> for (;;) { \
> - (val) = op(args); \
> + op; \
> if (cond) \
> break; \
> if (__timeout_us && __left_ns < 0) { \
> - (val) = op(args); \
> + op; \
> break; \
> } \
> if (__delay_us) { \
> @@ -113,6 +108,57 @@
> (cond) ? 0 : -ETIMEDOUT; \
> })
>
> +/**
> + * read_poll_timeout - Periodically poll an address until a condition is
> + * met or a timeout occurs
> + * @op: accessor function (takes @args as its arguments)
> + * @val: Variable to read the value into
> + * @cond: Break condition (usually involving @val)
> + * @sleep_us: Maximum time to sleep between reads in us (0 tight-loops). Please
> + * read usleep_range() function description for details and
> + * limitations.
> + * @timeout_us: Timeout in us, 0 means never timeout
> + * @sleep_before_read: if it is true, sleep @sleep_us before read.
> + * @args: arguments for @op poll
> + *
> + * When available, you'll probably want to use one of the specialized
> + * macros defined below rather than this macro directly.
> + *
> + * Returns: 0 on success and -ETIMEDOUT upon a timeout. In either
> + * case, the last read value at @args is stored in @val. Must not
> + * be called from atomic context if sleep_us or timeout_us are used.
> + */
> +#define read_poll_timeout(op, val, cond, sleep_us, timeout_us, \
> + sleep_before_read, args...) \
> + poll_timeout_us((val) = op(args), cond, sleep_us, timeout_us, sleep_before_read)
> +
> +/**
> + * read_poll_timeout_atomic - Periodically poll an address until a condition is
> + * met or a timeout occurs
> + * @op: accessor function (takes @args as its arguments)
> + * @val: Variable to read the value into
> + * @cond: Break condition (usually involving @val)
> + * @delay_us: Time to udelay between reads in us (0 tight-loops). Please
> + * read udelay() function description for details and
> + * limitations.
> + * @timeout_us: Timeout in us, 0 means never timeout
> + * @delay_before_read: if it is true, delay @delay_us before read.
> + * @args: arguments for @op poll
> + *
> + * This macro does not rely on timekeeping. Hence it is safe to call even when
> + * timekeeping is suspended, at the expense of an underestimation of wall clock
> + * time, which is rather minimal with a non-zero delay_us.
> + *
> + * When available, you'll probably want to use one of the specialized
> + * macros defined below rather than this macro directly.
> + *
> + * Returns: 0 on success and -ETIMEDOUT upon a timeout. In either
> + * case, the last read value at @args is stored in @val.
> + */
> +#define read_poll_timeout_atomic(op, val, cond, sleep_us, timeout_us, \
> + sleep_before_read, args...) \
> + poll_timeout_us_atomic((val) = op(args), cond, sleep_us, timeout_us, sleep_before_read)
> +
> /**
> * readx_poll_timeout - Periodically poll an address until a condition is met or a timeout occurs
> * @op: accessor function (takes @addr as its only argument)
> --
> 2.49.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-07-15 18:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 22:34 [PATCH 1/4] iopoll: Generalize read_poll_timeout() into poll_timeout_us() Ville Syrjala
2025-07-02 22:34 ` [PATCH 2/4] iopoll: Avoid evaluating 'cond' twice in poll_timeout_us() Ville Syrjala
2025-07-03 11:55 ` Jani Nikula
2025-07-02 22:34 ` [PATCH 3/4] iopoll: Reorder the timeout handling " Ville Syrjala
2025-07-03 12:00 ` Jani Nikula
2025-07-02 22:34 ` [PATCH 4/4] DO-NOT-MERGE: drm/i915: Use poll_timeout_us() Ville Syrjala
2025-07-03 12:12 ` Jani Nikula
2025-07-03 12:50 ` Ville Syrjälä
2025-07-02 23:05 ` ✗ CI.checkpatch: warning for series starting with [1/4] iopoll: Generalize read_poll_timeout() into poll_timeout_us() Patchwork
2025-07-02 23:06 ` ✓ CI.KUnit: success " Patchwork
2025-07-02 23:58 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-03 0:05 ` ✓ i915.CI.BAT: " Patchwork
2025-07-03 8:56 ` ✓ i915.CI.Full: " Patchwork
2025-07-03 11:51 ` [PATCH 1/4] " Jani Nikula
2025-07-03 14:28 ` Lucas De Marchi
2025-07-04 8:40 ` Jani Nikula
2025-07-04 14:34 ` ✗ Xe.CI.Full: failure for series starting with [1/4] " Patchwork
2025-07-08 13:16 ` [PATCH v2 1/4] " Ville Syrjala
2025-07-15 18:20 ` Ville Syrjälä [this message]
2025-07-31 8:51 ` Jani Nikula
2025-08-26 10:56 ` Jani Nikula
2025-07-08 14:46 ` ✗ CI.checkpatch: warning for series starting with [v2,1/4] iopoll: Generalize read_poll_timeout() into poll_timeout_us() (rev2) Patchwork
2025-07-08 14:47 ` ✓ CI.KUnit: success " Patchwork
2025-07-08 15:28 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-08 16:46 ` ✗ Xe.CI.Full: failure " Patchwork
2025-07-08 18:04 ` ✓ i915.CI.BAT: success " Patchwork
2025-07-08 23:14 ` ✓ i915.CI.Full: " Patchwork
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=aHacCnkuMCwNYin8@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=david.laight.linux@gmail.com \
--cc=dibin.moolakadan.subrahmanian@intel.com \
--cc=geert+renesas@glider.be \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=mattw@codeaurora.org \
--cc=zhengdejin5@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.