1. 24 9月, 2013 1 次提交
  2. 06 8月, 2013 1 次提交
  3. 26 7月, 2013 1 次提交
  4. 15 7月, 2013 3 次提交
  5. 20 6月, 2013 1 次提交
  6. 25 3月, 2013 1 次提交
  7. 20 1月, 2013 1 次提交
  8. 17 1月, 2013 3 次提交
  9. 16 11月, 2012 1 次提交
  10. 15 11月, 2012 1 次提交
    • R
      ACPI / PM: Provide device PM functions operating on struct acpi_device · 078eb126
      Rafael J. Wysocki 提交于
      If the caller of acpi_bus_set_power() already has a pointer to the
      struct acpi_device object corresponding to the device in question, it
      doesn't make sense for it to go through acpi_bus_get_device(), which
      may be costly, because it involves acquiring the global ACPI
      namespace mutex.
      
      For this reason, export the function operating on struct acpi_device
      objects used internally by acpi_bus_set_power(), so that it may be
      called instead of acpi_bus_set_power() in the above case, and change
      its name to acpi_device_set_power().
      
      Additionally, introduce two inline wrappers for checking ACPI PM
      capabilities of devices represented by struct acpi_device objects.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      078eb126
  11. 25 9月, 2012 1 次提交
  12. 14 9月, 2012 1 次提交
    • R
      ACPI / PM: Infer parent power state from child if unknown, v2 · 8f7412a7
      Rafael J. Wysocki 提交于
      It turns out that there are ACPI BIOSes defining device objects with
      _PSx and without either _PSC or _PRx.  For devices corresponding to
      those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN
      and their initial power states are regarded as unknown as a result.
      If such a device is a parent of another power-manageable device, the
      child cannot be put into a low-power state through ACPI, because
      __acpi_bus_set_power() refuses to change power states of devices
      whose parents' power states are unknown.
      
      To work around this problem, observe that the ACPI power state of
      a device cannot be higher-power (lower-number) than the power state
      of its parent.  Thus, if the device's _PSC method or the
      configuration of its power resources indicates that the device is
      in D0, the device's parent has to be in D0 as well.  Consequently,
      if the parent's power state is unknown when we've just learned that
      its child's power state is D0, we can safely set the parent's
      power.state field to ACPI_STATE_D0.
      Tested-by: NAaron Lu <aaron.lu@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8f7412a7
  13. 04 6月, 2012 1 次提交
  14. 30 5月, 2012 2 次提交
    • R
      ACPI / PM: Make __acpi_bus_get_power() cover D3cold correctly · 38c92fff
      Rafael J. Wysocki 提交于
      After recent changes of the ACPI device power states definitions, if
      power resources are not used for the device's power management, the
      state returned by __acpi_bus_get_power() cannot exceed D3hot, because
      the return values of _PSC are 0 through 3.  However, if the _PR3
      method is not present for the device and _PS3 returns 3, we have to
      assume that the device is in D3cold, so the value returned by
      __acpi_bus_get_power() in that case should be 4.
      
      Similarly, acpi_power_get_inferred_state() should take the power
      resources for the D3hot state into account in general, so that it
      can return 3 if those resources are "on" or 4 (D3cold) otherwise.
      
      Fix the the above two issues and make sure that if both _PSC and
      _PR3 are present for the device, the power resources listed by _PR3
      will be used to determine if the number 3 returned by _PSC is meant
      to represent D3cold or D3hot.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      38c92fff
    • R
      ACPI / PM: Fix error messages in drivers/acpi/bus.c · 63a1a765
      Rafael J. Wysocki 提交于
      After recent changes of the ACPI device low-power states definitions
      kernel messages in drivers/acpi/bus.c need to be updated so that they
      include the correct names of the states in question (currently is
      "D3" for D3hot and "D4" for D3cold, which is incorrect).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      63a1a765
  15. 18 5月, 2012 1 次提交
    • R
      ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold · 5c7dd710
      Rafael J. Wysocki 提交于
      Commit 1cc0c998 ("ACPI: Fix D3hot v D3cold confusion") introduced a
      bug in __acpi_bus_set_power() and changed the behavior of
      acpi_pci_set_power_state() in such a way that it generally doesn't work
      as expected if PCI_D3hot is passed to it as the second argument.
      
      First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
      __acpi_bus_set_power() and the explicit_set flag is set for the D3cold
      state, the function will try to execute AML method called "_PS4", which
      doesn't exist.
      
      Fix this by adding a check to ensure that the name of the AML method
      to execute for transitions to ACPI_STATE_D3_COLD is correct in
      __acpi_bus_set_power().  Also make sure that the explicit_set flag
      for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
      acpi_power_transition() to avoid accessing power resources for
      ACPI_STATE_D3_COLD, because they don't exist.
      
      Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
      target state, the function will request a transition to
      ACPI_STATE_D3_HOT instead of ACPI_STATE_D3.  However,
      ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
      method is defined for the given device, which is rare.  This causes
      problems to happen on systems where devices were successfully put
      into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
      now.  In particular, some unused graphics adapters are not turned
      off as a result.
      
      To fix this issue restore the old behavior of
      acpi_pci_set_power_state(), which is to request a transition to
      ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
      PCI_D3cold is passed to it as the argument.
      
      This approach is not ideal, because generally power should not
      be removed from devices if PCI_D3hot is the target power state,
      but since this behavior is relied on, we have no choice but to
      restore it at the moment and spend more time on designing a
      better solution in the future.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=43228Reported-by: Nrocko <rockorequin@hotmail.com>
      Reported-by: NCristian Rodríguez <crrodriguez@opensuse.org>
      Reported-and-tested-by: NPeter <lekensteyn@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5c7dd710
  16. 30 3月, 2012 1 次提交
  17. 07 11月, 2011 1 次提交
  18. 03 8月, 2011 1 次提交
  19. 14 7月, 2011 1 次提交
    • H
      ACPI, APEI, Add APEI bit support in generic _OSC call · eccddd32
      Huang Ying 提交于
      In APEI firmware first mode, hardware error is reported by hardware to
      firmware firstly, then firmware reports the error to Linux in a GHES
      error record via POLL/SCI/IRQ/NMI etc.
      
      This may result in some issues if OS has no full APEI support.  So
      some firmware implementation will work in a back-compatible mode by
      default.  Where firmware will only notify OS in old-fashion, without
      GHES record.  For example, for a fatal hardware error, only NMI is
      signaled, no GHES record.
      
      To gain full APEI power on these machines, APEI bit in generic _OSC
      call can be specified to tell firmware that Linux has full APEI
      support.  This patch adds the APEI bit support in generic _OSC call.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      eccddd32
  20. 29 5月, 2011 1 次提交
  21. 15 3月, 2011 2 次提交
  22. 12 1月, 2011 8 次提交
  23. 26 10月, 2010 1 次提交
  24. 30 9月, 2010 1 次提交
  25. 29 9月, 2010 1 次提交
  26. 15 8月, 2010 2 次提交
    • Z
      ACPI: remove deprecated ACPI procfs I/F · 47f5c892
      Zhang Rui 提交于
      Rmove deprecated ACPI procfs I/F, including
      /proc/acpi/debug_layer
      /proc/acpi/debug_level
      /proc/acpi/info
      /proc/acpi/dsdt
      /proc/acpi/fadt
      /proc/acpi/sleep
      
      because the sysfs I/F is already available
      and has been working well for years.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      47f5c892
    • Z
      ACPI: introduce drivers/acpi/sysfs.c · 1c8fce27
      Zhang Rui 提交于
      Introduce drivers/acpi/sysfs.c.
      
      code for ACPI sysfs I/F, including
      #ifdef ACPI_DEBUG
      /sys/module/acpi/parameters/debug_layer
      /sys/module/acpi/parameters/debug_level
      /sys/module/acpi/parameters/trace_method_name
      /sys/module/acpi/parameters/trace_debug_layer
      /sys/module/acpi/parameters/trace_debug_level
      /sys/module/acpi/parameters/trace_state
      #endif
      /sys/module/acpi/parameters/acpica_version
      /sys/firmware/acpi/tables/
      /sys/firmware/acpi/interrupts/
      is moved to this file.
      
      No function change in this patch.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1c8fce27