1. 27 2月, 2010 11 次提交
    • R
      PM: Allow USB devices to suspend/resume asynchronously · 927bc916
      Rafael J. Wysocki 提交于
      Set power.async_suspend for USB devices, endpoints and interfaces,
      allowing them to be suspended and resumed asynchronously during
      system sleep transitions.
      
      The power.async_suspend flag is also set for devices that don't have
      suspend or resume callbacks, because otherwise they would make the
      main suspend/resume thread wait for their "asynchronous" children
      (during suspend) or parents (during resume), effectively negating the
      possible gains from executing these devices' suspend and resume
      callbacks asynchronously.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      927bc916
    • A
      USB: implement non-tree resume ordering constraints for PCI host controllers · 6d19c009
      Alan Stern 提交于
      This patch (as1331) adds non-tree ordering constraints needed for
      proper resume of PCI USB host controllers from hibernation.  The main
      issue is that non-high-speed devices must not be resumed before the
      high-speed root hub, because it is the ehci_bus_resume() routine which
      takes care of handing the device connection over to the companion
      controller.  If the device resume is attempted before the handover
      then the device won't be found and it will be treated as though it had
      disconnected.
      
      The patch adds a new field to the usb_bus structure; for each
      full/low-speed bus this field will contain a pointer to the companion
      high-speed bus (if one exists).  It is used during normal device
      resume; if the hs_companion pointer isn't NULL then we wait for the
      root-hub device on the hs_companion bus.
      
      A secondary issue is that an EHCI controlller shouldn't be resumed
      before any of its companions.  On some machines I have observed
      handovers failing if the companion controller is reinitialized after
      the handover.  Thus, the EHCI resume routine must wait for the
      companion controllers to be resumed.
      
      The patch also fixes a small bug in usb_hcd_pci_probe(); an error path
      jumps to the wrong label, causing a memory leak.
      
      [rjw: Fixed compilation for CONFIG_PM_SLEEP unset.]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      6d19c009
    • R
      PM: Allow PCI devices to suspend/resume asynchronously · a1e4d72c
      Rafael J. Wysocki 提交于
      Set power.async_suspend for all PCI devices and PCIe port services,
      so that they can be suspended and resumed in parallel with other
      devices they don't depend on in a known way (i.e. devices which are
      not their parents or children).
      
      This only affects the "regular" suspend and resume stages, which
      means in particular that the restoration of the PCI devices' standard
      configuration registers during resume will still be carried out
      synchronously (at the "early" resume stage).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      a1e4d72c
    • R
      PM: Allow device drivers to use dpm_wait() · f8824cee
      Rafael J. Wysocki 提交于
      There are some dependencies between devices (in particular, between
      EHCI USB controllers and their OHCI/UHCI siblings) which are not
      reflected by the structure of the device tree.  With synchronous
      suspend and resume these dependencies are taken into accout
      automatically, because the devices in question are always registered
      in the right order, but to meet these constraints with asynchronous
      suspend and resume the drivers of these devices will need to use
      dpm_wait() in their suspend/resume routines, so introduce a helper
      function allowing them to do that.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      f8824cee
    • R
      PM: Start asynchronous resume threads upfront · 97df8c12
      Rafael J. Wysocki 提交于
      It has been shown by testing that total device resume time can be
      reduced significantly (by as much as 50% or more) if the async
      threads executing some devices' resume routines are all started
      before the main resume thread starts to handle the "synchronous"
      devices.
      
      This is a consequence of the fact that the slowest devices tend to be
      located at the end of dpm_list, so their resume routines are started
      very late.  Consequently, they have to wait for all the preceding
      "synchronous" devices before their resume routines can be started
      by the main resume thread, even if they are "asynchronous".  By
      starting their async threads upfront we effectively move those
      devices towards the beginning of dpm_list, without breaking their
      ordering with respect to their parents and children.  As a result,
      their resume routines are started much earlier and we are able to
      save much more device resume time this way.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      97df8c12
    • R
      PM: Add facility for advanced testing of async suspend/resume · 5a2eb858
      Rafael J. Wysocki 提交于
      Add configuration switch CONFIG_PM_ADVANCED_DEBUG for compiling in
      extra PM debugging/testing code allowing one to access some
      PM-related attributes of devices from the user space via sysfs.
      
      If CONFIG_PM_ADVANCED_DEBUG is set, add sysfs attribute power/async
      for every device allowing the user space to access the device's
      power.async_suspend flag and modify it, if desired.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      5a2eb858
    • R
      PM: Add a switch for disabling/enabling asynchronous suspend/resume · 0e06b4a8
      Rafael J. Wysocki 提交于
      Add sysfs attribute /sys/power/pm_async allowing the user space to
      disable/enable asynchronous suspend/resume of devices.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      0e06b4a8
    • R
      PM: Asynchronous suspend and resume of devices · 5af84b82
      Rafael J. Wysocki 提交于
      Theoretically, the total time of system sleep transitions (suspend
      to RAM, hibernation) can be reduced by running suspend and resume
      callbacks of device drivers in parallel with each other.  However,
      there are dependencies between devices such that we're not allowed
      to suspend the parent of a device before suspending the device
      itself.  Analogously, we're not allowed to resume a device before
      resuming its parent.
      
      The most straightforward way to take these dependencies into accout
      is to start the async threads used for suspending and resuming
      devices at the core level, so that async_schedule() is called for
      each suspend and resume callback supposed to be executed
      asynchronously.
      
      For this purpose, introduce a new device flag, power.async_suspend,
      used to mark the devices whose suspend and resume callbacks are to be
      executed asynchronously (ie. in parallel with the main suspend/resume
      thread and possibly in parallel with each other) and helper function
      device_enable_async_suspend() allowing one to set power.async_suspend
      for given device (power.async_suspend is unset by default for all
      devices).  For each device with the power.async_suspend flag set the
      PM core will use async_schedule() to execute its suspend and resume
      callbacks.
      
      The async threads started for different devices as a result of
      calling async_schedule() are synchronized with each other and with
      the main suspend/resume thread with the help of completions, in the
      following way:
      (1) There is a completion, power.completion, for each device object.
      (2) Each device's completion is reset before calling async_schedule()
          for the device or, in the case of devices with the
          power.async_suspend flags unset, before executing the device's
          suspend and resume callbacks.
      (3) During suspend, right before running the bus type, device type
          and device class suspend callbacks for the device, the PM core
          waits for the completions of all the device's children to be
          completed.
      (4) During resume, right before running the bus type, device type and
          device class resume callbacks for the device, the PM core waits
          for the completion of the device's parent to be completed.
      (5) The PM core completes power.completion for each device right
          after the bus type, device type and device class suspend (or
          resume) callbacks executed for the device have returned.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      5af84b82
    • R
      PM: Add parent information to timing messages · 8cc6b39f
      Rafael J. Wysocki 提交于
      Add parent information to the messages printed by the suspend/resume
      core when initcall_debug is set.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8cc6b39f
    • R
      PM / Runtime: Add sysfs switch for disabling device run-time PM · 53823639
      Rafael J. Wysocki 提交于
      Add new device sysfs attribute, power/control, allowing the user
      space to block the run-time power management of the devices.  If this
      attribute is set to "on", the driver of the device won't be able to power
      manage it at run time (without breaking the rules) and the device will
      always be in the full power state (except when the entire system goes
      into a sleep state).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      53823639
    • L
      Lower USB storage settling delay to something more reasonable · a4a47bc0
      Linus Torvalds 提交于
      The five-second delay can be rather annoying, and makes the system
      appear much less responsive when you connect a USB drive.
      
      It's also not entirely clear that it is needed - the settling delay has
      at least historically been an issue on some Apple iPods, for example,
      and some devices have been reported to need even more than the old 5s
      delay.
      
      But before we penalize them all, let's see how bad it really is.  Some
      of the reasons for long delays seem to be actual historical kernel bugs
      that should probably never have been papered over with a delay in the
      first place (there's a Ubuntu bug report for 2.6.20 about a NULL pointer
      dereference unless 'delay_use' is 8 or more, for example).
      
      It also looks like some distros have already shipped with delay_use=0,
      so the five second default may well be totally historical.
      
      In other words: "Let's see if anybody screams".
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a4a47bc0
  2. 25 2月, 2010 2 次提交
  3. 24 2月, 2010 27 次提交
新手
引导
客服 返回
顶部