public inbox for intel-xe@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/i915/de: Implement register polling in the display code
Date: Mon, 23 Mar 2026 11:50:34 +0200	[thread overview]
Message-ID: <acEM6tm9cdDDN7oh@intel.com> (raw)
In-Reply-To: <c642aab2724d1db478cdcd3af623117e6f9dad5c@intel.com>

On Fri, Mar 13, 2026 at 05:03:16PM +0200, Jani Nikula wrote:
> Another difference between i915/xe and poll_timeout_us() is the range
> for usleep_range(), which is *also* different from fsleep().
> 
> i915/xe have:
> 
> 	usleep_range(wait__, wait__ * 2);
> 
> iopoll has:
> 
> 	usleep_range((__sleep_us >> 2) + 1, __sleep_us);

I was pondering about this a bit and came to the conclusion that
what poll_timeout_us() does with the usleep_range() is a bad idea.
We might have some crappy hardware/firmware (*cough* pcode *cough*)
that doesn't like to be polled too frequently, so it seems much more
sensible to provide the minimum polling interval rather than the
maximum. Also the maximum won't be the actual maximum anyway due to 
random scheduling delays/etc. So I think we probably need to change
the behavior of poll_timeout_us() if we want to actually use it...

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2026-03-23  9:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13 11:10 [PATCH 0/3] drm/i915/de: Move register polling into display code Ville Syrjala
2026-03-13 11:10 ` [PATCH 1/3] drm/i915/de: Introduce intel_de.c and move intel_de_{read, write}8() there Ville Syrjala
2026-03-13 14:21   ` Jani Nikula
2026-03-13 11:10 ` [PATCH 2/3] drm/i915/de: Move intel_de_wait*() into intel_de.c Ville Syrjala
2026-03-13 14:21   ` Jani Nikula
2026-03-13 11:10 ` [PATCH 3/3] drm/i915/de: Implement register polling in the display code Ville Syrjala
2026-03-13 15:03   ` Jani Nikula
2026-03-17  7:52     ` Ville Syrjälä
2026-03-23  9:50     ` Ville Syrjälä [this message]
2026-03-14  8:09   ` kernel test robot
2026-03-23  9:43   ` [PATCH v2 " Ville Syrjala
2026-03-13 11:15 ` ✗ CI.checkpatch: warning for drm/i915/de: Move register polling into " Patchwork
2026-03-13 11:17 ` ✓ CI.KUnit: success " Patchwork
2026-03-13 11:51 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-14 14:29 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-03-23 10:43 ` ✗ CI.checkpatch: warning for drm/i915/de: Move register polling into display code (rev2) Patchwork
2026-03-23 10:45 ` ✓ CI.KUnit: success " Patchwork
2026-03-23 11:26 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-23 13:56 ` ✓ Xe.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=acEM6tm9cdDDN7oh@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.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