1. 23 10月, 2008 1 次提交
    • R
      ACPI suspend: Fix CONFIG_ACPI_SLEEP dependence and some compilation warnings · 5d1e072b
      Rafael J. Wysocki 提交于
      Initially CONFIG_PM_SLEEP was defined as
      CONFIG_SUSPEND || CONFIG_HIBERNATION and some ACPI code, most
      importantly the code in drivers/acpi/main.c, was written with this
      assumption.  Currently, however, CONFIG_PM_SLEEP is also set when
      CONFIG_XEN_SAVE_RESTORE is set.
      
      This causes some compilation warnings to appear in
      drivers/acpi/main.c if both CONFIG_SUSPEND and CONFIG_HIBERNATION
      are unset and CONFIG_PM_SLEEP is set (this was impossible before).
      To fix this problem, redefine CONFIG_ACPI_SLEEP do depend directly
      on CONFIG_SUSPEND || CONFIG_HIBERNATION, as originally intended, and
      use it instead of CONFIG_PM_SLEEP in drivers/acpi/main.c, wherever
      appropriate.
      
      Additionally, move the acpi_target_sleep_state definition from under
      the #ifdef to prevent compilation from failing in some cases.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      5d1e072b
  2. 25 7月, 2008 2 次提交
  3. 17 7月, 2008 2 次提交
  4. 08 7月, 2008 1 次提交
    • R
      PCI ACPI: Rework PCI handling of wake-up · eb9d0fe4
      Rafael J. Wysocki 提交于
      * Introduce function acpi_pm_device_sleep_wake() for enabling and
        disabling the system wake-up capability of devices that are power
        manageable by ACPI.
      
      * Introduce function acpi_bus_can_wakeup() allowing other (dependent)
        subsystems to check if ACPI is able to enable the system wake-up
        capability of given device.
      
      * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
        for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().
      
      * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
        for the ACPI 'driver' make it use acpi_bus_can_wakeup().
      
      * Move the PME# handlig code out of pci_enable_wake() and split it
        into two functions, pci_pme_capable() and pci_pme_active(),
        allowing the caller to check if given device is capable of
        generating PME# from given power state and to enable/disable the
        device's PME# functionality, respectively.
      
      * Modify pci_enable_wake() to use the new ACPI callbacks and the new
        PME#-related functions.
      
      * Drop the generic .platform_enable_wakeup() callback that is not
        used any more.
      
      * Introduce device_set_wakeup_capable() that will set the
        power.can_wakeup flag of given device.
      
      * Rework PCI device PM initialization so that, if given device is
        capable of generating wake-up events, either natively through the
        PME# mechanism, or with the help of the platform, its
        power.can_wakeup flag is set and its power.should_wakeup flag is
        unset as appropriate.
      
      * Make ACPI set the power.can_wakeup flag for devices found to be
        wake-up capable by it.
      
      * Make the ACPI wake-up code enable/disable GPEs for devices that
        have the wakeup.flags.prepared flag set (which means that their
        wake-up power has been enabled).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      eb9d0fe4
  5. 05 7月, 2008 1 次提交
  6. 13 6月, 2008 1 次提交
    • R
      Suspend-related patches for 2.6.27 · d8f3de0d
      Rafael J. Wysocki 提交于
      ACPI PM: Add possibility to change suspend sequence
      
      There are some systems out there that don't work correctly with
      our current suspend/hibernation code ordering.  Provide a workaround
      for these systems allowing them to pass 'acpi_sleep=old_ordering' in
      the kernel command line so that it will use the pre-ACPI 2.0 ("old")
      suspend code ordering.
      
      Unfortunately, this requires us to add a platform hook to the
      resuming of devices for recovering the platform in case one of the
      device drivers' .suspend() routines returns error code.  Namely,
      ACPI 1.0 specifies that _PTS should be called before suspending
      devices, but _WAK still should be called before resuming them in
      order to undo the changes made by _PTS.  However, if there is an
      error during suspending devices, they are automatically resumed
      without returning control to the PM core, so the _WAK has to be
      called from within device_resume() in that cases.
      
      The patch also reorders and refactors the ACPI suspend/hibernation
      code to avoid duplication as far as reasonably possible.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d8f3de0d
  7. 12 6月, 2008 2 次提交
  8. 29 4月, 2008 1 次提交
  9. 02 4月, 2008 1 次提交
    • R
      ACPI PM: Restore the 2.6.24 suspend ordering · 7731ce63
      Rafael J. Wysocki 提交于
      Some time ago it turned out that our suspend code ordering broke some
      NVidia-based systems that hung if _PTS was executed with one of the PCI
      devices, specifically a USB controller, in a low power state.
      
      Then, it was noticed that the suspend code ordering was not compliant
      with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and
      it was argued that the code had to be changed for that reason (ref.
      http://bugzilla.kernel.org/show_bug.cgi?id=9528).
      
      So we did, but evidently we did wrong, because it's now turning out that
      some systems have been broken by this change. Refs:
      	http://bugzilla.kernel.org/show_bug.cgi?id=10340
      	https://bugzilla.novell.com/show_bug.cgi?id=374217#c16
      
      [ I said at that time that something like this might happend, but the
        majority of people involved thought that it was improbable due to the
        necessity to preserve the compliance of hardware with ACPI 1.0. ]
      
      This actually is a quite serious regression from 2.6.24.
      
      Moreover, the ACPI 1.0 ordering of suspend code introduced another issue
      that I have only noticed recently.  Namely, if the suspend of one of
      devices fails, the already suspended devices will be resumed without
      executing _WAK before, which leads to problems on some systems (for
      example, in such situations thermal management is broken on my HP
      nx6325).  Consequently, it also breaks suspend debugging on the affected
      systems.
      
      Note also, that the requirement to execute _PTS before suspending
      devices does not really make sense, because the device in question may
      be put into a low power state at run time for a reason unrelated to a
      system-wide suspend.
      
      For the reasons outlined above, the change of the suspend ordering
      should be reverted, which is done by the patch below.
      
      [ Felix Möller: "I am the reporter from the original Novell Bug:
      
      	https://bugzilla.novell.com/show_bug.cgi?id=374217
      
        I just tried current git head (two hours ago) with the patch (the one
        from the beginning of this thread) from Rafael and without it.  With
        the patch my MacBook does suspend without it does not." ]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NFelix Möller <felix@derklecks.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7731ce63
  10. 11 3月, 2008 1 次提交
  11. 07 2月, 2008 1 次提交
  12. 02 2月, 2008 9 次提交
  13. 12 1月, 2008 1 次提交
  14. 26 10月, 2007 2 次提交
  15. 19 10月, 2007 5 次提交
  16. 10 10月, 2007 2 次提交
  17. 28 9月, 2007 1 次提交
  18. 26 9月, 2007 2 次提交
  19. 22 9月, 2007 1 次提交
  20. 21 9月, 2007 1 次提交
  21. 25 8月, 2007 1 次提交
  22. 30 7月, 2007 1 次提交
    • R
      Introduce CONFIG_SUSPEND for suspend-to-Ram and standby · 296699de
      Rafael J. Wysocki 提交于
      Introduce CONFIG_SUSPEND representing the ability to enter system sleep
      states, such as the ACPI S3 state, and allow the user to choose SUSPEND
      and HIBERNATION independently of each other.
      
      Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has
      been chosen and the kernel is intended for SMP systems.
      
      Also, introduce CONFIG_PM_SLEEP which is automatically selected if
      CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the
      code needed for both suspend and hibernation.
      
      The top-level power management headers and the ACPI code related to
      suspend and hibernation are modified to use the new definitions (the
      changes in drivers/acpi/sleep/main.c are, mostly, moving code to reduce
      the number of ifdefs).
      
      There are many other files in which CONFIG_PM can be replaced with
      CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in
      the future.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      296699de