- 04 10月, 2011 2 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
the AR_SREV register does not seems to indicate whether AR9480 is pci_express capable or not though the other information like macVersion etc can be obtained properly. this fix is essential as ASPM won't be intialized and its related driver functionality ath9k_hw_configpcipowersave won't be called Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
this patch fixes the assumption of maximum number of GPIO pins present in AR9287/AR9300. this fix is essential as we might encounter some functionality issues involved in accessing the status of GPIO pins which are all incorrectly assumed to be not within the range of max_num_gpio of AR9300/AR9287 chipsets Cc: stable@kernel.org Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 9月, 2011 2 次提交
-
-
由 Rajkumar Manoharan 提交于
AR9003 seems to have issues sometimes with fast channel change in 5GHz and this case is handled specifically for AR9280 by doing a full reset. Let's do a full reset for 5GHz channles of AR9380 & for all channels of AR9280 pci chips. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
This patch adds support for AR946/8x chipets. Signed-off-by: NSenthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 9月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
we already have ah->{rx,tx}chainmask for the same purpose Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 9月, 2011 3 次提交
-
-
由 Bill Jordan 提交于
In commit 9c204b46 (ath9k_hw: do not limit initial tx power to 20 dbm), setting of txpower was broken. This patch fixes it by initializing reg_pwr from the new power limit, not the previous value. Signed-off-by: NBill Jordan <bjordan@rajant.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Rx latecy to start signal(usec) of 11a is 41 not 37 and also corrected the rx delay in quarter rate. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
It is only used to workaround interoperability issues related to longer delays in receiving the block ack, so it is not necessary to apply it to the CTS exchange. Should improve throughput slightly, especially when there are lots of retransmissions. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 8月, 2011 3 次提交
-
-
由 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>
-
由 Rajkumar Manoharan 提交于
Initialize 9us slot time as that is what is used mostly (for non-ERP cases) and also to be in sync with initvals. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Florian Fainelli 提交于
AR9340 is not listed in ath_mac_bb_names, which leads to such a message: ieee80211 phy0: Atheros AR???? Rev:0 mem=0xb8100000, irq=2 Signed-off-by: NFlorian Fainelli <florian@openwrt.org> 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>
-
- 25 8月, 2011 1 次提交
-
-
由 Alex Hacker 提交于
The EIFS value read from AR_D_GBL_IFS_EIFS register in core clocks and then written back as microsecond value. Signed-off-by: NAlex Hacker <hacker@epn.ru> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 8月, 2011 1 次提交
-
-
由 Stanislaw Gruszka 提交于
Disable ASPM in pci ->probe on upstream (device) and downstream (PCIe port) component. According to e1000e driver authors this is required. I did not find that requirement in PCIe spec, but it seems to be logical for me. This need to be fixed for CONFIG_PCIEASPM, that will be done later ... Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 8月, 2011 2 次提交
-
-
由 Felix Fietkau 提交于
Currently ath9k presents the internal calibrated noise floor as channel noise measurement, however this results in highly chip specific values that are only useful as relative measurements but do not resemble any real channel noise values. In order to give a much better approximation of the real channel noise, add the difference between the measured noise floor and the nominal chip specific noise floor to the default minimum channel noise value, which is currently used to calculate the signal strength from the RSSI value. This may not be 100% accurate, but it's much better than what's there before. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
When testing for tx power, bypass the default limits. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 8月, 2011 1 次提交
-
-
由 Stanislaw Gruszka 提交于
We receive many bug reports about system hang during suspend/resume when ath9k driver is in use. Adrian Chadd remarked that this problem happens on systems that have ASPM disabled. To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe downstream port device, which ath9k device is connected to, has ASPM disabled. Bug was introduced by: commit 53bc7aa0 Author: Vivek Natarajan <vnatarajan@atheros.com> Date: Mon Apr 5 14:48:04 2010 +0530 ath9k: Add support for newer AR9285 chipsets. Patch should address: https://bugzilla.kernel.org/show_bug.cgi?id=37462 https://bugzilla.kernel.org/show_bug.cgi?id=37082 https://bugzilla.redhat.com/show_bug.cgi?id=697157 however I did not receive confirmation about that, except from Camilo Mesias, whose system stops hang regularly with this patch (but still hangs from time to time, but this is probably some other bug). Tested-by: NCamilo Mesias <camilo@mesias.co.uk> Cc: stable@kernel.org # 2.6.35+ Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 7月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
Some devices (e.g. Ubiquiti AirRouter) ship with broken EEPROM chainmask data, which breaks the initial calibration after a hardware reset. To fix this, mask the eeprom chainmask with the chainmask of the chip, and use the chip chainmask if the result is zero. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 7月, 2011 5 次提交
-
-
由 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>
-
由 Felix Fietkau 提交于
Initialize the the clock-to-TSF field of AR_USEC and the SIFS and EIFS time registers based on the clock rate instead of relying on initvals. With those changes, some of the hardcoded AR9287 1.3+ specific overrides can be dropped. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
This chip uses the async FIFO feature and runs the MAC at 117 MHz Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Enabling half/quarter rate makes the MAC run at half/quarter clock speed. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
All devices support this, but some disable it using an EEPROM flag for some reason. Improves 5 GHz performance on those devices. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 6月, 2011 9 次提交
-
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
The patch adds a callback to ath9k_platform_data. If the callback is provided by the platform code, then it can be used to hard reset the WMAC device. The callback is required for doing a hard reset of the AR9330 chips to get them working again after a hang. Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
The AR9330 1.0 and 1.1 are using the same revision, thus it is not possible to distinguish the two chips. The platform setup code can distinguish the chips based on the SoC revision. Add a callback function to ath9k_platform_data in order to allow getting the revision number from the platform code. Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 6月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
Earlier beacon_interval is used to hold interval value and some flags (ATH9K_BEACON_ENA &ATH9K_BEACON_PERIOD). So to extract interval ATH9K_BEACON_PERIOD is used. Those flags were completely removed. So masking beacon_interval is not required. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 5月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
While receiving unsupported rate frame rx state machine gets into a state 0xb and if phy_restart happens in that state, BB would go hang. If RXSM is in 0xb state after first bb panic, ensure to disable the phy_restart. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> 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>
-
- 17 5月, 2011 1 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
read antenna diversity and combining information from the EEPROM. Enable antenna diversity/combining feature only when both LNA diversity and fast diversity are supported Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com> Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com> Tested-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@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>
-
- 26 4月, 2011 3 次提交
-
-
由 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 提交于
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>
-
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>
-