summaryrefslogtreecommitdiffstats
path: root/usr.sbin/acpi
diff options
context:
space:
mode:
authoradrian <adrian@FreeBSD.org>2012-10-04 15:42:45 +0000
committeradrian <adrian@FreeBSD.org>2012-10-04 15:42:45 +0000
commit284641708a4092b8adc9f735e726bd9dba1fe0fe (patch)
tree85cead7cd32fd714c5eeda6f6c9c22172dc1db8d /usr.sbin/acpi
parent2c1ce8e72bb03cd36f1ccfc733a88d538134f47f (diff)
downloadFreeBSD-src-284641708a4092b8adc9f735e726bd9dba1fe0fe.zip
FreeBSD-src-284641708a4092b8adc9f735e726bd9dba1fe0fe.tar.gz
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
Diffstat (limited to 'usr.sbin/acpi')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud