1. 20 9月, 2011 1 次提交
  2. 17 9月, 2011 1 次提交
  3. 14 9月, 2011 1 次提交
  4. 30 8月, 2011 1 次提交
  5. 26 8月, 2011 1 次提交
    • L
      ath9k_hw: add AR9580 support · 5a63ef0f
      Luis R. Rodriguez 提交于
      Here are the AR9580 1.0 initvals checksums using the
      Atheros initvals-tools [1]. This is useful for when
      we udate the initvals again with other values. It ensures
      that we match the same initvals used internally. The
      tool is documented on the wiki [2].
      
      $ ./initvals -f ar9580-1p0
      0x00000000e912711f        ar9580_1p0_modes_fast_clock
      0x000000004a488fc7        ar9580_1p0_radio_postamble
      0x00000000f3888b02        ar9580_1p0_baseband_core
      0x0000000003f783bb        ar9580_1p0_mac_postamble
      0x0000000094be244a        ar9580_1p0_low_ob_db_tx_gain_table
      0x0000000094be244a        ar9580_1p0_high_power_tx_gain_table
      0x0000000090be244a        ar9580_1p0_lowest_ob_db_tx_gain_table
      0x00000000ed9eaac6        ar9580_1p0_baseband_core_txfir_coeff_japan_2484
      0x00000000c4d66d1b        ar9580_1p0_mac_core
      0x00000000e8e9043a        ar9580_1p0_mixed_ob_db_tx_gain_table
      0x000000003521a300        ar9580_1p0_wo_xlna_rx_gain_table
      0x00000000301fc841        ar9580_1p0_soc_postamble
      0x00000000a9a06b3a        ar9580_1p0_high_ob_db_tx_gain_table
      0x00000000a15ccf1b        ar9580_1p0_soc_preamble
      0x0000000029495000        ar9580_1p0_rx_gain_table
      0x0000000037ac0ee8        ar9580_1p0_radio_core
      0x00000000603a1b80        ar9580_1p0_baseband_postamble
      0x000000003d8b4396        ar9580_1p0_pcie_phy_clkreq_enable_L1
      0x00000000398b4396        ar9580_1p0_pcie_phy_clkreq_disable_L1
      0x00000000397b4396        ar9580_1p0_pcie_phy_pll_on_clkreq
      
      [1] git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/initvals-tool.git
      [2] http://wireless.kernel.org/en/users/Drivers/ath9k_hw/initvals-tool
      
      Cc: David Quan <dquan@qca.qualcomm.com>
      Cc: Kathy Giori <kgiori@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Tested-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5a63ef0f
  6. 19 7月, 2011 1 次提交
  7. 12 7月, 2011 1 次提交
  8. 23 6月, 2011 1 次提交
  9. 20 5月, 2011 1 次提交
  10. 29 4月, 2011 1 次提交
  11. 27 4月, 2011 1 次提交
    • R
      ath9k_hw: Fix Tx IQ Calibration hang issue in AR9003 chips · 3782c69d
      Rajkumar Manoharan 提交于
      On AR9003 chips, doing three IQ calibrations will possibly cause chip
      in stuck state. In noisy environment, chip could receive
      a packet during the middle of three calibrations and it causes
      the conflict of HW access and the eventual failure. It also
      causes IQ calibration outliers which results in poor Tx EVM.
      
      The IQ Cal procedure is after resetting the chip, run IQ cal 3 times
      per each cal cycle and find the two closest readings and average of two.
      The advantage of running Tx IQ cal more than once is that we can compare
      calibration results for the same gain setting over multiple iterations.
      Most of the cases the IQ failures were observed after first pass.
      
      For the AR9485 and later chips, Tx IQ Calibration is performed along
      with AGC cal. But for pre-AR9485 chips, Tx IQ cal HW has to be separated
      from the rest of calibration HW to avoid chip hang. After all
      calibrations are done in HW, we can start SW post-processing.
      By doing this way, we minimize the SW difference among all chips.
      
      The order of calibration (run IQ cal before other calibration) is also
      needed to avoid chip hang for chips before AR9485. This issue was
      originally observed with AR9382.
      
      During the issue kernel log was filled with following message
      ath: timeout (100000 us) on reg 0xa640: 0x00000001 & 0x00000001 != 0x00000000
      ath: timeout (100000 us) on reg 0xa2c4: 0x00158dd9 & 0x00000001 != 0x00000000
      ath: Unable to reset channel (2412 MHz), reset status -5
      ath: Unable to set channel
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3782c69d
  12. 26 4月, 2011 3 次提交
  13. 13 4月, 2011 2 次提交
  14. 31 3月, 2011 1 次提交
  15. 24 2月, 2011 1 次提交
  16. 19 2月, 2011 1 次提交
  17. 29 1月, 2011 2 次提交
  18. 08 12月, 2010 3 次提交
  19. 03 12月, 2010 1 次提交
  20. 25 11月, 2010 2 次提交
  21. 23 11月, 2010 1 次提交
  22. 17 11月, 2010 4 次提交
  23. 09 11月, 2010 1 次提交
    • V
      ath9k_hw: Fix AR9280 surprise removal during frequent idle on/off · f119da30
      Vasanthakumar Thiagarajan 提交于
      Bit 22 of AR_WA should be set to fix the situation where chip reset
      is asynchronous to clock of analog shift registers, such that when
      reset is released, it could mess up the values of analog shift registers
      and cause some hw issue on AR9280.
      
      This bit is write only, but the driver does a read-modify-write
      on AR_WA without setting bit 22 in ar9002_hw_configpcipowersave()
      during radio disable. This causes surprise removal of hw. It can
      never recover from this state and the hw will become usable only
      after a power on/off cycle, and sometimes only during a cold reboot.
      
      This issue can be triggered by doing frequent roaming with the
      simple/test-roam script available from the wifi-test project [1]
      when roaming between APs quickly. When roaming there is a is a high
      possibility that the device being put into idle (radio disable) state
      by mac80211 during AUTH->ASSOC. A device hardware reset would fail
      and the kernel would output:
      
      [40251.363799] ath: AWAKE -> FULL-SLEEP
      [40251.363815] ieee80211 phy17: device no longer idle - working
      [40251.363817] ath: Marking phy17 as not-idle
      [40251.363819] ath: FULL-SLEEP -> AWAKE
      [40251.415978] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3)
      [40251.419896] ath: ah->misc_mode 0x4
      [40251.428138] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3)
      [40251.532247] ath: timeout (100000 us) on reg 0x9860: 0xffffffff & 0x00000001 != 0x00000000
      [40251.532250] ath: Unable to reset channel (2462 MHz), reset status -5
      [40251.532422] ath: Set channel: 5745 MHz
      [40251.540639] ath: Failed to stop TX DMA in 100 msec after killing last frame
      [40251.548826] ath: Failed to stop TX DMA in 100 msec after killing last frame
      [40251.557023] ath: Failed to stop TX DMA in 100 msec after killing last frame
      [40251.565211] ath: Failed to stop TX DMA in 100 msec after killing last frame
      [40251.573415] ath: Failed to stop TX DMA in 100 msec after killing last frame
      [40251.581603] ath: Failed to stop TX DMA in 100 msec after killing last frame
      [40251.581606] ath: Failed to stop TX DMA. Resetting hardware!
      [40251.592679] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff
      [40251.703330] ath: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
      [40251.703333] ath: RTC stuck in MAC reset
      [40251.703334] ath: Chip reset failed
      [40251.703335] ath: Unable to reset hardware; reset status -22
      
      This is currently only reproducible with some HB92 (Half Mini-PCIE)
      cards but the fix applies to all AR9280 cards. This patch fixes this
      issue by setting bit 22 during radio disable.
      
      This patch has fixes for all kernels that has ath9k.
      
      [1] http://wireless.kernel.org/en/developers/Testing/wifi-test
      
      Cc: kyungwan.nam@atheros.com
      Cc: amod.bodas@atheros.com
      Cc: david.quan@atheros.com
      Cc: stable@kernel.org
      Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f119da30
  24. 16 10月, 2010 1 次提交
    • L
      ath9k_hw: remove AR9003 2.0 support · 886b42bf
      Luis R. Rodriguez 提交于
      These chipsets will not hit the market, all customers will be
      on >= AR9003 2.2. This shaves down the ath9k_hw size by
      24161 bytes (24 KB) on my system.
      
      Before:
      
      $ size drivers/net/wireless/ath/ath9k/ath9k_hw.ko
         text	   data	    bss	    dec	    hex	filename
       292328	    616	   1824	 294768	  47f70	drivers/net/wireless/ath/ath9k/ath9k_hw.ko
      
      $ du -b drivers/net/wireless/ath/ath9k/ath9k_hw.ko
      5987825	drivers/net/wireless/ath/ath9k/ath9k_hw.ko
      
      After:
      
      $ size drivers/net/wireless/ath/ath9k/ath9k_hw.ko
         text	   data	    bss	    dec	    hex	filename
       277192	    616	   1824	 279632	  44450	drivers/net/wireless/ath/ath9k/ath9k_hw.ko
      
      $ du -b drivers/net/wireless/ath/ath9k/ath9k_hw.ko
      5963664	drivers/net/wireless/ath/ath9k/ath9k_hw.ko
      
      Cc: Yixiang Li <yixiang.li@atheros.com>
      Cc: Don Breslin <don.breslin@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      886b42bf
  25. 12 10月, 2010 1 次提交
  26. 28 9月, 2010 3 次提交
  27. 14 8月, 2010 1 次提交
  28. 01 7月, 2010 1 次提交