Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1236407

Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware

From Alan Stern <stern@rowland.harvard.edu>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware
Date 2015-09-30 16:50 +0200
Message-ID <qeqRH-7Z1-1@gated-at.bofh.it> (permalink)
References <qedrr-5yV-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, 30 Sep 2015, Rafael J. Wysocki wrote:

> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If the platform firmware was involved in the system resume that's
> being completed, there is a concern that some devices might have
> been reset by it and if those devices had the power.direct_complete
> flag set during the preceding suspend transition, they may stay
> in a reset-power-on state indefinitely (until they are runtime-resumed
> and then suspended again).  That may not be a big deal from the
> individual device's perspective, but if the system is an SoC, it may
> be prevented from entering deep SoC-wide low-power states on idle
> because of that.
> 
> To prevent that from happening, force a runtime resume for devices
> with power.direct_complete set if the platform firmware was involved
> in the resume transition currently in progress.
> 
> Something similar was done by the ACPI PM domain, but regardless of
> the platform firmware involvement, and the new mechanism should be
> sufficient to replace that code, so drop it.

Maybe I'm not reading patch 1/2 correctly, but it looks like an
ordinary ACPI-based desktop PC will always believe the firmware was
involved in an S3 sleep transition.  If that's so then won't this
change defeat all the work being done by people trying to prevent
unneeded runtime resumes during system resume?  direct_complete would 
be useful only on non-ACPI systems.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-30 02:30 +0200
  Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been  reset by firmware kbuild test robot <lkp@intel.com> - 2015-09-30 02:40 +0200
  Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been  reset by firmware Alan Stern <stern@rowland.harvard.edu> - 2015-09-30 16:50 +0200
    Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-30 23:30 +0200
      Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been  reset by firmware Alan Stern <stern@rowland.harvard.edu> - 2015-10-01 16:50 +0200
        Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-01 23:50 +0200

csiph-web