- 11 5月, 2011 4 次提交
-
-
由 Rajkumar Manoharan 提交于
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
currently ath9k_hw_getchan_noise is not used anywhere Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Processing TSF out of range before RX helps to update beacon timers so early in the succeeding rx process. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
The assumsion is that while processing ath9k tasklet, interrupts were already disabled and it will be enabled at the completion of ath9k tasklet. But whenever TSFOOR is raised, the driver configures the beacon timers after having received a beacon frame from the AP which inturn enables the interrupts. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 5月, 2011 4 次提交
-
-
由 Luis R. Rodriguez 提交于
With AR9003 at about ~ 10 feet from an AP that uses RTS / CTS you will be able to associate but not not get data through given that the power for the rates used was set too low. This increases the power and permits data connectivity at longer distances from access points when connected with HT40. Without this you will not get any data through when associated to APs configured in HT40 at about more than 10 feet away. Cc: stable@kernel.org Cc: Fiona Cain <fcain@atheros.com> Cc: Zhen Xie <Zhen.Xie@Atheros.com> Cc: Kathy Giori <kathy.giori@atheros.com> Cc: Neha Choksi <neha.choksi@atheros.com> Cc: Wayne Daniel <wayne.daniel@atheros.com> Cc: Gaurav Jauhar <gaurav.jauhar@atheros.com> Cc: Samira Naraghi <samira.naraghi@atheros.com> CC: Ashok Chennupati <ashok.chennupati@atheros.com> Cc: Lance Zimmerman <lance.zimmerman@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
At present the noise floor calibration is processed in supported control and extension chains rather than required chains. Unnccesarily doing nfcal in all supported chains leads to invalid nf readings on extn chains and these invalid values got updated into history buffer. While loading those values from history buffer is moving the chip to deaf state. This issue was observed in AR9002/AR9003 chips while doing associate/dissociate in HT40 mode and interface up/down in iterative manner. After some iterations, the chip was moved to deaf state. Somehow the pci devices are recovered by poll work after chip reset. Raading the nf values in all supported extension chains when the hw is not yet configured in HT40 mode results invalid values. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
when aggregation protection mode is enabled the hardware needs to send RTS/CTS for each HT frame. Currently its disabled so remove the unused call backs. Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
While draining the txq in flush, the buffers can be added into the tx queue by tx_tasklet which leads to unneccesary chip reset. This issue was originially found with AR9382 and running heavy uplink udp traffic with higher bandwidth and doing frequent bgscan. Cc: stable@kernel.org Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 4月, 2011 3 次提交
-
-
由 Sujith Manoharan 提交于
Remove all the convoluted hacks in the driver and simplify things by making use of mac80211's LED triggers. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/modal_eeprom Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/base_eeprom Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 4月, 2011 8 次提交
-
-
由 Sujith Manoharan 提交于
This callback is used to set the minimum rate for management frames. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
This patch adds WMI_BITRATE_MASK_CMDID which can be used by the set_bitrate_mask() handler. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Bump the firmware version to 1.2 Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Use ps wrappers before accessing hw registers in btcoex. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Generic timer interrupt was not triggered unless autosleep was disabled. Since autosleep is enabled in the newer chipsets, enable generic timer for using with bt coex logic. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Move bt_stomp to ath9k_hw and add its support for latest chipsets. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 4月, 2011 3 次提交
-
-
由 Adrian Chadd 提交于
The xpaBiasLvlFreq parameter array is made up of 16 bit words which aren't byte-swapped like the other 16-bit eeprom parameters are. It's only used by the AR9160. Signed-off-by: NAdrian Chadd <adrian@freebsd.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Requesting beacon sync up to configure beacon timers properly in hw, has be done after doing beacon config with default values. Setting the flags in beacon config is causing the device to not enter into network sleep on idle state. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 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>
-
- 26 4月, 2011 18 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
This helped the developers to fix an issue of chip not entering network sleep during idle state, previously this was only available as a debug message Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
newer chipsets support auto sleep feature, so remove the unlikely check which does not seems to help anything Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
We should protect hw_pll handler with power save wrappers and also modularize hw_pll handler properly for better readability. Also add a debug message to track chip resets on pll hang condition. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
There is no reason why pll work handler should be part of xmit file. move it to main.c so that reading hw check routines are all in the same place. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
We need not wake up the chip even before mutex lock is acquired and also that it is required only if we are going to drain the txq. So place the wrappers accordingly and this change is also useful when there are no pending frames in the txq as we do not wake up the chip unnecessarily. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
we should program the AR9485 baseband PLL phase shift to 6 and a redundant setting overwrites the correct value. Remove the incorrect and unwnated register setting. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
The LED gpio is incorrectly programmed for AR9300 and so the led is not working propelry. AR93xx uses gpio 10 for LED and not the default. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Hw next tigger time is configured as current_tsf + (timer_period * 10) which is wrong, it should be current_tsf + timer_period. The wrong hw timer configuration would cause btcoex related issues. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Set the maximum ampdu size of a station correctly in the target by using the ampdu_factor. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
* Register the driver's maximum ampdu subframe limit to mac80211. * Cleanup the target capabilities structure and fix an endian issue. * Fix BTCOEX by sending a command to the target when the BT priority changes. * Bump the required firmware version to 1.1 Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
AR9340 is a AR9003 family built-in 2x2 wmac of ar934x SOCs. It is single band in ar9341 SOC and dual band in ar9344/ar9342 SOCs. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-