[Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early
Todd Brandt
todd.e.brandt at linux.intel.com
Wed Apr 27 21:27:41 UTC 2016
On Wed, 2016-04-27 at 23:49 +0300, Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 01:17:15PM -0700, Todd Brandt wrote:
> > On Wed, 2016-04-27 at 22:31 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> > > > I'd like to propose that we push the i915 suspend_late/resume_early code
> > > > into suspend_noirq/resume_noirq in order to reduce the total suspend time
> > > > by ~15ms. According to the comments, when i915_pm_suspend_late was first
> > > > added to the kernel back in April 2014, it was done so to ensure that it
> > > > was called after the snd_hda_intel driver had finished its suspend.
> > > >
> > > > The comments in i915_drv.c are here:
> > > >
> > > > /*
> > > > * We have a suspedn ordering issue with the snd-hda driver also
> > > > * requiring our device to be power up. Due to the lack of a
> > > > * parent/child relationship we currently solve this with an late
> > > > * suspend hook.
> > > > *
> > > > * FIXME: This should be solved with a special hdmi sink device or
> > > > * similar so that power domains can be employed.
> > > > */
> > > >
> > > > I believe we could achieve the same ordering by simply pushing it to
> > > > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late
> > > > and resume_early phases altogether in most simple systems. Does anyone see
> > > > a problem with this?
> > > >
> > > > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH):
> > > > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
> > > > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
> > > > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/
> > > >
> > > > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH):
> > > > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/
> > > > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/
> > > > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/
> > >
> > > Hmm. Looking at those makes me confused. Why isn't the pci bus
> > > .resume_noirq hook (pci_pm_resume_noirq()) waking up our pci device?
> > > Instead our wakeup gets delayed until .resume_early for some reason.
> >
> > Which timeline are you referring to? The "late" ones are the unaltered
> > versions.
>
> Referring to the current code, ie. the "late" timeline.
>
Well it does wakeup with noirq in the suspend mode (S3) version:
https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/
It's in freeze (S2) that it gets delayed to resume_early, which I
assumed was normal (I'll try it on other systems to compare):
https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/
More information about the Intel-gfx
mailing list