1. 05 4月, 2011 1 次提交
  2. 15 2月, 2011 2 次提交
    • J
      zd1211rw: move async iowrite16v up to callers · 8662b251
      Jussi Kivilinna 提交于
      Writing beacon to device happen through multiple write command calls.
      zd_usb_iowrite16v uses synchronous urb call and with multiple write
      commands in row causes high CPU usage.
      
      Make asynchronous zd_usb_iowrite16v_async available outside zd_usb.c
      and use where possible.
      
      This lower CPU usage from ~10% to ~2% on Intel Atom when running
      AP-mode with 100 TU beacon interval.
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8662b251
    • J
      zd1211rw: use async urb for write command · eefdbec1
      Jussi Kivilinna 提交于
      Writing beacon to device happen through multiple write command calls.
      zd_usb_iowrite16v uses synchronous urb call and with multiple write
      commands in row causes high CPU usage.
      
      This patch makes zd_usb_iowrite16v use asynchronous urb submit within
      zd_usb.c. zd_usb_iowrite16v_async_start is used to initiate writing
      multiple commands to device using zd_usb_iowrite16v_async. Each URB
      is delayed and submitted to device by next zd_usb_iowrite16v_async
      call or by call to zd_usb_iowrite16v_async_end. URBs submitted by
      zd_usb_iowrite16v_async have URB_NO_INTERRUPT set and last URB
      send by zd_usb_iowrite16v_async_end does not. This lower CPU
      usage when doing writes that require multiple URBs.
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      eefdbec1
  3. 05 2月, 2011 5 次提交
  4. 03 6月, 2010 1 次提交
  5. 29 1月, 2008 2 次提交
  6. 11 7月, 2007 1 次提交
    • D
      [PATCH] zd1211rw: Defer firmware load until first ifup · 74553aed
      Daniel Drake 提交于
      While playing with the firmware a while back, I discovered a way to
      access the device's entire address space before the firmware has been
      loaded.
      
      Previously we were loading the firmware early on (during probe) so that
      we could read the MAC address from the EEPROM and register a netdevice.
      Now that we can read the EEPROM without having firmware, we can defer
      firmware loading until later while still reading the MAC address early
      on.
      
      This has the advantage that zd1211rw can now be built into the kernel --
      previously if this was the case, zd1211rw would be loaded before the
      filesystem is available and firmware loading would fail.
      
      Firmware load and other device initialization operations now happen the
      first time the interface is brought up.
      
      Some architectural changes were needed: handling of the is_zd1211b flag
      was moved into the zd_usb structure, MAC address handling was obviously
      changed, and a preinit_hw stage was added (the order is now: init,
      preinit_hw, init_hw).
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      74553aed
  7. 06 2月, 2007 1 次提交
    • D
      [PATCH] zd1211rw: Remove addressing abstraction · 0ce34bc8
      Daniel Drake 提交于
      Instead of passing our own custom 32-bit addresses around and
      translating them, this patch makes all our register address constants
      absolute and removes the translation.
      
      There are two ugly parts:
       - fw_reg_addr() is needed to compute addresses of firmware registers, as this
         is dynamic based upon firmware
       - inc_addr() needs a small hack to handle byte vs word addressing
      
      However, both of those are only small, and we don't use fw_regs a whole
      lot anyway.
      
      The bonuses here include simplicity and improved driver readability. Also, the
      fact that registers are now referenced by 16-bit absolute addresses (as
      opposed to 32-bit pseudo addresses) means that over 2kb compiled code size has
      been shaved off.
      
      Includes some touchups and sparse fixes from Ulrich Kunitz.
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0ce34bc8
  8. 29 11月, 2006 1 次提交
  9. 26 9月, 2006 1 次提交
  10. 12 9月, 2006 1 次提交
  11. 15 8月, 2006 1 次提交
  12. 06 7月, 2006 1 次提交
    • D
      [PATCH] ZyDAS ZD1211 USB-WLAN driver · e85d0918
      Daniel Drake 提交于
      There are 60+ USB wifi adapters available on the market based on the ZyDAS
      ZD1211 chip.
      
      Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
      data operations are coordinated by the device driver. The ZD1211 chip sits
      alongside an RF transceiver which is also controlled by the driver. Our driver
      currently supports 2 RF types, we know of one other available in a few marketed
      products which we will be supporting soon.
      
      Our driver also supports the newer revision of ZD1211, called ZD1211B. The
      initialization and RF operations are slightly different for the new revision,
      but the main difference is 802.11e support. Our driver does not support the
      QoS features yet, but we think we know how to use them.
      
      This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
      ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
      up to them. Additionally, the firmware is redistributable and they have
      provided device specs.
      
      This driver has been written primarily by Ulrich Kunitz and myself. Graham
      Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
      developers of ieee80211 and softmac have made our lives so much easier- thanks!
      
      We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
      
      If there is enough time for review, we would like to aim for inclusion in
      2.6.18. The driver works nicely as a STA, and can connect to both open and
      encrypted networks (we are using software-based encryption for now). We will
      work towards supporting more advanced features in the future (ad-hoc, master
      mode, 802.11a, ...).
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e85d0918