1. 22 12月, 2009 1 次提交
  2. 29 11月, 2009 2 次提交
    • L
      ath9k: Fix maximum tx fifo settings for single stream devices · f4709fdf
      Luis R. Rodriguez 提交于
      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: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f4709fdf
    • L
      ath9k: fix processing of TX PS null data frames · e7824a50
      Luis R. Rodriguez 提交于
      When mac80211 was telling us to go into Powersave we listened
      and immediately turned RX off. This meant hardware would not
      see the ACKs from the AP we're associated with and hardware
      we'd end up retransmiting the null data frame in a loop
      helplessly.
      
      Fix this by keeping track of the transmitted nullfunc frames
      and only when we are sure the AP has sent back an ACK do we
      go ahead and shut RX off.
      Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NVivek Natarajan <Vivek.Natarajan@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e7824a50
  3. 08 10月, 2009 6 次提交
  4. 14 8月, 2009 1 次提交
  5. 25 7月, 2009 1 次提交
    • S
      ath9k: RX stucks during heavy traffic in HT40 mode. · dd8b15b0
      Senthil Balasubramanian 提交于
      Running iperf along with p2p traffic on both TX and RX side then
      stop one side, then stop the other side, then start it up again,
      eventually the STA gets into a mode that it can not pass data at
      all.
      
      A hardware workaround for invalid RSSI can make FIFO write pointer
      to jump over read pointer, causing RX data corruption and repeated
      DMA. Both TX and RX works fine when the workaround is disabled.
      
      To replace the original hardware work around, software looks for
      frames with post delimiter CRC error and mark the RSSI invalid so
      that the upperlayer will not use the RSSI associated with this
      frame. So disable the hardware workaround by updating the appropriate
      registers.
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dd8b15b0
  6. 23 4月, 2009 2 次提交
  7. 28 3月, 2009 1 次提交
  8. 28 2月, 2009 2 次提交
  9. 14 2月, 2009 3 次提交
  10. 10 2月, 2009 1 次提交
  11. 31 1月, 2009 1 次提交
  12. 13 12月, 2008 2 次提交
  13. 05 12月, 2008 2 次提交
  14. 26 11月, 2008 1 次提交
  15. 11 11月, 2008 1 次提交