[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