ath9k: fix TSF after reset on AR913x
PATCH 1/1 ath9k: fix TSF after reset on AR913x
When issuing a reset, the TSF value is lost in the hardware because of the 913x specific cold reset. As with some AR9280 cards, the TSF needs to be preserved in software here.
Additionally, there's an issue that frequently prevents a successful TSF write directly after the chip reset. In this case, repeating the TSF write after the initval-writes usually works.
This patch detects failed TSF writes and recovers from them, taking into account the delay caused by the initval writes.
---
drivers/net/wireless/ath/ath9k/hw.c +14 -2
@@ -1280,7 +1280,8 @@ int ath9k_hw_reset(struct ath_hw *ah, st macStaId1 =REG_READ (ah,AR_STA_ID1 ) &AR_STA_ID1_BASE_RATE_11B ;/* For chips on which RTC reset is done, save TSF before it gets cleared */ -if (AR_SREV_9280 (ah) && ah->eep_ops->get_eeprom (ah,EEP_OL_PWRCTRL )) +if (AR_SREV_9100 (ah) || + (AR_SREV_9280 (ah) && ah->eep_ops->get_eeprom (ah,EEP_OL_PWRCTRL ))) tsf =ath9k_hw_gettsf64 (ah); saveLedState = REG_READ(ah, AR_CFG_LED) &
@@ -1312,7 +1313,7 @@ int ath9k_hw_reset(struct ath_hw *ah, st }/* Restore TSF */ -if (tsf &&AR_SREV_9280 (ah) && ah->eep_ops->get_eeprom (ah,EEP_OL_PWRCTRL )) +if (tsf)ath9k_hw_settsf64 (ah, tsf);if (AR_SREV_9280_10_OR_LATER (ah))
@@ -1325,6 +1326,17 @@ int ath9k_hw_reset(struct ath_hw *ah, stif (r)return r; +/* +* Some AR91xx SoC devices frequently fail to accept TSF writes +* right after the chip reset. When that happens, write a new +* value after the initvals have been applied, with an offset +* based on measured time difference +*/ +if (AR_SREV_9100 (ah) && (ath9k_hw_gettsf64 (ah) < tsf)) { + tsf +=1500 ; +ath9k_hw_settsf64 (ah, tsf); + } +/* Setup MFP options for CCMP */ if (AR_SREV_9280_20_OR_LATER (ah)) {/* Mask Retry(b11), PwrMgt(b12), MoreData(b13) to 0 in mgmt
drivers/net/wireless/ath/ath9k/hw.c int ath9k_hw_reset(struct ath_hw *ah, st · line 1336
Quoted 2 lines · Felix Fietkau
drivers/net/wireless/ath/ath9k/hw.c +2
-0+if (AR_SREV_9100 (ah) && (ath9k_hw_gettsf64 (ah) < tsf)) { + tsf +=1500 ;
Why 1500? Is it a magic number? It is a result of some measurement? Can we have a define for it, please?
Signature · 2 lines
Regards, Pavel Roskin
Quoted 6 lines · Pavel Roskin
Quoted 2 lines · Felix Fietkau
+ if (
AR_SREV_9100(ah)&& (ath9k_hw_gettsf64(ah)< tsf)) {
+ tsf += 1500;Why 1500? Is it a magic number? It is a result of some measurement? Can we have a define for it, please?
Does the TSF always start counting from zero when the chip is reset? In that case maybe the "magic number" can be replaced with the return value from ath9k_hw_gettsf64() (which we call anyway).
/Björn
Quoted 11 lines · Björn Smedman
Quoted 6 lines · Pavel Roskin
drivers/net/wireless/ath/ath9k/hw.c int ath9k_hw_reset(struct ath_hw *ah, st · line 1336
Quoted 2 lines · Felix Fietkau
drivers/net/wireless/ath/ath9k/hw.c +2
-0+if (AR_SREV_9100 (ah) && (ath9k_hw_gettsf64 (ah) < tsf)) { + tsf +=1500 ;Why 1500? Is it a magic number? It is a result of some measurement? Can we have a define for it, please?
Does the TSF always start counting from zero when the chip is reset? In that case maybe the "magic number" can be replaced with the return value from
ath9k_hw_gettsf64()(which we call anyway).
No, the TSF value at this point is not accurate. It differs semi-randomly by a few orders of magnitude from the time measured by the CPU timer. The value I put in above is just an approximation, but since making it completely accurate is impossible, I figured this is good enough, especially since the value will most likely not deviate much from what I've measured here.
- Felix
Quoted 6 lines · Felix Fietkau
No, the TSF value at this point is not accurate. It differs semi-randomly by a few orders of magnitude from the time measured by the CPU timer. The value I put in above is just an approximation, but since making it completely accurate is impossible, I figured this is good enough, especially since the value will most likely not deviate much from what I've measured here.
Are you sure it doesn't depend on CPU speed as well since the driver is involved here? Or DMA speed?
johannes
Quoted 11 lines · Johannes Berg
Quoted 6 lines · Felix Fietkau
No, the TSF value at this point is not accurate. It differs semi-randomly by a few orders of magnitude from the time measured by the CPU timer. The value I put in above is just an approximation, but since making it completely accurate is impossible, I figured this is good enough, especially since the value will most likely not deviate much from what I've measured here.
Are you sure it doesn't depend on CPU speed as well since the driver is involved here? Or DMA speed?
Yes, it depends on CPU speed, but there's not a lot of variation possible, because this only affects one, maybe two different SoC types with similar CPU speed, and a large part of the delay is probably constant because of udelay calls.
As I said, being precise here is impossible anyway, this is only a workaround for a hw issue, and this simple approximation should not cause any problems for anything. Even if the AP's TSF jumps by a few microseconds, the clients will catch on to that pretty quickly.
- Felix
Quoted 6 lines · Pavel Roskin
drivers/net/wireless/ath/ath9k/hw.c int ath9k_hw_reset(struct ath_hw *ah, st · line 1336
Quoted 2 lines · Felix Fietkau
drivers/net/wireless/ath/ath9k/hw.c +2
-0+if (AR_SREV_9100 (ah) && (ath9k_hw_gettsf64 (ah) < tsf)) { + tsf +=1500 ;Why 1500? Is it a magic number? It is a result of some measurement? Can we have a define for it, please?
The comment right above already explains it. This is the 'offset based on measured time difference'
- Felix