1. 07 10月, 2008 2 次提交
  2. 30 8月, 2008 2 次提交
    • M
      b43: Rewrite TX power adjustment · 18c8adeb
      Michael Buesch 提交于
      This patch rewrites the TX power recalculation algorithms to scale better
      with changed enviromnent. If there's low
      TX traffic, the power will be checked against the desired values
      every 60 seconds.
      If there is high TX traffic, the check is redone every 2 seconds. This improves
      the reaction times a lot and confuses the rate control less.
      It will also reduce the time it initially takes to tune to a new TX power
      value. With the old algorithm it could take about 30 to 45 seconds to settle to
      a new power value. This will happen in about two to four seconds now.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      18c8adeb
    • M
      b43: Implement dynamic PHY API · ef1a628d
      Michael Buesch 提交于
      This patch implements a dynamic "ops" based PHY API.
      This is needed in order to conveniently support future PHY types
      to avoid the "switch"-hell.
      
      This patch does not change any functionality. It just moves lots
      of code from one place to another and adjusts it for the changed
      data structures.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ef1a628d
  3. 30 7月, 2008 1 次提交
  4. 15 7月, 2008 1 次提交
    • J
      mac80211: fix TX sequence numbers · f591fa5d
      Johannes Berg 提交于
      This patch makes mac80211 assign proper sequence numbers to
      QoS-data frames. It also removes the old sequence number code
      because we noticed that only the driver or hardware can assign
      sequence numbers to non-QoS-data and especially management
      frames in a race-free manner because beacons aren't passed
      through mac80211's TX path.
      
      This patch also adds temporary code to the rt2x00 drivers to
      not break them completely, that code will have to be reworked
      for proper sequence numbers on beacons.
      
      It also moves sequence number assignment down in the TX path
      so no sequence numbers are assigned to frames that are dropped.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f591fa5d
  5. 27 6月, 2008 1 次提交
  6. 22 5月, 2008 2 次提交
  7. 15 5月, 2008 1 次提交
    • B
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf 提交于
      trying to clean up the signal/noise code. the previous code in mac80211 had
      confusing names for the related variables, did not have much definition of
      what units of signal and noise were provided and used implicit mechanisms from
      the wireless extensions.
      
      this patch introduces hardware capability flags to let the hardware specify
      clearly if it can provide signal and noise level values and which units it can
      provide. this also anticipates possible new units like RCPI in the future.
      
      for signal:
      
        IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
        IEEE80211_HW_SIGNAL_DB     - dB difference to unspecified reference point
        IEEE80211_HW_SIGNAL_DBM    - dBm, difference to 1mW
      
      for noise we currently only have dBm:
      
        IEEE80211_HW_NOISE_DBM     - dBm, difference to 1mW
      
      if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
      to provide the maximum value (max_signal) it reports in order for applications
      to make sense of the signal values.
      
      i tried my best to find out for each driver what it can provide and update it
      but i'm not sure (?) for some of them and used the more conservative guess in
      doubt. this can be fixed easily after this patch has been merged by changing
      the hardware flags of the driver.
      
      DRIVER          SIGNAL    MAX	NOISE   QUAL
      -----------------------------------------------------------------
      adm8211         unspec(?) 100   n/a     missing
      at76_usb        unspec(?) (?)   unused  missing
      ath5k           dBm             dBm     percent rssi
      b43legacy       dBm             dBm     percent jssi(?)
      b43             dBm             dBm     percent jssi(?)
      iwl-3945        dBm             dBm     percent snr+more
      iwl-4965        dBm             dBm     percent snr+more
      p54             unspec    127   n/a     missing
      rt2x00          dBm	        n/a     percent rssi+tx/rx frame success
        rt2400        dBm             n/a
        rt2500pci     dBm             n/a
        rt2500usb     dBm             n/a
        rt61pci       dBm             n/a
        rt73usb       dBm             n/a
      rtl8180         unspec(?) 65    n/a     (?)
      rtl8187         unspec(?) 65    (?)     noise(?)
      zd1211          dB(?)     100   n/a     percent
      
      drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      566bfe5a
  8. 08 5月, 2008 1 次提交
  9. 09 4月, 2008 2 次提交
    • M
      b43: Add more N-PHY stuff · 7b584163
      Michael Buesch 提交于
      This adds some minor stuff for N-PHY support. Nothing special.
      Adds Analog switching and some TODOs for RSSI processing.
      Just a patch I had floating around for quite some time now.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7b584163
    • M
      b43: Add PIO support for PCMCIA devices · 5100d5ac
      Michael Buesch 提交于
      This adds PIO support back (D'oh!) for PCMCIA devices.
      This is a complete rewrite of the old PIO code. It does actually work
      and we get reasonable performance out of it on a modern machine.
      On a PowerBook G4 I get a few MBit for TX and a few more for RX.
      So it doesn't work as well as DMA (of course), but it's a _lot_ faster
      than the old PIO code (only got a few kBit with that).
      
      The limiting factor is the host CPU speed. So it will generate 100%
      CPU usage when the network interface is heavily loaded. A voluntary preemption
      point in the RX path makes sure Desktop Latency isn't hurt.
      
      PIO is needed for 16bit PCMCIA devices, as we really don't want to poke with
      the braindead DMA mechanisms on PCMCIA sockets. Additionally, not all
      PCMCIA sockets do actually support DMA in 16bit mode (mine doesn't).
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5100d5ac
  10. 08 3月, 2008 1 次提交
  11. 01 3月, 2008 2 次提交
  12. 01 2月, 2008 2 次提交
  13. 29 1月, 2008 10 次提交
  14. 09 1月, 2008 1 次提交
  15. 11 10月, 2007 2 次提交