Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Apr 2014 23:35:05 +0000 (UTC)
From:      Adrian Chadd <adrian@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r265031 - head/sys/dev/ath/ath_hal/ar5416
Message-ID:  <201404272335.s3RNZ5hu005053@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: adrian
Date: Sun Apr 27 23:35:05 2014
New Revision: 265031
URL: http://svnweb.freebsd.org/changeset/base/265031

Log:
  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!

Modified:
  head/sys/dev/ath/ath_hal/ar5416/ar5416_beacon.c

Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_beacon.c
==============================================================================
--- head/sys/dev/ath/ath_hal/ar5416/ar5416_beacon.c	Sun Apr 27 23:33:37 2014	(r265030)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416_beacon.c	Sun Apr 27 23:35:05 2014	(r265031)
@@ -197,6 +197,25 @@ ar5416SetStaBeaconTimers(struct ath_hal 
 	 *   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 
 
 	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",



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404272335.s3RNZ5hu005053>