1. 13 Jun, 2008 1 commit
  2. 28 May, 2008 2 commits
  3. 21 May, 2008 1 commit
  4. 01 May, 2008 1 commit
  5. 30 Apr, 2008 1 commit
  6. 29 Apr, 2008 1 commit
  7. 23 Apr, 2008 4 commits
  8. 19 Apr, 2008 1 commit
    • Rafael J. Wysocki's avatar
      PM: Remove destroy_suspended_device() · b844eba2
      Rafael J. Wysocki authored
      After 2.6.24 there was a plan to make the PM core acquire all device
      semaphores during a suspend/hibernation to protect itself from
      concurrent operations involving device objects.  That proved to be
      too heavy-handed and we found a better way to achieve the goal, but
      before it happened, we had introduced the functions
      device_pm_schedule_removal() and destroy_suspended_device() to allow
      drivers to "safely" destroy a suspended device and we had adapted some
      drivers to use them.  Now that these functions are no longer necessary,
      it seems reasonable to remove them and modify their users to use the
      normal device unregistration instead.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  9. 16 Apr, 2008 1 commit
    • Michael Buesch's avatar
      b43: Add fastpath to b43_mac_suspend() · ba380013
      Michael Buesch authored
      This adds a fastpath for the common workloads to the
      MAC suspend flushing.
      In common workloads the FIFO flush will take between 100 and
      200 microseconds. So we want to avoid calling msleep() in the
      common case, as it will waste over 800 microseconds + scheduler
      This fastpath will hit in workloads where only small chunks
      of data are transmitted (downloading a file) or when a TX rate bigger
      or equal to 24MBit/s is used when transmitting lots of stuff (iperf).
      So in the commonly used workloads it will basically always hit.
      In case the fastpath is not hit, there's no real performance or latency
      disadvantage from that.
      And yes, I measured this. So this is not one of these
      bad Programmer Likeliness Assumptions that are always wrong. ;)
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 15 Apr, 2008 1 commit
    • Michael Buesch's avatar
      ssb: Fix usage of struct device used for DMAing · 4ac58469
      Michael Buesch authored
      This fixes DMA on architectures where DMA is nontrivial, like PPC64.
      We must use the host-device's (PCI) struct device for any DMA
      operation instead of the SSB device. For this we add a new
      struct device pointer to the SSB device structure that will always
      point to the right device for DMAing.
      Without this patch b43 and b44 drivers won't work on complex-DMA
      architectures, that for example need dev->archdata for DMA operations.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 08 Apr, 2008 9 commits
  12. 01 Apr, 2008 2 commits
  13. 25 Mar, 2008 1 commit
  14. 24 Mar, 2008 2 commits
  15. 13 Mar, 2008 3 commits
  16. 07 Mar, 2008 4 commits
  17. 06 Mar, 2008 1 commit
  18. 29 Feb, 2008 4 commits