Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Nikula,  Jani" <jani.nikula@intel.com>,
	"Roper, Matthew D" <matthew.d.roper@intel.com>
Subject: Re: [PATCH] drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximums
Date: Wed, 16 Sep 2026 19:10:11 +0000	[thread overview]
Message-ID: <6f8deb9d5f07feae11f35363e8b22d5ae606e63d.camel@intel.com> (raw)
In-Reply-To: <aqnL7lUojj9jm8q_@intel.com>

On Tue, 2026-09-15 at 18:51 -0400, Vivi, Rodrigo wrote:
> On Tue, Sep 15, 2026 at 04:00:54PM +0000, Teres Alexis, Alan Previn wrote:
> > On Tue, 2026-09-15 at 10:34 +0300, Nikula, Jani wrote:
> > > On Mon, 14 Sep 2026, Alan Previn <alan.previn.teres.alexis@intel.com> wrote:
> > alan:snip
> > > >  int xe_mmio_wait32(struct xe_mmio *mmio, struct xe_reg reg, u32 mask, u32 val, u32 timeout_us,
> > > > -		   u32 *out_val, bool atomic)
> > > > +		   u32 *out_val)
> > > >  {
> > > > -	return __xe_mmio_wait32(mmio, reg, mask, val, timeout_us, out_val, atomic, true);
> > > > +	u32 read;
> > > > +	int ret;
> > > > +
> > > > +	ret = poll_timeout_us(read = xe_mmio_read32(mmio, reg), (read & mask) == val,
> > > > +			      10, timeout_us, false);
> > > 
> > > You probably do need to let the callers pass in the wait too. 10 us wait
> > > with a long timeout is going to be pretty bad.
> 
> agreed
> 
> > > 
> > > 
> > alan: okay - perhaps i can make every caller pass in a polling-wait thats a fraction of their wait time.
> > (as a starting point since i dont know what's the expected behavior of every caller).
> > so perhaps something like "timeout_us << 4" (i.e. 1/16th) but pass in 10 us if its anything smaller than that
> > (i.e. smaller than 16 usec).
> 
> I think we might be complicating this too much..
> 
> what about something simpler like:
> 
> #define XE_MMIO_WAIT_MAX_BACKOFF_US   1000
> 
> ...
> -             wait <<= 1;
> +             wait = min_t(s64, wait << 1, XE_MMIO_WAIT_MAX_BACKOFF_US);
> 
> 

alan: i dont understand your this comment on the increasing the "wait by x2" in the loop after agreeing with Jani on the earlier statement.
Some historical context:

 1. current baseline code it stands to day IS in violation of linux rules for how to use those sleep/delay functions
 2. my initial revs on fixing this was to minimize the changes so its not complicated by simply fixing the code in place.
 3. Jani said we really should use the proper linux kernel helpers: poll_timeout_us / poll_timeout_us_atomic.
 4. Those helpers have the "timeout_us" and the "intra-loop-wait-us" period. I hardcoded to 10 usec.
	- Jani said i should not hardcode and ensure all up-the-stack callers of the xe_mmio_wait32 function passes in the intra-wait-loop
value. 
	- Then you (Rodrigo) agreed with his request but go on to propose going back to exponential 2x intra-wait-loop.
		- but that contradicts Jani's request u agreed to and also that means we implement the intra-wait-loop? (i.e. dont use the
proper linux helper?)

 ...alan


> Also the Fixes tag is not the right one... the bug was there before...
> 
> > 
> > ...alan


  reply	other threads:[~2026-09-16 19:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 21:57 [PATCH] drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximums Alan Previn
2026-09-14 22:16 ` sashiko-bot
2026-09-14 22:40 ` ✓ CI.KUnit: success for drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximums (rev4) Patchwork
2026-09-14 23:39 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-15  4:17 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-15  7:34 ` [PATCH] drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximums Jani Nikula
2026-09-15 16:00   ` Teres Alexis, Alan Previn
2026-09-15 16:43     ` Jani Nikula
2026-09-15 22:51     ` Rodrigo Vivi
2026-09-16 19:10       ` Teres Alexis, Alan Previn [this message]
2026-09-17  0:54         ` Rodrigo Vivi
2026-09-17  2:07           ` Teres Alexis, Alan Previn
2026-09-17 18:49             ` Teres Alexis, Alan Previn
  -- strict thread matches above, loose matches on Subject: below --
2026-09-29 19:20 Alan Previn
2026-09-30  3:51 ` Rodrigo Vivi
2026-09-29 15:25 Alan Previn
2026-09-29 16:18 ` sashiko-bot
2026-09-29 19:07   ` Teres Alexis, Alan Previn
2026-09-29  5:44 Alan Previn
2026-09-29  5:49 ` sashiko-bot
2026-09-29 17:51 ` Rodrigo Vivi
2026-09-08 20:33 Alan Previn
2026-09-08 18:56 Alan Previn
2026-09-08 19:03 ` sashiko-bot
2026-09-09  8:00 ` Jani Nikula
2026-09-11  0:05   ` Teres Alexis, Alan Previn
2026-09-07 23:55 Alan Previn
2026-09-08  0:02 ` sashiko-bot

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=6f8deb9d5f07feae11f35363e8b22d5ae606e63d.camel@intel.com \
    --to=alan.previn.teres.alexis@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@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