[PATCH] ath9k: fix TSF after reset on AR913x

[PATCH] ath9k: fix TSF after reset on AR913x

[Felix Fietkau]

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 <nbd@openwrt.org>
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Cc: stable@kernel.org
---
--- 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

Re: [PATCH] ath9k: fix TSF after reset on AR913x

[Pavel Roskin]

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

Re: [PATCH] ath9k: fix TSF after reset on AR913x

[Björn Smedman]

On Thu, Jul 1, 2010 at 12:02 AM, Pavel Roskin <proski@gnu.org> 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

Re: [PATCH] ath9k: fix TSF after reset on AR913x

[Felix Fietkau]

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

Re: [PATCH] ath9k: fix TSF after reset on AR913x

[Felix Fietkau]

On 2010-07-01 12:38 AM, Björn Smedman wrote:
> On Thu, Jul 1, 2010 at 12:02 AM, Pavel Roskin <proski@gnu.org> 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

Re: [PATCH] ath9k: fix TSF after reset on AR913x

[Johannes Berg]

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

Re: [PATCH] ath9k: fix TSF after reset on AR913x

[Felix Fietkau]

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