1. 17 4月, 2008 1 次提交
    • M
      b43: Add fastpath to b43_mac_suspend() · ba380013
      Michael Buesch 提交于
      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
      overhead.
      
      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: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba380013
  2. 16 4月, 2008 1 次提交
    • M
      ssb: Fix usage of struct device used for DMAing · 4ac58469
      Michael Buesch 提交于
      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: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4ac58469
  3. 09 4月, 2008 9 次提交
  4. 02 4月, 2008 2 次提交
  5. 26 3月, 2008 1 次提交
  6. 25 3月, 2008 2 次提交
  7. 14 3月, 2008 3 次提交
  8. 08 3月, 2008 4 次提交
  9. 07 3月, 2008 1 次提交
  10. 01 3月, 2008 4 次提交
  11. 28 2月, 2008 1 次提交
  12. 16 2月, 2008 3 次提交
  13. 07 2月, 2008 1 次提交
  14. 06 2月, 2008 3 次提交
  15. 01 2月, 2008 3 次提交
  16. 29 1月, 2008 1 次提交
    • M
      b43: Fix MAC control and microcode init · 1f7d87b0
      Michael Buesch 提交于
      This zeros out all microcode related memory before loading
      the microcode.
      
      This also fixes initialization of the MAC control register.
      The _only_ place where we overwrite the contents of the MAC control
      register is at the beginning of b43_chip_init().
      All other places must do read() -> mask/set -> write() to not
      overwrite existing bits.
      
      This also adds a longer delay for waiting for the microcode
      to initialize itself. It seems that the current timeout is sufficient
      on all available devices, but there's no real reason why we shouldn't
      wait for up to one second. Slow embedded devices might exist.
      Better safe than sorry.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1f7d87b0