Re: i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers)

[Imre Deak <imre.deak@intel.com>]

On Fri, Feb 16, 2018 at 09:49:28AM +0100, Lukas Wunner wrote:
> [trimming cc: a little to avoid spamming folks not directly involved with i915]
> 
> On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > > on runtime suspend.  But this results in the GPU bouncing back and forth
> > > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > > runtime suspend to D3cold since every suspend/resume cycle costs a
> > > significant amount of time and energy.  (i915 and malidp do not seem
> > > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > > questionable.  msm however does and would also deadlock if it disabled
> > > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> > 
> > In i915 polling is on during runtime suspend only if there are outputs
> > without hotplug interrupt support. A special case is when an output has
> > working HPD interrupts when in D0, but no interrupts when runtime
> > suspended. For these we start polling (from a scheduled work) in the
> > runtime suspend hook and stop it in the runtime resume hook (again from
> > a scheduled work).
> 
> I'm assuming to poll outputs you need to access mmio, is that correct?

Correct.

> Since mmio is inaccessible in D3hot, you seem to leave the PCI device
> in D0 during runtime suspend, right?

No, it's put into D3 (by the runtime PM core).

> Aren't you leaving power saving
> potential on the table that way?  Or are you able to achieve the same
> low power consumption in D0 as in D3hot by turning off power wells etc?
> When powering off the GPU via vga_switcheroo manual power control
> (a legacy feature we'll hopefully drop once we have runtime PM
> support on muxed laptops and in i915) the PCI device *is* put into
> D3hot by i915_suspend_switcheroo().  If leaving the device in D0
> in the runtime suspend code path results in less power reduction,
> runtime PM wouldn't be a full replacement for vga_switcheroo manual
> power control, which would be kind of a bummer. :-/

It's possible that in the future the device won't be put into D3, given
that HPD interrupts are gone in that state, but this will be done only
if D3 doesn't provide any power saving over turning off display/GPU
power wells (still need to figure out the details of this).

> Another question, you're not calling pm_runtime_allow() when binding
> the driver to the device, so users have to either manually allow it
> via sysfs or use "powertop --auto-tune" or whatever.  What's the
> rationale for that?

We decided to have more testing/fixing known issues before enabling it
by default.

--Imre

> nouveau, radeon and amdgpu all allow it by default.
> 
> Thanks,
> 
> Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx