From: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
To: "chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register
Date: Wed, 28 Mar 2018 19:35:58 +0000 [thread overview]
Message-ID: <1522267221.15158.52.camel@dk-H97M-D3H> (raw)
In-Reply-To: <152226438320.10679.15283889552728790137@mail.alporthouse.com>
On Wed, 2018-03-28 at 20:13 +0100, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-03-28 20:01:40)
> >
> > On Wed, 2018-03-28 at 18:53 +0100, Chris Wilson wrote:
> > > As intel_wait_for_register_fw() may use, and if successful only use, a
> > > busy-wait loop, the might_sleep() warning is a little over-zealous.
> > > Restrict it to a might_sleep_if() a slow timeout is specified (and so
> > > the caller authorises use of a usleep).
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > ---
> > > drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> > > index f37ecfc69e49..44c4654443ba 100644
> > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > @@ -1996,7 +1996,7 @@ int __intel_wait_for_register(struct drm_i915_private *dev_priv,
> > > u32 reg_value;
> > > int ret;
> > >
> > > - might_sleep();
> > > + might_sleep_if(slow_timeout_ms);
> >
> > __wait_for() already has a might_sleep(), why is this needed?
>
> To document that this routine is a sleeper, irrespective of the
> implementation. Sometimes it is implicit on the implementation and so
> should only be at the low level, sometimes we want to call out the
> requirements explicitly and clearly. We have "wait" in the name so
> shouting out that this may indeed sleep rather than busyspin seems to
> be in order.
> -Chris
Fair enough.
There seems to be a side effect from the second hunk that your commit
message does not explicitly state.
> - if (ret)
> + if (ret && slow_timeout_ms)
This results in a different return value if condition == true and
slow_timeout_ms == 0 after fast_timeout_us was exceeded.
Previously, __intel_wait_for_register would have passed along the 0 from
__wait_for(), now it returns -ETIMEDOUT. Which means this change should
have been a separate patch.
As the patch itself is sensible,
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-03-28 19:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 17:53 [PATCH] drm/i915: Only warn for might_sleep() before a slow wait_for_register Chris Wilson
2018-03-28 19:01 ` Pandiyan, Dhinakaran
2018-03-28 19:13 ` Chris Wilson
2018-03-28 19:35 ` Pandiyan, Dhinakaran [this message]
2018-03-28 19:10 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-03-29 1:45 ` ✗ Fi.CI.IGT: failure " 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=1522267221.15158.52.camel@dk-H97M-D3H \
--to=dhinakaran.pandiyan@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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.