An error occurred fetching the project authors.
  1. 19 Sep, 2011 1 commit
  2. 16 Sep, 2011 3 commits
  3. 30 Aug, 2011 1 commit
  4. 29 Aug, 2011 1 commit
  5. 24 Aug, 2011 1 commit
  6. 19 May, 2011 1 commit
  7. 19 Apr, 2011 1 commit
    • Felix Fietkau's avatar
      ath9k: fix powersave frame filtering/buffering in AP mode · 5519541d
      Felix Fietkau authored
      This patch fixes a long standing issue of pending packets in the queue being
      sent (and retransmitted many times) to sleeping stations.
      This was made worse by aggregation through driver-internal retransmitting
      of A-MDPU subframes.
      Previously the hardware tx filter was cleared unconditionally for every
      single packet - with this patch it uses the IEEE80211_TX_CTL_CLEAR_PS_FILT
      for unaggregated frames.
      A sta_notify driver op is added to stop aggregation for stations when they
      enter powersave mode. Subframes stay buffered inside the driver, to ensure
      that the BlockAck window keeps a sane state.
      Since the driver uses software aggregation, the clearing of the tx filter
      needs to be handled by the driver instead of mac80211 for aggregated frames.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5519541d
  8. 12 Apr, 2011 1 commit
    • Felix Fietkau's avatar
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau authored
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
      hardware (before AR9380) after an rx stop has been requested.
      
      This typically shows up in the kernel log with messages like these:
      
      ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
      Call Trace:
      [<8023f0e8>] dump_stack+0x8/0x34
      [<80075050>] warn_slowpath_common+0x78/0xa4
      [<80075094>] warn_slowpath_null+0x18/0x24
      [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
      [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
      [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
      
      When this happens, the state that the MAC enters is easy to identify and
      does not result in bogus DMA traffic, however to ensure a working state
      after a channel change, the hardware should still be reset.
      
      This patch adds detection for this specific MAC state, after which the above
      warnings completely disappear in my tests.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5882da02
  9. 14 Mar, 2011 2 commits
    • Felix Fietkau's avatar
      ath9k: improve reliability of beacon transmission and stuck beacon handling · efff395e
      Felix Fietkau authored
      ath9k calls ath9k_hw_stoptxdma every time it sends a beacon, however there
      is not much point in doing that if the previous beacon and mcast traffic
      went out properly. On AR9380, calling that function too often can result
      in an increase of stuck beacons due to differences in the handling of the
      queue enable/disable functionality.
      
      With this patch, the queue will only be explicitly stopped if the previous
      data frames were not sent successfully. With the beacon code being the
      only remaining user of ath9k_hw_stoptxdma, this function can be simplified
      in order to remove the now pointless attempts at waiting for transmission
      completion, which would never happen at this point due to the different
      method of tx scheduling of the beacon queue.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      efff395e
    • Felix Fietkau's avatar
      ath9k: fix stopping tx dma on reset · 0d51cccc
      Felix Fietkau authored
      In some situations, stopping Tx DMA frequently fails, leading to messages
      like this:
      
      ath: Failed to stop TX DMA in 100 msec after killing last frame
      ath: Failed to stop TX DMA!
      
      This patch uses a few MAC features to abort DMA globally instead of iterating
      over all hardware queues and attempting to stop them individually.
      Not only is that faster and works with a shorter timeout, it also makes the
      process much more reliable.
      
      With this change, I can no longer trigger these messages on AR9380,
      and on AR9280 they become much more rare.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0d51cccc
  10. 28 Jan, 2011 1 commit
  11. 24 Nov, 2010 1 commit
  12. 09 Nov, 2010 3 commits
    • Felix Fietkau's avatar
      ath9k_hw: optimize all descriptor access functions · ada9f1ca
      Felix Fietkau authored
      Because all of the descriptor data structures are marked as __packed, GCC
      assumes the worst case wrt. alignment and generates unaligned load/store
      instructions on MIPS for access to all fields.
      Since descriptors always have to be 4-byte-aligned, we can just mark the
      data structures with __aligned(4), which allows GCC to generate much more
      efficient code.
      Verified through disassembly and OProfile comparisons.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ada9f1ca
    • Felix Fietkau's avatar
      ath9k_hw: optimize tx status descriptor processing · e0e9bc82
      Felix Fietkau authored
      Disassembly shows, that at least on MIPS, the compiler generates a lot of
      memory accesses to the same location in the descriptor field parsing.
      Since it is operating on uncached memory, this can be quite expensive in
      this hot path.
      Change the code a bit to help the compiler optimize it properly, and get
      rid of some unused fields in the ath_tx_status struct.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e0e9bc82
    • Felix Fietkau's avatar
      ath9k_hw: optimize interrupt mask changes · 4df3071e
      Felix Fietkau authored
      OProfile showed that ath9k was spending way too much time in
      ath9k_hw_set_interrupts. Since most of the interrupt mask changes only
      need to globally enable/disable interrupts, it makes sense to split
      this part into separate functions, replacing all calls to
      ath9k_hw_set_interrupts(ah, 0) with ath9k_hw_disable_interrupts(ah).
      
      ath9k_hw_set_interrupts(ah, ah->imask) only gets changed to
      ath9k_hw_enable_interrupts(ah), whenever ah->imask was not changed
      since the point where interrupts were disabled.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4df3071e
  13. 16 Sep, 2010 1 commit
  14. 12 Jul, 2010 1 commit
  15. 14 Jun, 2010 2 commits
  16. 20 Apr, 2010 1 commit
  17. 16 Apr, 2010 11 commits
  18. 31 Mar, 2010 3 commits
  19. 23 Mar, 2010 1 commit
  20. 12 Jan, 2010 1 commit
  21. 28 Dec, 2009 1 commit
  22. 28 Nov, 2009 1 commit
    • Luis R. Rodriguez's avatar
      ath9k: Fix maximum tx fifo settings for single stream devices · f4709fdf
      Luis R. Rodriguez authored
      Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO
      buffer size of that of dual stream devices. Dual stream devices
      have a max PCU TX FIFO size of 8 KB while single stream devices
      have 4 KB. Single stream devices have an issue though and require
      hardware only to use half of the amount of its capable PCU TX FIFO
      size, 2 KB and this requires a change in software.
      
      Technically a change would not have been required (except for frame
      burst considerations of 128 bytes) if these devices would have been
      able to use the full 4 KB of the PCU TX FIFO size but our systems
      engineers recommend 2 KB to be used only. We enforce this through
      software by reducing the max frame triggger level to 2 KB.
      
      Fixing the max frame trigger level should then have a few benefits:
      
        * The PER will now be adjusted as designed for underruns when the
          max trigger level is reached. This should help alleviate the
          bus as the rate control algorithm chooses a slower rate which
          should ensure frames are transmitted properly under high system
          bus load.
      
        * The poll we use on our TX queues should now trigger and work
          as designed for single stream devices. The hardware passes
          data from each TX queue on the PCU TX FIFO queue respecting each
          queue's priority. The new trigger level ensures this seeding of
          the PCU TX FIFO queue occurs as designed which could mean avoiding
          false resets and actually reseting hw correctly when a TX queue
          is indeed stuck.
      
        * Some undocumented / unsupported behaviour could have been triggered
          when the max trigger level level was being set to 4 KB on single
          stream devices. Its not clear what this issue was to me yet.
      
      Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
      Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com>
      Cc: Stephen Chen <stephen.chen@atheros.com>
      Cc: Shan Palanisamy <shan.palanisamy@atheros.com>
      Cc: Paul Shaw <paul.shaw@atheros.com>
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f4709fdf