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.
Signed-off-by: Felix Fietkau <[email protected]>
Reported-by: Bj?rn Smedman <[email protected]>
Cc: [email protected]
---
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -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, st
if (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
On 2010-07-01 8:39 AM, Johannes Berg wrote:
> On Thu, 2010-07-01 at 02:47 +0200, Felix Fietkau wrote:
>
>> 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
On Thu, Jul 1, 2010 at 12:02 AM, Pavel Roskin <[email protected]> wrote:
> On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
>> + ? ? 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
On 2010-07-01 12:02 AM, Pavel Roskin wrote:
> On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
>> + 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
On Thu, 2010-07-01 at 02:47 +0200, Felix Fietkau wrote:
> 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
On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
> + 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?
--
Regards,
Pavel Roskin
On 2010-07-01 12:38 AM, Bj?rn Smedman wrote:
> On Thu, Jul 1, 2010 at 12:02 AM, Pavel Roskin <[email protected]> wrote:
>> On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
>>> + 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