1. 28 May, 2004 6 commits
    • Todd Poynor's avatar
      [PATCH] Fix for leave-runtime-suspended-devices-off-at-system-resume.patch · 9e6b95c3
      Todd Poynor authored
      A patch to fix my previous
      leave-runtime-suspended-devices-off-at-system-resume patch; the new
      changes save a copy of power.power_state in order to know whether to
      resume a device, independently of mods to that field by a driver suspend
      routine.  This fixes 2.6.7-rc1-mm1 in the same fashion as the updated
      2.6.6 patch sent previously.
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      9e6b95c3
    • Greg Kroah-Hartman's avatar
      Merge kroah.com:/home/greg/linux/BK/bleed-2.6 · 5bb8ea44
      Greg Kroah-Hartman authored
      into kroah.com:/home/greg/linux/BK/driver-2.6
      5bb8ea44
    • Greg Kroah-Hartman's avatar
    • Greg Kroah-Hartman's avatar
      [PATCH] Report which device failed to suspend · 5ca5b409
      Greg Kroah-Hartman authored
      Based on a patch from Nickolai Zeldovich <kolya@MIT.EDU> but put into the
      proper place by me.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      5ca5b409
    • Todd Poynor's avatar
      [PATCH] Leave runtime suspended devices off at system resume · b8ff3f6b
      Todd Poynor authored
      Currently all devices are resumed at system resume time, including any
      that were individually powered off ("at runtime") prior to the system
      suspend.  In certain cases it can be nice to force back on individually
      suspended devices, such as the display, but hopefully this policy can be
      left up to userspace power managers; the kernel should probably honor
      the settings previously made by userspace/drivers.  This seems
      preferable to requiring a power-conscious system to re-suspend devices
      after a system resume; furthermore, for certain platforms (such as
      XScale PXA27X) there can be disastrous consequences of powering up
      devices when the system is in a state incompatible with operation of the
      device.
      
      Suggested patch does this:
      
      (1) At system resume, checks power_state to see if the device was
      suspended prior to system suspend, and skips powering on the device if
      so.
      
      (2) Does not re-suspend an already-suspended device at system suspend
      (using a different method than is currently employed, which reorders the
      list, see #3).
      
      (3) Preserves the active/off device list order despite the above changes
      to suspend/resume behavior, to avoid dependency problems that tend to
      occur when the list is reordered.
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      b8ff3f6b
    • Todd Poynor's avatar
      [PATCH] Device runtime suspend/resume fixes · 98e1a74e
      Todd Poynor authored
      (1) Set device power state at runtime resume (as is done for runtime
      suspend) so that a later suspend does not think the device is still
      suspended (refusing to suspend it again).
      
      (2) Move devices from the active list to the off list only when
      suspending all devices as part of a system suspend, not for runtime
      suspend.  This matches the resume code, which only moves devices from
      off to active during system resume, such that runtime resume currently
      doesn't move the suspended device back to the active list.  (This also
      avoids reordering the device list for runtime suspends; the list is in
      order of registration and suspend/resume works best that way -- granted,
      more sweeping improvements in how device dependencies are accounted for
      in the suspend/resume order are also needed someday.)
      
      Runtime device suspend/resume is in some cases used frequently on
      battery-powered embedded devices, to save additional power and to handle
      device power state interactions with overall system power state on
      certain platforms.
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      98e1a74e
  2. 27 May, 2004 1 commit
  3. 28 May, 2004 3 commits
  4. 27 May, 2004 30 commits