From: Jani Nikula <jani.nikula@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
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,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH 4/4] DO-NOT-MERGE: drm/i915: Use poll_timeout_us()
Date: Thu, 03 Jul 2025 15:12:39 +0300 [thread overview]
Message-ID: <9bca3e31879af4ba4abd9cb3c5bd89e80ec013f1@intel.com> (raw)
In-Reply-To: <20250702223439.19752-4-ville.syrjala@linux.intel.com>
On Thu, 03 Jul 2025, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Make sure poll_timeout_us() works by using it in i915
> instead of the custom __wait_for().
>
> Remaining difference between two:
> | poll_timeout_us() | __wait_for()
> ---------------------------------------------------
> backoff | fixed interval | exponential
> usleep_range() | N/4+1 to N | N to N*2
> clock | MONOTONIC | MONOTONIC_RAW
>
> Just a test hack for now, proper conversion probably
> needs actual thought.
Agreed.
I feel pretty strongly about converting everything to use
poll_timeout_us() and poll_timeout_us_atomic() directly. I think the
plethora of wait_for variants in i915_utils.h is more confusing than
helpful (even if some of them are supposed to be "simpler"
alternatives). I also think the separate atomic variant is better than
magically deciding that based on delay length.
I'm also not all that convinced about the exponential wait. Not all of
the wait_for versions use it, and then it needs to have a max wait
anyway (we have an issue with xe not having that [1]). I believe callers
can decide on a sleep length that is appropriate for the timeout, case
by case, and gut feeling says it's probably fine. ;)
BR,
Jani.
[1] https://lore.kernel.org/r/fe44d12c701c3d410de6e0ebc1f08bae2eec10a1@intel.com
>
> Cc: Jani Nikula <jani.nikula@intel.com>
> 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
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_utils.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index f7fb40cfdb70..8509d1de1901 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -32,6 +32,7 @@
> #include <linux/types.h>
> #include <linux/workqueue.h>
> #include <linux/sched/clock.h>
> +#include <linux/iopoll.h>
>
> #ifdef CONFIG_X86
> #include <asm/hypervisor.h>
> @@ -238,7 +239,7 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
> * 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(OP, COND, US, Wmin, Wmax) ({ \
> +#define __wait_for_old(OP, COND, US, Wmin, Wmax) ({ \
> const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \
> long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
> int ret__; \
> @@ -263,6 +264,8 @@ wait_remaining_ms_from_jiffies(unsigned long timestamp_jiffies, int to_wait_ms)
> ret__; \
> })
>
> +#define __wait_for(OP, COND, US, Wmin, Wmax) \
> + poll_timeout_us(OP, COND, (Wmin), (US), false)
> #define _wait_for(COND, US, Wmin, Wmax) __wait_for(, (COND), (US), (Wmin), \
> (Wmax))
> #define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-07-03 12:12 UTC|newest]
Thread overview: 15+ 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 [this message]
2025-07-03 12:50 ` Ville Syrjälä
2025-07-03 11:51 ` [PATCH 1/4] iopoll: Generalize read_poll_timeout() into poll_timeout_us() Jani Nikula
2025-07-03 14:28 ` Lucas De Marchi
2025-07-04 8:40 ` Jani Nikula
2025-07-08 13:16 ` [PATCH v2 " Ville Syrjala
2025-07-15 18:20 ` Ville Syrjälä
2025-07-31 8:51 ` Jani Nikula
2025-08-26 10:56 ` Jani Nikula
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=9bca3e31879af4ba4abd9cb3c5bd89e80ec013f1@intel.com \
--to=jani.nikula@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=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=mattw@codeaurora.org \
--cc=ville.syrjala@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®