Date: Sat, 19 Mar 2011 03:15:28 +0000 (UTC) From: Adrian Chadd <adrian@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/dev/ath/ath_hal/ar5212 ar5212_misc.c ar5212_recv.c src/sys/dev/ath/ath_hal/ar5416 ar5416_attach.c ar5416_reset.c Message-ID: <201103190315.p2J3FdM7027659@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
adrian 2011-03-19 03:15:28 UTC
FreeBSD src repository
Modified files:
sys/dev/ath/ath_hal/ar5212 ar5212_misc.c ar5212_recv.c
sys/dev/ath/ath_hal/ar5416 ar5416_attach.c ar5416_reset.c
Log:
SVN rev 219771 on 2011-03-19 03:15:28Z by adrian
Make sure that the AR_MISC_MODE value from the initvals are properly respected.
This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."
The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.
The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.
This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)
The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.
Revision Changes Path
1.9 +1 -1 src/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c
1.4 +1 -1 src/sys/dev/ath/ath_hal/ar5212/ar5212_recv.c
1.27 +1 -1 src/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c
1.36 +1 -1 src/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103190315.p2J3FdM7027659>