1. 25 4月, 2014 1 次提交
  2. 22 4月, 2014 1 次提交
  3. 09 4月, 2014 1 次提交
    • H
      ACPI: Update the ACPI spec information in Kconfig · c7f5220d
      Hanjun Guo 提交于
      The UEFI Forum included the ACPI spec in its portfolio in October 2013
      and will host future spec iterations, following the ACPI v5.0a release.
      
      A UEFI Forum working group named ACPI Specification Working Group (ASWG)
      has been established to handle future ACPI developments, any UEFI member
      can join the group and contribute to ACPI specification.
      
      So update the ownership and developers for ACPI in Kconfig accordingly,
      and add another website link to ACPI specification too.
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c7f5220d
  4. 07 4月, 2014 3 次提交
  5. 04 4月, 2014 1 次提交
  6. 26 3月, 2014 6 次提交
  7. 20 3月, 2014 1 次提交
  8. 19 3月, 2014 5 次提交
  9. 18 3月, 2014 7 次提交
  10. 14 3月, 2014 1 次提交
    • R
      ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states · a4e90bed
      Rafael J. Wysocki 提交于
      If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses
      the optional sleep control and sleep status registers for making
      the system enter sleep states (including S5), so it is not possible
      to use system sleep states or power it off using ACPI if the HW
      Reduced ACPI mode bit is set and those registers are not available.
      
      For this reason, add a new function, acpi_sleep_state_supported(),
      checking if the HW Reduced ACPI mode bit is set and whether or not
      system sleep states are usable in that case in addition to checking
      the return value of acpi_get_sleep_type_data() and make the ACPI
      sleep setup routines use that function to check the availability of
      system sleep states.
      
      Among other things, this prevents the kernel from attempting to
      use ACPI for powering off HW Reduced ACPI systems without the sleep
      control and sleep status registers, because ACPI power off doesn't
      have a chance to work on them.  That allows alternative power off
      mechanisms that may actually work to be used on those systems.  The
      affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell
      Desktop SDP and Ivy Bridge EP Demo depot.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=70931Reported-by: NAdam Williamson <awilliam@redhat.com>
      Tested-by: NAubrey Li <aubrey.li@linux.intel.com>
      Cc: 3.4+ <stable@vger.kernel.org> # 3.4+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a4e90bed
  11. 10 3月, 2014 1 次提交
  12. 06 3月, 2014 1 次提交
  13. 05 3月, 2014 2 次提交
  14. 04 3月, 2014 1 次提交
    • R
      ACPI / PM: Resume runtime-suspended devices later during system suspend · 92858c47
      Rafael J. Wysocki 提交于
      Runtime-suspended devices are resumed during system suspend by
      acpi_subsys_prepare() for two reasons: First, because they may need
      to be reprogrammed in order to change their wakeup settings and,
      second, because they may need to be operatonal for their children
      to be successfully suspended.  That is a problem, though, if there
      are many runtime-suspended devices that need to be resumed this
      way during system suspend, because the .prepare() PM callbacks of
      devices are executed sequentially and the times taken by them
      accumulate, which may increase the total system suspend time quite
      a bit.
      
      For this reason, move the resume of runtime-suspended devices up
      to the next phase of device suspend (during system suspend), except
      for the ones that have power.ignore_children set.  The exception is
      made, because the devices with power.ignore_children set may still
      be necessary for their children to be successfully suspended (during
      system suspend) and they won't be resumed automatically as a result
      of the runtime resume of their children.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      92858c47
  15. 03 3月, 2014 1 次提交
  16. 02 3月, 2014 2 次提交
  17. 27 2月, 2014 5 次提交