1. 21 May, 2008 4 commits
  2. 14 May, 2008 2 commits
    • Bruno Randolf's avatar
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf authored
      
      
      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: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      566bfe5a
    • Harvey Harrison's avatar
      b43: replace limit_value macro with clamp_val · cdbf0846
      Harvey Harrison authored
      
      
      kernel-provided clamp_val is identical, delete the private limit_value helper.
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Cc: Michael Buesch <mb@bu3sch.de>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cdbf0846
  3. 07 May, 2008 3 commits
    • Johannes Berg's avatar
      mac80211: QoS related cleanups · e100bb64
      Johannes Berg authored
      
      
      This
       * makes the queue number passed to drivers a u16
         (as it will be with skb_get_queue_mapping)
       * removes the useless queue number defines
       * splits hw->queues into hw->queues/ampdu_queues
       * removes the debugfs files for per-queue counters
       * removes some dead QoS code
       * removes the beacon queue configuration for IBSS
         so that the drivers now never get a queue number
         bigger than (hw->queues + hw->ampdu_queues - 1)
         for tx and only in the range 0..hw->queues-1 for
         conf_tx.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e100bb64
    • Michael Buesch's avatar
      b43: Don't disable IRQs in mac_suspend · e40ac414
      Michael Buesch authored
      
      
      This patch removes the IRQ-disable from mac_suspend.
      The main advantage of this is to get rid of the IRQ-sync call in mac_suspend.
      We need to remove the MAC suspend bit from the IRQ service mask, as otherwise
      the IRQ handler would race with us.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e40ac414
    • Michael Buesch's avatar
      b43: Rewrite LO calibration algorithm · f5eda47f
      Michael Buesch authored
      
      
      This patch distributes the Local Oscillator calibration bursts over time,
      so that calibration only happens when it's actually needed.
      Currently we periodically perform a recalibration of the whole table.
      The table is huge and this takes lots of time. Additionally only small bits
      of the table are actually needed at a given time. So instead of maintaining
      a huge table with all possible calibration values, we create dynamic calibration
      settings that
      a) We only calibrate when they are actually needed.
      b) Are cached for some time until they expire.
      So a recalibration might happen if we need a calibration setting that's not
      cached, or if the active calibration setting expires.
      Currently the expire timeout is set to 30 seconds. We may raise that in future.
      
      This patch reduces overall memory consumption by nuking the
      huge static calibration tables.
      
      This patch has been tested on several 4306, 4311 and 4318 flavours.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f5eda47f
  4. 01 May, 2008 1 commit
  5. 30 Apr, 2008 1 commit
  6. 29 Apr, 2008 1 commit
  7. 23 Apr, 2008 3 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>
      b844eba2
  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
      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: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ba380013
  10. 08 Apr, 2008 7 commits
  11. 24 Mar, 2008 1 commit
  12. 13 Mar, 2008 1 commit
  13. 07 Mar, 2008 2 commits
  14. 06 Mar, 2008 1 commit
  15. 29 Feb, 2008 3 commits
  16. 15 Feb, 2008 3 commits
  17. 05 Feb, 2008 2 commits
  18. 31 Jan, 2008 2 commits
  19. 28 Jan, 2008 1 commit
    • Michael Buesch's avatar
      b43: Fix MAC control and microcode init · 1f7d87b0
      Michael Buesch authored
      
      
      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: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1f7d87b0