Author: adrian
Date: Thu Oct 4 15:42:45 2012
New Revision: 241195
URL: http://svn.freebsd.org/changeset/base/241195
Log:
Implement the quarter rate fractional channel programming for the
AR5416 and AR9280, but leave it disabled by default.
TL;DR: don't enable this code at all unless you go through the process
of getting the NIC re-certified. This is purely to be used as a
reference and NOT a certified solution by any stretch of the imagination.
The background:
The AR5112 RF synth right up to the AR5133 RF synth (used on the AR5416,
derivative is used for the AR9130/AR9160) only implement down to 2.5MHz
channel spacing in 5GHz. Ie, the RF synth is programmed in steps of 2.5MHz
(or 5, 10, 20MHz.) So they can't represent the quarter rate channels
in the 4.9GHz PSB (which end in xxx2MHz and xxx7MHz). They support
fractional spacing in 2GHz (1MHz spacing) (or things wouldn't work,
right?)
So instead of doing this, the RF synth programming for the AR5112 and
later code will round to the nearest available frequency.
If all NICs were RF5112 or later, they'll inter-operate fine - they all
program the same. (And for reference, only the latest revision of the
RF5111 NICs do it, but the driver doesn't yet implement the programming.)
However:
* The AR5416 programming didn't at all implement the fractional synth
work around as above;
* The AR9280 programming actually programmed the accurate centre frequency
and thus wouldn't inter-operate with the legacy NICs.
So this patch:
* Implements the 4.9GHz PSB fractional synth workaround, exactly as the
RF5112 and later code does;
* Adds a very dirty workaround from me to calculate the same channel
centre "fudge" to the AR9280 code when operating on fractional frequencies
in 5GHz.
HOWEVER however:
It is disabled by default. Since the HAL didn't implement this feature,
it's highly unlikely that the AR5416 and AR928x has been tested in these
centre frequencies. There's a lot of regulatory compliance testing required
before a NIC can have this enabled - checking for centre frequency,
for drift, for synth spurs, for distortion and spectral mask compliance.
There's likely a lot of other things that need testing so please don't
treat this as an exhaustive, authoritative list. There's a perfectly good
process out there to get a NIC certified by your regulatory domain, please
go and engage someone to do that for you and pay the relevant fees.
If a company wishes to grab this work and certify existing 802.11n NICs
for work in these bands then please be my guest. The AR9280 works fine
on the correct fractional synth channels (49x2 and 49x7Mhz) so you don't
need to get certification for that. But the 500KHz offset hack may have
the above issues (spur, distortion, accuracy, etc) so you will need to
get the NIC recertified.
Please note that it's also CARD dependent. Just because the RF synth
will behave correctly doesn't at all mean that the card design will also
behave correctly. So no, I won't enable this by default if someone
verifies a specific AR5416/AR9280 NIC works. Please don't ask.
Tested:
I used the following NICs to do basic interoperability testing at
half and quarter rates. However, I only did very minimal spectrum
analyser testing (mostly "am I about to blow things up" testing;
not "certification ready" testing):
* AR5212 + AR5112 synth
* AR5413 + AR5413 synth
* AR5416 + AR5113 synth
* AR9280
Modified:
head/sys/dev/ath/ath_hal/ar5416/ar2133.c
head/sys/dev/ath/ath_hal/ar9002/ar9280.c
Modified: head/sys/dev/ath/ath_hal/ar5416/ar2133.c
==============================================================================
--- head/sys/dev/ath/ath_hal/ar5416/ar2133.c Thu Oct 4 12:43:45 2012
(r241194)
+++ head/sys/dev/ath/ath_hal/ar5416/ar2133.c Thu Oct 4 15:42:45 2012
(r241195)
@@ -163,6 +163,33 @@ ar2133SetChannel(struct ath_hal *ah, con
OS_REG_WRITE(ah, AR_PHY_CCK_TX_CTRL,
txctl &~ AR_PHY_CCK_TX_CTRL_JAPAN);
}
+ /*
+ * Handle programming the RF synth for odd frequencies in the
+ * 4.9->5GHz range. This matches the programming from the
+ * later model 802.11abg RF synths.
+ *
+ * This interoperates on the quarter rate channels with the
+ * AR5112 and later RF synths. Please note that the synthesiser
+ * isn't able to completely accurately represent these frequencies
+ * (as the resolution in this reference is 2.5MHz) and thus it will
+ * be slightly "off centre." This matches the same slightly
+ * incorrect * centre frequency behaviour that the AR5112 and later
+ * channel selection code has.
+ *
+ * This is disabled because it hasn't been tested for regulatory
+ * compliance and neither have the NICs which would use it.
+ * So if you enable this code, you must first ensure that you've
+ * re-certified the NICs in question beforehand or you will be
+ * violating your local regulatory rules and breaking the law.
+ */
+#if 0
+ } else if (((freq % 5) == 2) && (freq <= 5435)) {
+ freq = freq - 2;
+ channelSel = ath_hal_reverseBits(
+ (uint32_t) (((freq - 4800) * 10) / 25 + 1), 8);
+ /* XXX what about for Howl/Sowl? */
+ aModeRefSel = ath_hal_reverseBits(0, 2);
+#endif
} else if ((freq % 20) == 0 && freq >= 5120) {
channelSel = ath_hal_reverseBits(((freq - 4800) / 20 << 2), 8);
if (AR_SREV_HOWL(ah) || AR_SREV_SOWL_10_OR_LATER(ah))
@@ -179,7 +206,8 @@ ar2133SetChannel(struct ath_hal *ah, con
channelSel = ath_hal_reverseBits((freq - 4800) / 5, 8);
aModeRefSel = ath_hal_reverseBits(1, 2);
} else {
- HALDEBUG(ah, HAL_DEBUG_ANY, "%s: invalid channel %u MHz\n",
+ HALDEBUG(ah, HAL_DEBUG_UNMASKABLE,
+ "%s: invalid channel %u MHz\n",
__func__, freq);
return AH_FALSE;
}
Modified: head/sys/dev/ath/ath_hal/ar9002/ar9280.c
==============================================================================
--- head/sys/dev/ath/ath_hal/ar9002/ar9280.c Thu Oct 4 12:43:45 2012
(r241194)
+++ head/sys/dev/ath/ath_hal/ar9002/ar9280.c Thu Oct 4 15:42:45 2012
(r241195)
@@ -132,9 +132,63 @@ ar9280SetChannel(struct ath_hal *ah, con
default:
aModeRefSel = 0;
/* Enable 2G (fractional) mode for channels which are
5MHz spaced */
- fracMode = 1;
- refDivA = 1;
- channelSel = (freq * 0x8000)/15;
+
+ /*
+ * Workaround for talking on PSB non-5MHz channels;
+ * the pre-Merlin chips only had a 2.5MHz channel
+ * spacing so some channels aren't reachable.
+
+ *
+ * This interoperates on the quarter rate channels
+ * with the AR5112 and later RF synths. Please note
+ * that the synthesiser isn't able to completely
+ * accurately represent these frequencies (as the
+ * resolution in this reference is 2.5MHz) and thus
+ * it will be slightly "off centre." This matches
+ * the same slightly incorrect centre frequency
+ * behaviour that the AR5112 and later channel
+ * selection code has.
+ *
+ * This also interoperates with the AR5416
+ * synthesiser modification for programming
+ * fractional frequencies in 5GHz mode. However
+ * that modification is also disabled by default.
+ *
+ * This is disabled because it hasn't been tested for
+ * regulatory compliance and neither have the NICs
+ * which would use it. So if you enable this code,
+ * you must first ensure that you've re-certified the
+ * NICs in question beforehand or you will be
+ * violating your local regulatory rules and breaking
+ * the law.
+ */
+#if 0
+ if (freq % 5 == 0) {
+#endif
+ /* Normal */
+ fracMode = 1;
+ refDivA = 1;
+ channelSel = (freq * 0x8000)/15;
+#if 0
+ } else {
+ /* Offset by 500KHz */
+ uint32_t f, ch, ch2;
+
+ fracMode = 1;
+ refDivA = 1;
+
+ /* Calculate the "adjusted" frequency */
+ f = freq - 2;
+ ch = (((f - 4800) * 10) / 25) + 1;
+
+ ch2 = ((ch * 25) / 5) + 9600;
+ channelSel = (ch2 * 0x4000) / 15;
+ //ath_hal_printf(ah,
+ // "%s: freq=%d, ch=%d, ch2=%d, "
+ // "channelSel=%d\n",
+ // __func__, freq, ch, ch2, channelSel);
+ }
+#endif
/* RefDivA setting */
OS_A_REG_RMW_FIELD(ah, AR_AN_SYNTH9,
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
