Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 07 6月, 2012 1 次提交
  3. 30 5月, 2012 1 次提交
  5. 16 5月, 2012 1 次提交
    • S
      ath9k_hw: Fix RTT calibration · 8a90555f
      由 Sujith Manoharan 提交于 
      This patch fixes multiple issues with the current RTT
implementation in ath9k.

* The data that is obtained from the RTT interface registers
  are stored in 31:5 - mask out the extra bits when reading them.

* A history buffer is maintained which is not needed at all.
  Remove this array and just store the baseband data for each
  chain (or bank).

* A 'num_readings' variable was being used to handle the
  last entry. But it was being used in an improper manner, with
  the result that the RTT values were never being written
  to the RTT Interface registers. Fix this by using a simple
  flag.

* Stop baseband operations before programming the calibration values
  to the HW.

* Do not restore RX gain settings as part of RTT.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8a90555f
  7. 24 4月, 2012 5 次提交
  9. 17 4月, 2012 2 次提交
  11. 13 4月, 2012 1 次提交
  13. 10 4月, 2012 1 次提交
    • R
      ath9k: recover ar9380 chips from rare stuck state · 01e18918
      由 Rajkumar Manoharan 提交于 
      In the experiment with Azimuth ADEPT-n testbed where the APs transmit
power was reduced to 25% and the signal strength was futher attenuated
by 20dB and induced a path loss of ~7dB, the station was reporting
beacon losses and the following issue were observed.

* rx clear is stuck at low for more than 300ms
* dcu chain and complete state is stuck at one of the hang signature

This patch triggers the hang detection logic that recovers the chip
from any of the above conditions. As the issue was originally reported
in ChromeOs with AR9382 chips, this detection logic is enabled only for
AR9380/2 chips.

Cc: Paul Stewart <pstew@google.com>
Reported-by: NGary Morain <gmorain@google.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      01e18918
  15. 16 3月, 2012 5 次提交
  17. 13 3月, 2012 1 次提交
  19. 08 3月, 2012 1 次提交
  21. 28 2月, 2012 6 次提交
  23. 13 2月, 2012 1 次提交
  25. 07 2月, 2012 1 次提交
  27. 20 12月, 2011 2 次提交
  29. 16 12月, 2011 2 次提交
  31. 08 12月, 2011 2 次提交
    • N
      ath9k: enable ANI for ar9100 chips · 4f17c48e
      由 Nikolay Martynov 提交于 
        Enable ANI for ar9100 since it seems to be working fine (and as a
matter of fact ANI was always performed for ar9100 since code which
was supposed to disable it didn't achieve this goal).
  This patch sets config.enable_ani to default (true) value for
ar9100.
Signed-off-by: NNikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4f17c48e
    • N
      ath9k: use config.enable_ani to check if ani should be performed · 4279425c
      由 Nikolay Martynov 提交于 
        Currently in ath9k code there is an attempt which is meant to
disable ANI for ar9100 and ar9340. But it doesn't really achieve
this. All it does is disable ANI init and setup (i.e. calls to
ath9k_hw_ani_setup and ath9k_hw_ani_init). Since ath9k_hw_ani_setup is
not called ah->config.ani_poll_interval is never initialized (i.e. it
is always zero) and ath_ani_calibrate always executes ANI procedures
(over uninitialized ANI parameters).
  Moreover, ath_ani_calibrate is being called each 1ms because
common->ani.timer is set to zero interval because
ah->config.ani_poll_interval==0 (and thus smallest value of all
intervals). Normally it should not be called this often.
  This patch changes the code so config.enable_ani is used to check if
ANI should be performed.
  config.enable_ani is initialized to true by default. This patch sets
it to false for ar9100 and ar9340.
Signed-off-by: NNikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4279425c
  33. 01 12月, 2011 6 次提交
  35. 29 11月, 2011 1 次提交