- 20 9月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
- AR_SREV_5416_20_OR_LATER is always true, remove it - AR_SREV_9280_20_OR_LATER is always true within eeprom_4k.c and eeprom_9287.c - (AR_SREV_9271 || AR_SREV_9285) is always true in eeprom_4k.c Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 9月, 2011 1 次提交
-
-
由 Senthil Balasubramanian 提交于
Add initvals and register modifications required to support AR946/8x chipsets. Signed-off-by: NSenthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 9月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
The commit "ath9k_hw: Fix exceed transmission burst-time of 5GHz" added a padding of 60 delimiters on the first subframe to work around an issue on AR9380, but it lacked the checks to prevent it from being applied to pre-AR9380, enterprise AR9380 or AR9580+ Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 8月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
For AR9287 v1.3+ chips, MAC runs at 117MHz. But the initvals IFS parameters are loaded based on 44/88MHz clockrate. So eifs/usec from ini should not be used for AR9287 v1.3+. The mentioned values are tested on 2 chain HT40 mode. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 26 8月, 2011 1 次提交
-
-
由 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>
-
- 19 7月, 2011 1 次提交
-
-
由 Pavel Roskin 提交于
Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 7月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
Now that the clock rate is initialized properly and SIFS, EIFS, USEC, slot time and ACK timeout are properly calculated by the generic code, the 'async FIFO' register hacks are no longer necessary. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 6月, 2011 1 次提交
-
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 5月, 2011 1 次提交
-
-
由 Sujith Manoharan 提交于
The Times They Are a-Changin'. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 4月, 2011 1 次提交
-
-
由 Vivek Natarajan 提交于
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 4月, 2011 1 次提交
-
-
由 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 3 次提交
-
-
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>
-
- 13 4月, 2011 2 次提交
-
-
This fixes random disconnect. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Older versions have not been sold and the driver does not explicitly check for them anyway, so we can simply ignore the macRev here. Reduces ath9k_hw size on mips by more than 2 KB. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 31 3月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
Fixes interop issues with aggregation in combination with multi-BSSID Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 2月, 2011 1 次提交
-
-
由 Sujith Manoharan 提交于
Some AR7010 based devices are recognized as storage media. Sending a CD-EJECT command to the device will 'convert' it into a WLAN device. Do this within the driver itself, removing the dependancy on an external program (usb_modeswitch). Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 19 2月, 2011 1 次提交
-
-
由 Vivek Natarajan 提交于
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 1月, 2011 2 次提交
-
-
由 Vivek Natarajan 提交于
Updates from the analog team for AR9485 chipsets to set DDR_PLL2 and DDR_PLL3. Also program the BB_PLL ki and kd value. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Add a function to observe the delta VC of BB_PLL. For a good chip, the sqsum_dvc is below 2000. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 12月, 2010 3 次提交
-
-
由 Sujith Manoharan 提交于
ath.ko is a common module shared between ath5k, ar9170usb, ath9k and ath9k_htc. Adding driver specific data to the shared structure would impact all the drivers. Handling USB device recognition for devices specific to ath9k_htc can be handled within the driver itself. Also, AR7010 refers to the processor used in both AR9280/AR9287 based devices. Rename the device enumerations accordingly. While at it, check properly for the bus type when choosing the EEPROM base address for UB95. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@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>
-
AR9485 is a single chain and single band (2.4 Ghz) chip. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 03 12月, 2010 1 次提交
-
-
The register which gives input gpio state is 0x404c for ar9003, currently 0x4048 is wrongly used. This will disable RF and make it unusable on some of AR9003. Cc:stable@kernel.org Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 11月, 2010 2 次提交
-
-
由 Rajkumar Manoharan 提交于
Categorize AR7010 & AR9287 devices based on driver_info of usb_device_id, instead of PIDs. This avoids per-device cases and minimize code changes for new device addition. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
AR9287 devices (PCI/USB) use different eeprom start location to read nvram. New devices might endup with same devid. So use driver_info to set offset, instead of devid. driver_info is valid for HTC devices alone which is filled in usb_device_id. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 11月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
Under load, a large number of frames can produce decryption errors, even when no key cache update is being done. Performing a key search for every single frame in an A-MPDU improves reliability. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 11月, 2010 4 次提交
-
-
由 Senthil Balasubramanian 提交于
TX underruns were noticed when RTS/CTS preceded aggregates. This issue was noticed in ar93xx family of chipsets only. The workaround involves padding the RTS or CTS length up to the min packet length of 256 bytes required by the hardware by adding delimiters to the fist descriptor of the aggregate. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
AR9382 needs to be configured for the correct chain mask before running AGC/TxIQ caliberation. Otherwise reset would fail. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
AR9287 based PCI & USB devices are differed in eeprom start offset. So set proper the offset for HTC devices to read nvram correctly. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Treat new PIDs (0xA704, 0x1200) as AR7010 devices. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 11月, 2010 1 次提交
-
-
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>
-
- 16 10月, 2010 1 次提交
-
-
由 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>
-
- 12 10月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
Instead of keeping track of wraparound, clear the counters on every access and keep separate deltas for ANI and later survey use. Also moves the function for calculating the 'listen time' for ANI Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 9月, 2010 3 次提交
-
-
由 Felix Fietkau 提交于
Since AR9287 v1.0 was never sold (and the initvals removed), its revision checks can be simplified similar to AR9280 Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Since AR9285 v1.0 and v1.1 were never sold (and the initvals removed), its revision checks can be simplified similar to AR9280 Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Since AR9280 v1.0 was never sold (and the initvals removed), v1.0 specific revision checks can be removed and the 'v2.0 or later' check can be simplified to a check for AR9280 or later. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 8月, 2010 1 次提交
-
-
由 Rajkumar Manoharan 提交于
This patch handles the firmware loading properly for device ID 7015. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 7月, 2010 1 次提交
-
-
由 Sujith 提交于
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-