Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Sep 2011 04:42:05 +0000 (UTC)
From:      Adrian Chadd <adrian@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-user@freebsd.org
Subject:   svn commit: r225604 - user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416
Message-ID:  <201109160442.p8G4g5um004324@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: adrian
Date: Fri Sep 16 04:42:05 2011
New Revision: 225604
URL: http://svn.freebsd.org/changeset/base/225604

Log:
  Fix the default cabq configuration time to not be "too long".
  
  The -HEAD code would configure a cabq time of 100 TU minus the
  various beacon setup intervals. When doing staggered beacons,
  this would result in CABQ readytime being 4 * the beacon interval
  timer, which is 1/ATH_BCBUF (4) the default beacon interval (100 TU.)
  
  This didn't seem to annoy the AR9160 MAC but it definitely annoys
  the AR9220/AR9280 MAC.
  
  I then fixed it to use the beacon time configured through a (hopefully
  earlier!) call to the HAL beacon timer setup code. This reduced the
  stuck beacon and cabq stall occurances quite a bit, but it didn't
  eliminate them.
  
  Having a CABQ time that's almost the same as the beacon interval seems
  to annoy AR9280 (Merlin) and later MACs. So, I decided to twiddle
  things a bit and make it 70% of the beacon interval. Both linux ath9k
  and the Atheros reference code default to 80% of the beacon interval.
  
  This hasn't stopped miss beacons (which could be because the air is
  "busy", which it tends to be in my apartment..) or eliminated the
  cabq TX issues (which should still be addressed, as there's no way
  a few broadcast frames here and there shouldn't make it out
  when the air is completely free for TX) but it does seem to have
  (initially) eliminated the stuck beacon conditions on my AR9220 NIC.
  I'll have to run this for a few hours to see what the story is and
  I likely should investigate why cabq traffic can't be TXed, but
  I'm happy to report these last few commits have had a positive effect.
  
  TODO: fix this in AR5212 too, just to be correct.
  TODO: actually set a non-0 readytime value when setting up the
    CABQ in the ath driver.

Modified:
  user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c

Modified: user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c
==============================================================================
--- user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c	Fri Sep 16 04:26:40 2011	(r225603)
+++ user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c	Fri Sep 16 04:42:05 2011	(r225604)
@@ -941,6 +941,7 @@ setTxQInterrupts(struct ath_hal *ah, HAL
  * Assumes:
  *  phwChannel has been set to point to the current channel
  */
+#define	TU_TO_USEC(_tu)		((_tu) << 10)
 HAL_BOOL
 ar5416ResetTxQueue(struct ath_hal *ah, u_int q)
 {
@@ -1018,7 +1019,8 @@ ar5416ResetTxQueue(struct ath_hal *ah, u
 		if (qi->tqi_cbrOverflowLimit)
 			qmisc |= AR_Q_MISC_CBR_EXP_CNTR_LIMIT;
 	}
-	if (qi->tqi_readyTime) {
+
+	if (qi->tqi_readyTime && (qi->tqi_type != HAL_TX_QUEUE_CAB)) {
 		OS_REG_WRITE(ah, AR_QRDYTIMECFG(q),
 			  SM(qi->tqi_readyTime, AR_Q_RDYTIMECFG_INT)
 			| AR_Q_RDYTIMECFG_ENA);
@@ -1089,18 +1091,38 @@ ar5416ResetTxQueue(struct ath_hal *ah, u
 		qmisc |= AR_Q_MISC_FSP_DBA_GATED
 		      |  AR_Q_MISC_CBR_INCR_DIS1
 		      |  AR_Q_MISC_CBR_INCR_DIS0;
-
-		if (!qi->tqi_readyTime) {
+		HALDEBUG(ah, HAL_DEBUG_TXQUEUE, "%s: CAB: tqi_readyTime = %d\n",
+		    __func__, qi->tqi_readyTime);
+		if (qi->tqi_readyTime) {
+			HALDEBUG(ah, HAL_DEBUG_TXQUEUE,
+			    "%s: using tqi_readyTime\n", __func__);
+			OS_REG_WRITE(ah, AR_QRDYTIMECFG(q),
+			    SM(qi->tqi_readyTime, AR_Q_RDYTIMECFG_INT) |
+			    AR_Q_RDYTIMECFG_ENA);
+		} else {
 			/*
 			 * NB: don't set default ready time if driver
 			 * has explicitly specified something.  This is
 			 * here solely for backwards compatibility.
 			 */
-			value = (ahp->ah_beaconInterval
-				- (ah->ah_config.ah_sw_beacon_response_time -
-					ah->ah_config.ah_dma_beacon_response_time)
-				- ah->ah_config.ah_additional_swba_backoff) * 1024;
-			OS_REG_WRITE(ah, AR_QRDYTIMECFG(q), value | AR_Q_RDYTIMECFG_ENA);
+			/*
+			 * XXX for now, hard-code a CAB interval of 70%
+			 * XXX of the total beacon interval.
+			 * XXX This keeps Merlin and later based MACs
+			 * XXX quite a bit happier (stops stuck beacons,
+			 * XXX which I gather is because of such a long
+			 * XXX cabq time.)
+			 */
+			value = TU_TO_USEC((ahp->ah_beaconInterval * 70 / 100)
+				- (ah->ah_config.ah_sw_beacon_response_time
+				+ ah->ah_config.ah_dma_beacon_response_time)
+				- ah->ah_config.ah_additional_swba_backoff);
+			HALDEBUG(ah, HAL_DEBUG_TXQUEUE,
+			    "%s: defaulting to rdytime = %d\n",
+			    __func__, value);
+			OS_REG_WRITE(ah, AR_QRDYTIMECFG(q),
+			    SM(value, AR_Q_RDYTIMECFG_INT) |
+			    AR_Q_RDYTIMECFG_ENA);
 		}
 		dmisc |= SM(AR_D_MISC_ARB_LOCKOUT_CNTRL_GLOBAL,
 			    AR_D_MISC_ARB_LOCKOUT_CNTRL);
@@ -1168,3 +1190,4 @@ ar5416ResetTxQueue(struct ath_hal *ah, u
 
 	return AH_TRUE;
 }
+#undef	TU_TO_USEC



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