Program the AR_TSFOOR_THRESHOLD register with a default lifted from

the QCA HAL.

This fires off an interrupt if the TSF from the AP / IBSS peer is
wildly out of range.  I'll add some code to the ath(4) driver soon
which makes use of this.

TODO:

* verify this didn't break TDMA!
This commit is contained in:
Adrian Chadd 2014-04-27 23:35:05 +00:00
parent 3e9b8fe01b
commit ee6325ab56

View File

@ -197,6 +197,25 @@ ar5416SetStaBeaconTimers(struct ath_hal *ah, const HAL_BEACON_STATE *bs)
* beacon jitter; cab timeout is max time to wait for cab
* after seeing the last DTIM or MORE CAB bit
*/
/*
* I've bumped these to 30TU for now.
*
* Some APs (AR933x/AR934x?) in 2GHz especially seem to not always
* transmit beacon frames at exactly the right times and with it set
* to 10TU, the NIC starts not waking up at the right times to hear
* these slightly-larger-jitering beacons. It also never recovers
* from that (it doesn't resync? I'm not sure.)
*
* So for now bump this to 30TU. Ideally we'd cap this based on
* the beacon interval so the sum of CAB+BEACON timeouts never
* exceeded the beacon interval.
*
* Now, since we're doing all the math in the ath(4) driver in TU
* rather than TSF, we may be seeing the result of dumb rounding
* errors causing the jitter to actually be a much bigger problem.
* I'll have to investigate that with a fine tooth comb.
*/
#define CAB_TIMEOUT_VAL 10 /* in TU */
#define BEACON_TIMEOUT_VAL 10 /* in TU */
#define SLEEP_SLOP 3 /* in TU */
@ -248,6 +267,13 @@ ar5416SetStaBeaconTimers(struct ath_hal *ah, const HAL_BEACON_STATE *bs)
OS_REG_SET_BIT(ah, AR_TIMER_MODE,
AR_TIMER_MODE_TBTT | AR_TIMER_MODE_TIM | AR_TIMER_MODE_DTIM);
#define HAL_TSFOOR_THRESHOLD 0x00004240 /* TSF OOR threshold (16k us) */
/* TSF out of range threshold */
// OS_REG_WRITE(ah, AR_TSFOOR_THRESHOLD, bs->bs_tsfoor_threshold);
OS_REG_WRITE(ah, AR_TSFOOR_THRESHOLD, HAL_TSFOOR_THRESHOLD);
HALDEBUG(ah, HAL_DEBUG_BEACON, "%s: next DTIM %d\n",
__func__, bs->bs_nextdtim);
HALDEBUG(ah, HAL_DEBUG_BEACON, "%s: next beacon %d\n",