1. 13 6月, 2009 2 次提交
    • A
      PM core: rename suspend and resume functions · d1616302
      Alan Stern 提交于
      This patch (as1241) renames a bunch of functions in the PM core.
      Rather than go through a boring list of name changes, suffice it to
      say that in the end we have a bunch of pairs of functions:
      
      	device_resume_noirq	dpm_resume_noirq
      	device_resume		dpm_resume
      	device_complete		dpm_complete
      	device_suspend_noirq	dpm_suspend_noirq
      	device_suspend		dpm_suspend
      	device_prepare		dpm_prepare
      
      in which device_X does the X operation on a single device and dpm_X
      invokes device_X for all devices in the dpm_list.
      
      In addition, the old dpm_power_up and device_resume_noirq have been
      combined into a single function (dpm_resume_noirq).
      
      Lastly, dpm_suspend_start and dpm_resume_end are the renamed versions
      of the former top-level device_suspend and device_resume routines.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d1616302
    • M
      PM: Rename device_power_down/up() · e39a71ef
      Magnus Damm 提交于
      Rename the functions performing "_noirq" dev_pm_ops
      operations from device_power_down() and device_power_up()
      to device_suspend_noirq() and device_resume_noirq().
      
      The new function names are chosen to show that the functions
      are responsible for calling the _noirq() versions to finalize
      the suspend/resume operation. The current function names do
      not perform power down/up anymore so the names may be misleading.
      
      Global function renames:
      - device_power_down() -> device_suspend_noirq()
      - device_power_up() -> device_resume_noirq()
      
      Static function renames:
      - suspend_device_noirq() -> __device_suspend_noirq()
      - resume_device_noirq() -> __device_resume_noirq()
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NLen Brown <lenb@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      e39a71ef
  2. 25 5月, 2009 1 次提交
    • R
      PM: Do not hold dpm_list_mtx while disabling/enabling nonboot CPUs · 32bdfac5
      Rafael J. Wysocki 提交于
      We shouldn't hold dpm_list_mtx while executing
      [disable|enable]_nonboot_cpus(), because theoretically this may lead
      to a deadlock as shown by the following example (provided by Johannes
      Berg):
      
      CPU 3       CPU 2                     CPU 1
                                            suspend/hibernate
                  something:
                  rtnl_lock()               device_pm_lock()
                                             -> mutex_lock(&dpm_list_mtx)
      
                  mutex_lock(&dpm_list_mtx)
      
      linkwatch_work
       -> rtnl_lock()
                                            disable_nonboot_cpus()
                                             -> flush CPU 3 workqueue
      
      Fortunately, device drivers are supposed to stop any activities that
      might lead to the registration of new device objects way before
      disable_nonboot_cpus() is called, so it shouldn't be necessary to
      hold dpm_list_mtx over the entire late part of device suspend and
      early part of device resume.
      
      Thus, during the late suspend and the early resume of devices acquire
      dpm_list_mtx only when dpm_list is going to be traversed and release
      it right after that.
      
      This patch is reported to fix the regressions tracked as
      http://bugzilla.kernel.org/show_bug.cgi?id=13245.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NMiles Lane <miles.lane@gmail.com>
      Tested-by: NMing Lei <tom.leiming@gmail.com>
      32bdfac5
  3. 16 5月, 2009 1 次提交
  4. 25 4月, 2009 1 次提交
    • R
      PM/Hibernate: Fix waiting for image device to appear on resume · 0c8454f5
      Rafael J. Wysocki 提交于
      Commit c7510859 ("PM/Hibernate: Wait for
      SCSI devices scan to complete during resume") added a call to
      scsi_complete_async_scans() to software_resume(), so that it waited for
      the SCSI scanning to complete, but the call was added at a wrong place.
      
      Namely, it should have been added after wait_for_device_probe(), which
      is called only if the image partition hasn't been specified yet.  Also,
      it's reasonable to check if the image partition is present and only wait
      for the device probing and SCSI scanning to complete if it is not the
      case.
      
      Additionally, since noresume is checked right at the beginning of
      software_resume() and the function returns immediately if it's set, it
      doesn't make sense to check it once again later.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0c8454f5
  5. 20 4月, 2009 1 次提交
    • R
      PM/Suspend: Introduce two new platform callbacks to avoid breakage · 6a7c7eaf
      Rafael J. Wysocki 提交于
      Commit 900af0d9 (PM: Change suspend
      code ordering) changed the ordering of suspend code in such a way
      that the platform .prepare() callback is now executed after the
      device drivers' late suspend callbacks have run.  Unfortunately, this
      turns out to break ARM platforms that need to talk via I2C to power
      control devices during the .prepare() callback.
      
      For this reason introduce two new platform suspend callbacks,
      .prepare_late() and .wake(), that will be called just prior to
      disabling non-boot CPUs and right after bringing them back on line,
      respectively, and use them instead of .prepare() and .finish() for
      ACPI suspend.  Make the PM core execute the .prepare() and .finish()
      platform suspend callbacks where they were executed previously (that
      is, right after calling the regular suspend methods provided by
      device drivers and right before executing their regular resume
      methods, respectively).
      
      It is not necessary to make analogous changes to the hibernation
      code and data structures at the moment, because they are only used
      by ACPI platforms.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NLen Brown <len.brown@intel.com>
      6a7c7eaf
  6. 15 4月, 2009 1 次提交
  7. 14 4月, 2009 1 次提交
  8. 01 4月, 2009 2 次提交
  9. 31 3月, 2009 3 次提交
    • R
      PM: Change hibernation code ordering · 4aecd671
      Rafael J. Wysocki 提交于
      Change the ordering of the hibernation core code so that the platform
      "prepare" callbacks are executed and the nonboot CPUs are disabled
      after calling device drivers' "late suspend" methods.
      
      This change (along with the previous analogous change of the suspend
      core code) will allow us to rework the PCI PM core so that the power
      state of devices is changed in the "late" phase of suspend (and
      analogously in the "early" phase of resume), which in turn will allow
      us to avoid the race condition where a device using shared interrupts
      is put into a low power state with interrupts enabled and then an
      interrupt (for another device) comes in and confuses its driver.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      4aecd671
    • R
      PM: Change suspend code ordering · 900af0d9
      Rafael J. Wysocki 提交于
      Change the ordering of the suspend core code so that the platform
      "prepare" callback is executed and the nonboot CPUs are disabled
      after calling device drivers' "late suspend" methods.
      
      This change will allow us to rework the PCI PM core so that the power
      state of devices is changed in the "late" phase of suspend (and
      analogously in the "early" phase of resume), which in turn will allow
      us to avoid the race condition where a device using shared interrupts
      is put into a low power state with interrupts enabled and then an
      interrupt (for another device) comes in and confuses its driver.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      900af0d9
    • R
      PM: Rework handling of interrupts during suspend-resume · 2ed8d2b3
      Rafael J. Wysocki 提交于
      Use the functions introduced in by the previous patch,
      suspend_device_irqs(), resume_device_irqs() and check_wakeup_irqs(),
      to rework the handling of interrupts during suspend (hibernation) and
      resume.  Namely, interrupts will only be disabled on the CPU right
      before suspending sysdevs, while device drivers will be prevented
      from receiving interrupts, with the help of the new helper function,
      before their "late" suspend callbacks run (and analogously during
      resume).
      
      In addition, since the device interrups are now disabled before the
      CPU has turned all interrupts off and the CPU will ACK the interrupts
      setting the IRQ_PENDING bit for them, check in sysdev_suspend() if
      any wake-up interrupts are pending and abort suspend if that's the
      case.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      2ed8d2b3
  10. 30 3月, 2009 1 次提交
  11. 23 2月, 2009 1 次提交
  12. 22 2月, 2009 4 次提交
  13. 19 2月, 2009 1 次提交
  14. 18 2月, 2009 1 次提交
  15. 27 1月, 2009 1 次提交
    • R
      Hibernation: Introduce system_entering_hibernation · abfe2d7b
      Rafael J. Wysocki 提交于
      Introduce boolean function system_entering_hibernation() returning
      'true' during the last phase of hibernation, in which devices are
      being put into low power states and the sleep state (for example,
      ACPI S4) is finally entered.
      
      Some device drivers need such a function to check if the system is
      in the final phase of hibernation.  In particular, some SATA drivers
      are going to use it for blacklisting systems in which the disks
      should not be spun down during the last phase of hibernation (the
      BIOS will do that anyway).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      abfe2d7b
  16. 17 1月, 2009 2 次提交
  17. 07 1月, 2009 1 次提交
  18. 01 1月, 2009 1 次提交
  19. 19 12月, 2008 5 次提交
  20. 04 12月, 2008 1 次提交
  21. 23 11月, 2008 1 次提交
  22. 19 11月, 2008 1 次提交
  23. 02 11月, 2008 1 次提交
  24. 21 10月, 2008 3 次提交
  25. 20 10月, 2008 2 次提交
    • M
      container freezer: skip frozen cgroups during power management resume · 5a06915c
      Matt Helsley 提交于
      When a system is resumed after a suspend, it will also unfreeze frozen
      cgroups.
      
      This patchs modifies the resume sequence to skip the tasks which are part
      of a frozen control group.
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a06915c
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0