From owner-svn-src-head@FreeBSD.ORG Sun Apr 27 23:35:05 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6A60511; Sun, 27 Apr 2014 23:35:05 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A7CED12; Sun, 27 Apr 2014 23:35:05 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s3RNZ5Kp005054; Sun, 27 Apr 2014 23:35:05 GMT (envelope-from adrian@svn.freebsd.org) Received: (from adrian@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s3RNZ5hu005053; Sun, 27 Apr 2014 23:35:05 GMT (envelope-from adrian@svn.freebsd.org) Message-Id: <201404272335.s3RNZ5hu005053@svn.freebsd.org> From: Adrian Chadd Date: Sun, 27 Apr 2014 23:35:05 +0000 (UTC) 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 X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 23:35:05 -0000 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",