- 13 3月, 2012 1 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
tested in AR9462 Rev:2, both hardware capability flag are set Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 3月, 2012 1 次提交
-
-
由 Felix Fietkau 提交于
Cold reset is more reliable for getting the hardware out of some specific stuck states. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 2月, 2012 6 次提交
-
-
由 Sujith Manoharan 提交于
Make use of CONFIG_ATH9K_BTCOEX_SUPPORT in ath9k_hw to provide a clean way of compilation without BTCOEX support. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
This patch moves all the MCI-specific declarations that have been dumped unceremoniously in hw.h to ar9003_mci.h Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
This patch moves all the MCI-specific code in the main reset function to helper functions. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Setting up the required scheme can be done as part of the BTCOEX initialization path and it doesn't belong in ath9k_hw_fill_cap_info() anyway. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
v1.0 chips are not available in the market. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 07 2月, 2012 1 次提交
-
-
由 Felix Fietkau 提交于
commit adb5066a "ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts" reduced the hardware CTS timeout to the normal values specified by the standard, but it turns out while it doesn't need the same extra time that it needs for the ACK timeout, it does need more than the value specified in the standard, but only for 2.4 GHz. This patch brings the CTS timeout value in sync with the initialization values, while still allowing adjustment for bigger distances. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Reported-by: NSeth Forshee <seth.forshee@canonical.com> Reported-by: NMarek Lindner <lindner_marek@yahoo.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 12月, 2011 2 次提交
-
-
由 Felix Fietkau 提交于
Many systems (e.g. embedded systems) do not have wifi modules connected to bluetooth modules, so bluetooth coexistence is irrelevant there. With the addition of MCI support, ath9k picked up quite a bit of extra code that can be compiled out this way. This patch redefines ATH9K_HW_CAP_MCI and adds an inline wrapper for querying the bluetooth coexistence scheme, allowing the compiler to eliminate code that uses it, with only very little use of #ifdef. On MIPS this reduces the total size for the modules by about 20k. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Add ATH_DBG_ to macros to shorten the uses and reduce the line count. Coalesce ath_dbg formats. Add missing spaces to coalesced formats. Add missing newline terminations to ath_dbg formats. Align ath_dbg arguments where appropriate. Standardize ath_dbg formats without periods. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 12月, 2011 2 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
its not used anywhere in the current code Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Zefir Kurtisi 提交于
In order to enable DFS upstream we want to be sure DFS has been tested for each chipset. Push for public documentation of the requirements we want in place and allow for enabling each chipset through a single upstream commit. Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 12月, 2011 2 次提交
-
-
由 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>
-
由 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>
-
- 01 12月, 2011 6 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
the default tx/rx chainmask for AR9462 is 0x3. this patch helps to assign 0x3 rather than 0x7 for AR9462 with the help of fix_chainmask module if something goes wrong in reading tx/rx chain mask from OTP/EEPROM card(though its very unlikely) Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
only for AR9485 (or) later chipsets TxIQ calibration runs as part of AGC calibration. without this patch TX IQ cal completion i.e. ar9003_hw_tx_iq_cal_run won't be executed for AR9003 Reviewed-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
here we check for BT state and if BT calibration has started, give 25ms for BT Calibration to finish. we also take care of 2G/5G switch and LNA transfer incase WLAN is operating in 5G. in case the BT state is awake when we do WLAN calibration re-calibrate and we reset the message exchange between WLAN and BT. BT is given preference when simultaneous CAL request happens. calibration for WLAN/BT is done assuming that the other co-existing module is in awake state, if not we continue to do calibration while if the other module's state changes we need to do restart the calibration handshake Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
send halt BT GPM if the chip is in network sleep and BT state is awake Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 11月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by commit 2577c6e8 (ath9k_hw: Add support for AR946/8x chipsets) that caused a nasty regression to appear on my Acer Ferrari One (the box locks up entirely at random times after the wireless has been started without any way to get debug information out of it). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 11月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by commit 2577c6e8 ("ath9k_hw: Add support for AR946/8x chipsets") that caused a nasty regression to appear on my Acer Ferrari One (the box locks up entirely at random times after the wireless has been started without any way to get debug information out of it). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 11月, 2011 2 次提交
-
-
由 Rajkumar Manoharan 提交于
AR9462 chips have the capabilities to provoide bluetooth profile information. For non-AR9462 btcoex chips, the BT priority traffic was identified by periodically polling the respective registers and updated dutycycle, stomptype, etc. As AR9462 chip offers the BT profile informations, let us make use of that to update aggregation limit, dutycycle, stomptype and wieghtages. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dan Carpenter 提交于
The code here treats very large values of "limit" as less than MAX_POWER_RATE because of the cast to int. We should do the compare as u32 instead. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 03 11月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
During the fast channel change noise floor values are being loaded twice at init_cal and after channel_change. The commit "ath9k_hw: Improve fast channel change for AR9003 chips" overlooked it that caused failure to load nf while doing bgscan. This patch performs noise floor calibration after the fast and full reset. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 11月, 2011 1 次提交
-
-
由 Paul Gortmaker 提交于
The device.h header was including module.h, making it present for most of these drivers. But we want to clean that up. Call out the include of module.h in the modular network drivers. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 15 10月, 2011 8 次提交
-
-
由 Rajkumar Manoharan 提交于
Renamed to be in sync with Marketing term and to avoid confusion with other chip names. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Support the fast channel change across band switch only when there are available of reusable cabliration results. And also observed that doing agc control calibration on fastcc, sometimes causing calibration timeout. Hence changing agc control to be run only on full chip reset. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Supported calibrations of radio retention table (RTT) are - DC offset - Filter - Peak detect Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
The commit "ath9k_hw: Improve fast channel change for AR9003 chips" fixes the fast channel change issue for AR9003 chips that was originally observed in AR9382 chip. Hence enabling fastcc support again for 11A channel for AR9003 chips. Cc: Paul Stewart <pstew@google.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Currently Tx IQ calibration is enabled by default for all AR9003 chips. But for AR9480, the calibration status should be read from chip after processing ini. And also the carrier leak calibration status is checked during init cal. As the init_cal is being called for fast channel change too, the tx_cl status only be read after full reset. Hence moving that into process ini function. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
This patch adds support to reuse Carrier leak calibration during fast channel change for AR9480 chips. Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
In order to reduce the overall scan time, fast channel change should be implemented properly. This patch adds fast channel change support across band switch or channel mode switch instead of doing full chip reset. During the fastcc, tx iqcal measurements are preserved and will be reloaded after successful the channel change. This patch also addressed fast channel issue where the STA can not see APs in higher than operating channel on 5GHz band after the association. Cc: Paul Stewart <pstew@google.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Because of not clearing Bit 14 of AR_WA, the ASPM L1 is not enabled when entering into sleep mode. AR9480 does not need bit 14 to be set. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 10月, 2011 2 次提交
-
-
由 Felix Fietkau 提交于
It is unused since the previous dead code that was using it had been removed earlier. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
The code for handling various restrictions concerning regulatory limits, antenna gain, etc. is very convoluted and duplicated across various EEPROM parsing implementations, making it hard to review. This patch partially cleans up the mess by unifying regulatory limit handling in one function and simplifying handling of antenna gain. It also removes unused transmit power scaling arrays from the EEPROM code, which belonged to an unimplemented API that isn't supposed to be in the driver anyway. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 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 1 次提交
-
-
由 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>
-