From: Caz Yokoyama <Caz.Yokoyama@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH v2 2/2] add DROP_SUSPEND.
Date: Tue, 12 Mar 2019 10:14:25 -0700 [thread overview]
Message-ID: <d36ad936e4344f81e0e720da24817d12c9cc371d.camel@intel.com> (raw)
In-Reply-To: <155240693584.30003.18248026626471584008@skylake-alporthouse-com>
On Tue, 2019-03-12 at 16:09 +0000, Chris Wilson wrote:
> Quoting Caz Yokoyama (2019-03-12 16:11:14)
> > On Tue, 2019-03-12 at 15:51 +0000, Chris Wilson wrote:
> > > Quoting Caz Yokoyama (2019-03-12 15:52:09)
> > > > On Tue, 2019-03-12 at 15:30 +0000, Chris Wilson wrote:
> > > > > Quoting Caz Yokoyama (2019-03-12 03:31:32)
> > > > > > + if (val & DROP_SUSPEND) {
> > > > > > + struct device *dev = i915->drm.dev;
> > > > > > +
> > > > > > + dev_info(dev, "%s() %d: runtime_status:
> > > > > > %d\n",
> > > > > > __func__, __LINE__,
> > > > > > + dev->power.runtime_status);
> > > > >
> > > > >
> > > > > > + pm_runtime_disable(dev);
> > > > > > + if (!pm_runtime_status_suspended(dev)) {
> > > > > > + dev_warn(dev, "%s() %d:
> > > > > > runtime_status:
> > > > > > %d\n", __func__, __LINE__,
> > > > > > + dev-
> > > > > > >power.runtime_status);
> > > > > > + }
> > > > > > + pm_runtime_enable(dev);
> > > > >
> > > > > ret = pm_runtime_force_suspend(i915->drm.dev);
> > > > >
> > > >
> > > > Yes, this works. However, pm_runtime_force_suspend() always
> > > > exits
> > > > on
> > > > if (pm_runtime_status_suspended(dev))
> > > > return 0;
> > > > Therefore, this patch is meaningless after suspended state.
> > >
> > > Which would be fine for DROP_SUSPEND. Ah, so your intent is to do
> > > a
> > > DROP_WAKE as well :)
> >
> > My intention is to remove gem-execbuf-stress-extra-wait subtest
> > because it does same as gem-execbuf-stress except for meaningless
> > (10 x
> > 5 sec) delay.
>
> Then why complain that pm_runtime_force_suspend() is a no-op starting
> from a suspended state?
No, I am not complaining. The patch above is to confirm the patch is
meaningless on suspended state.
>
> WAIT_EXTRA is after WAIT_STATUS, so it will always be in a suspended
> state. If your intent then is to bolster the test by forcing a fresh
> suspend cycle, make that explicit and have both DROP_WAKE |
> DROP_SUSPEND. As it stands we can use DROP_SUSPEND as a faster
> WAIT_STATUS.
Let me update the patch.
-caz
> -Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-03-12 17:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 3:31 [igt-dev] [PATCH i-g-t v2 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster Caz Yokoyama
2019-03-12 3:31 ` [igt-dev] [PATCH v2 2/2] add DROP_SUSPEND Caz Yokoyama
2019-03-12 15:30 ` Chris Wilson
2019-03-12 15:52 ` Caz Yokoyama
2019-03-12 15:51 ` Chris Wilson
2019-03-12 16:11 ` Caz Yokoyama
2019-03-12 16:09 ` Chris Wilson
2019-03-12 17:14 ` Caz Yokoyama [this message]
2019-03-12 22:36 ` Caz Yokoyama
2019-03-12 22:42 ` Chris Wilson
2019-03-12 15:14 ` [igt-dev] [PATCH i-g-t v2 1/1] i915_pm_rpm: gem-execbuf-stress-extra-wait faster Caz Yokoyama
2019-03-12 15:24 ` Chris Wilson
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=d36ad936e4344f81e0e720da24817d12c9cc371d.camel@intel.com \
--to=caz.yokoyama@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=igt-dev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox