[igt-dev] [PATCH v2 2/2] add DROP_SUSPEND.

[Chris Wilson]

Quoting Caz Yokoyama (2019-03-12 22:36:49)
> On Tue, 2019-03-12 at 08:52 -0700, Caz Yokoyama wrote:
> > 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;
> Correction. This does not work because of kernel crash. When exiting
> from pm_runtime_force_suspend() by pm_runtime_status_suspended(dev) ==
> true, pm_runtime_enable(dev) is not called. It looks a bug for me.

Bah, just that I'm suggesting to use them outside of their expected
context. They should only be used during system-wide suspend/resume
apparently, which is annoying.

However, without such a call, we do not guarantee we suspend (skipping a
call to intel_runtime_suspend).

Maybe...
	pm_runtime_disable();
	pm_runtime_suspend();
	pm_runtime_enable();

If a plain pm_runtime_suspend() isn't enough by itself.

Fun experiments,
-Chris