272292 |
30-Sep-2014 |
adrian |
Add initial support for the AR9485 CUS198 / CUS230 variants.
These variants have a few differences from the default AR9485 NIC, namely:
* a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity.
To make this possible:
* Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC.
This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf.
Tested:
* AR9380 (STA) * AR9485 CUS198 (STA)
Obtained from: Qualcomm Atheros, Linux ath9k
|
251655 |
12-Jun-2013 |
adrian |
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.
The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused.
This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so.
Tested:
* AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
|
251400 |
05-Jun-2013 |
adrian |
Add a new capability flag to announce that the chip implements LNA mixing for the RX path.
This is different to the div comb HAL flag, that says it actually can use this for RX diversity (the "slow" diversity path implemented but disabled in the AR9285 HAL code.)
Tested:
* AR9285, STA operation
|
249580 |
17-Apr-2013 |
adrian |
Setup needed tables for TPC on AR5416->AR9287 chips.
* Add ah_ratesArray[] to the ar5416 HAL state - this stores the maximum values permissable per rate. * Since different chip EEPROM formats store this value in a different place, store the HT40 power detector increment value in the ar5416 HAL state. * Modify the target power setup code to store the maximum values in the ar5416 HAL state rather than using a local variable. * Add ar5416RateToRateTable() - to convert a hardware rate code to the ratesArray enum / index. * Add ar5416GetTxRatePower() - which goes through the gymnastics required to correctly calculate the target TX power: + Add the power detector increment for ht40; + Take the power offset into account for AR9280 and later; + Offset the TX power correctly when doing open-loop TX power control; + Enforce the per-rate maximum value allowable.
Note - setting a TPC value of 0x0 in the TX descriptor on (at least) the AR9160 resulted in the TX power being very high indeed. This didn't happen on the AR9220. I'm guessing it's a chip bug that was fixed at some point. So for now, just assume the AR5416/AR5418 and AR9130 are also suspect and clamp the minimum value here at 1.
Tested:
* AR5416, AR9160, AR9220 hostap, verified using (2GHz) spectrum analyser * Looked at target TX power in TX descriptor (using athalq) as well as TX power on the spectrum analyser.
TODO:
* The TX descriptor code sets the target TX power to 0 for AR9285 chips. I'm not yet sure why. Disable this for TPC and ensure that the TPC TX power is set. * AR9280, AR9285, AR9227, AR9287 testing! * 5GHz testing!
Quirks:
* The per-packet TPC code is only exercised when the tpc sysctl is set to 1. (dev.ath.X.tpc=1.) This needs to be done before you bring the interface up. * When TPC is enabled, setting the TX power doesn't end up with a call through to the HAL to update the maximum TX power. So ensure that you set the TPC sysctl before you bring the interface up and configure a lower TX power or the hardware will be clamped by the lower TX power (at least until the next channel change.)
Thanks to Qualcomm Atheros for all the hardware, and Sam Leffler for use of his spectrum analyser to verify the TX channel power.
|
244943 |
02-Jan-2013 |
adrian |
Bring over the basic spectral scan framework code from Qualcomm Atheros.
This includes the HAL routines to setup, enable/activate/disable spectral scan and configure the relevant registers.
This still requires driver interaction to enable spectral scan reporting. Specifically:
* call ah_spectralConfigure() to configure and enable spectral scan; * .. there's currently no way to disable spectral scan... that will have to follow. * call ah_spectralStart() to force start a spectral report; * call ah_spectralStop() to force stop an active spectral report.
The spectral scan results appear as PHY errors (type 0x5 on the AR9280, same as radar) but with the spectral scan bit set (0x10 in the last byte of the frame) identifying it as a spectral report rather than a radar FFT report.
Caveats:
* It's likely quite difficult to run spectral _and_ radar at the same time. Enabling spectral scan disables the radar thresholds but leaves radar enabled. Thus, the driver (for now) needs to ensure that only one or the other is enabled.
* .. it needs testing on HT40 mode.
Tested:
* AR9280 in STA mode, HT/20 only
TODO:
* Test on AR9285, AR9287; * Test in both HT20 and HT40 modes; * .. all the driver glue.
Obtained from: Qualcomm Atheros
|
241195 |
04-Oct-2012 |
adrian |
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
|
240471 |
13-Sep-2012 |
adrian |
Don't use AR_PHY_MODE to setup half/quarter rate.
I'm not sure where in the deep, distant past I found the AR_PHY_MODE registers for half/quarter rate mode, but unfortunately that doesn't seem to work "right" for non-AR9280 chips.
Specifically:
* don't touch AR_PHY_MODE * set the PLL bits when configuring half/quarter rate
I've verified this on the AR9280 (5ghz fast clock) and the AR5416.
The AR9280 works in both half/quarter rate; the AR5416 unfortunately only currently works at half rate. It fails to calibrate on quarter rate.
|
237611 |
26-Jun-2012 |
adrian |
Bring over the initial 802.11n bluetooth coexistence support code.
The Linux ath9k btcoex code is based off of this code.
Note this doesn't actually implement functional btcoex; there's some driver glue and a whole lot of verification that is required.
On the other hand, I do have the AR9285+BT and AR9287+BT NICs which this code supports..
Obtained from: Qualcomm Atheros, Linux ath9k
|
235957 |
25-May-2012 |
adrian |
Prepare for improved (read: pcie) suspend/resume support.
* Flesh out the pcie disable method for 11n chips, as they were defaulting to the AR5212 (empty) PCIe disable method.
* Add accessor macros for the HAL PCIe enable/disable calls.
* Call disable on ath_suspend()
* Call enable on ath_resume()
NOTE:
* This has nothing to do with the NIC sleep/run state - the NIC still will stay in network-run state rather than supporting network-sleep state. This is preparation work for supporting correct suspend/resume WARs for the 11n PCIe NICs.
TODO:
* It may be feasible at this point to keep the chip powered down during initial probe/attach and only power it up upon the first configure/reset pass. This however would require correct (for values of "correct") tracking of the NIC power configuration state from the driver and that just isn't attempted at the moment.
Tested:
* AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).
|
230847 |
31-Jan-2012 |
adrian |
Support AR9281/AR5B91 - a 1x2 stream device based on the AR9280.
* Override the TX/RX stream count if the EEPROM reports a single RX or TX stream, rather than assuming the device will always be a 2x2 strea device.
* For AR9280 devices, don't hard-code 2x2 stream. Instead, allow the ar5416FillCapabilityInfo() routine to correctly determine things.
The latter should be done for all 11n chips now that ar5416FillCapabilityInfo() will set the TX/RX stream count based on the active TX/RX chainmask in the EEPROM.
Thanks to Maciej Milewski for donating some AR9281 NICs to me for testing.
|
228517 |
15-Dec-2011 |
adrian |
Add the 11n chipset RF frontends to the linker set, even though they're not attached this way.
The AR5212 based NICs have a variety of RF frontends, so there's a linker set which the AR5212 attach routine calls. The same framework is used for the AR5416 and later but as there's a fixed RF frontend for each 11n NIC, it is just directly attached.
However in the case of compiling a cut down HAL (eg _just_ AR9130 WMAC support), the linker set ends up being empty and this causes the compile to fail.
So this is just a workaround for that - it means those users who wish an 11n only HAL can compile the 11n chipsets and RF frontend they need, and just "ath_ar5212" for the AR5212/AR5416 common code, and it'll just work.
Sponsored by: Hobnob, Inc.
|
225883 |
30-Sep-2011 |
adrian |
Fix a corner case in the HAL debugging changes, where ah was NULL.
Although I tried to fix this earlier by introducing HALDEBUG_G(), it turns out there seem to be other cases where the pointer value is still NULL.
* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL before deferencing it * Remove HALDEBUG_G() as it's no longer needed
This is hopefully a merge candidate for 9.0-RELEASE as enabling debugging at startup could result in a kernel panic.
|
224644 |
04-Aug-2011 |
adrian |
Undo this for now. It's "right", but it means everything will rely on the ar9130 code.
Since at least one kernel config specifies individual ath HAL chips rather than just "device ath_hal" (arm/AVILA), I'm doing this so people aren't caught out when they update to -HEAD or 9.0 and discover their ath setup doesn't compile.
I'll revisit this with a proper fix sometime before 9.0-RELEASE.
Approved by: re (kib, blanket) Pointed out by: ray@ Pointy hat to: adrian@
|
224634 |
03-Aug-2011 |
adrian |
Add in a dirty hack that allows for AR9280/AR9285/AR9287 embedded systems, in the same way that AR9130 embedded systems work.
This isn't -everything- that is required - the PCI glue still needs to be taught about the eepromdata hint, along the same lines as the AHB glue.
Approved by: re (kib, blanket)
|
224519 |
30-Jul-2011 |
adrian |
Introduce the FRAC_5G EEPROM parameter.
This seems to indicate whether to program the NIC for fractional 5ghz mode (ie, 5mhz spaced channels, rather than 10 or 20mhz spacing) or not. The default (0) seems to mean "only program fractional mode if needed". A different value (eg 1) seems to always enable fractional 5ghz mode regardless of the frequency.
Obtained from: Atheros Approved by: re (kib)
|
222584 |
01-Jun-2011 |
adrian |
Add some missing DFS chipset functionality to the FreeBSD HAL.
Please note - this doesn't in any way constitute a full DFS implementation, it merely adds the relevant capability bits and radar detection threshold register access.
The particulars:
* Add new capability bits outlining what the DFS capabilities are of the various chipsets. * Add HAL methods to set and get the radar related register values. * Add AR5212 and AR5416+ DFS radar related register value routines. * Add a missing HAL phy error code that's related to radar event processing. * Add HAL_PHYERR_PARAM, a data type that encapsulates the radar register values.
The AR5212 routines are just for completeness. The AR5416 routines are a super-set of those; I may later on do a drive-by pass to tidy up duplicate code.
Obtained from: Linux, Atheros
|
222432 |
29-May-2011 |
adrian |
Teach if_ath about devices which have short-GI in 20MHz channel modes.
This has been disabled until now because there hasn't been any supported device which has this feature. Since the AR9287 is the first device to support it, and since now the HAL has functional AR9287+11n support, flip this on.
|
222312 |
26-May-2011 |
adrian |
Bring over the AR5416 per-rate TX power code, modified to use the AR9287 EEPROM layout.
The AR9287 only supports 2ghz, so I've removed the 5ghz code (but left the 5ghz edge flags in there for now) and hard-coded the 2ghz-only path.
Whilst I'm there, fix a typo (ar9285->ar9287.)
This meets basic TX throughput testing - iperf TX tests == 27-28mbit in 11g, matching the rest of my 11g kit.
|
222301 |
26-May-2011 |
adrian |
Bring over my AR9287 work in progress.
It isn't linked into the build because it's missing the TX power and PDADC programming code.
This code is mostly based on the ath9k codebase, compared against the Atheros codebase as appropriate.
What's implemented:
* probe/attach * EEPROM board value programming * RX initial calibration * radio channel programming * general MAC / baseband setup * async fifo setup * open-loop tx power calibration
What's missing before it can be enabled by default:
* TX power / calibration setting code * closed-loop tx power calibration routines * TSF2 handling * generic timer support from ath9k
Obtained from: Atheros, ath9k
|
221833 |
13-May-2011 |
adrian |
Some diversity changes relating to AR9285.
* grab the main, alt and selected LNA config * add some optional / disabled logging code * add a check to reject packets with an invalid main rssi too, in case the alt is the active receive chain and main is -ve.
Note: The software-controlled combined diversity code is still disabled.
|
221694 |
09-May-2011 |
adrian |
Import some initial Kite fixed diversity code from Atheros.
For now, the diversity settings are controlled by 'txantenna', -not- rxantenna. This is because the earlier chipsets had controllable TX diversity; the RX antenna setting twiddles the default antenna register. I'll try sort that stuff out at some point.
Call the antenna switch function from the board setup function so scans, channel changes, mode changes, etc don't set the diversity back to a default state too far from what's intended.
Things to todo:
* Squirrel away the last antenna diversity/combining parameters and restore them during board setup if HAL_ANT_VARIABLE is defined. That way scans, etc don't reset the diversity settings.
* Add some more public facing statistics, rather than what's simply logged under HAL_DEBUG_DIVERSITY.
For now, the fixed antenna settings behave better than variable settings for me. I have some further fiddling to do..
Obtained from: Atheros
|
221667 |
08-May-2011 |
adrian |
Fix the 5ghz fast clock logic.
The macro which I incorrectly copied into ah_internal.h assumed that it'd be called with an AR_SREV_MERLIN_20() check to ensure it was only enabled for Merlin (AR9280) silicon revision 2.0 or later.
Trouble is, the 5GHz fast clock EEPROM flag is only valid for EEPROM revision 16 or greater; it's assumed to be enabled by default for Merlin rev >= 2.0. This meant it'd be incorrectly set for AR5416 and AR9160 in 5GHz mode.
This would have affected non-default clock timings such as SIFS, ACK and slot time. The incorrect slot time was very likely wrong for 5ghz mode.
|
221603 |
07-May-2011 |
adrian |
Do a HAL capabilities sync pass based on the Atheros HAL.
* Shuffle some of the capability numbers around to match the Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros HAL which will be be shortly used when new chipsets are added (HAL SGI-20 support is for Kiwi/AR9287 support); for TX aggregation (MBSSID aggregate support, WDS aggregation support); CST/GTT support for carrier sense/TX timeout.
|
220590 |
13-Apr-2011 |
adrian |
Port over a TX gain fix from ath9k specific to the AR9285 (Kite) and AR9271. Note: this HAL currently only supports the AR9285.
From Linux ath9k:
The problem is that when the attenuation is increased, the rate will start to drop from MCS7 -> MCS6, and finally will see MCS1 -> CCK_11Mbps. When the rate is changed b/w CCK and OFDM, it will use register desired_scale to calculate how much tx gain need to change.
The output power with the same tx gain for CCK and OFDM modulated signals are different. This difference is constant for AR9280 but not AR9285/AR9271. It has different PA architecture a constant. So it should be calibrated against this PA characteristic.
The driver has to read the calibrated values from EEPROM and set the tx power registers accordingly.
|
219627 |
14-Mar-2011 |
adrian |
Bring over the AR9285 board update code from ath9k.
This does a few things in particular:
* Abstracts out the gain control settings into a separate function; * Configure antenna diversity, LNA and antenna gain parameters; * Configure ob/db entries - the later v4k EEPROM modal revisions have multiple OB/DB parameters which are used for some form of calibration. Although the radio does have defaults for each, the EEPROM can override them.
This resolves the AR2427 related issues I've been seeing and makes it stable at all 11g rates for both TX and RX.
|
219605 |
13-Mar-2011 |
adrian |
Fix the nfarray offsets for the ar2133/ar5133 radio - (AR5416, AR9160, etc.)
The offsets didn't match the assumption that nfarray[] is ordered by the chainmask bits and programmed via the register order in ar5416_cca_regs[]. This repairs that damage and ensures that chain 1 is programmed correctly. (And extension channels will now be programmed correctly also.)
This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416 setups - because Chain 1 would be programmed -80 or -85 dBm, which is higher than the actual noise floor and thus convincing the radio that indeed it can't ever transmit.
|
219393 |
08-Mar-2011 |
adrian |
Implement open-loop TX power control (OLC) for Merlin (AR9280) and generally tidy up the TX power programming code.
Enforce that the TX power offset for Merlin is -5 dBm, rather than any other value programmable in the EEPROM. This requires some further code to be ported over from ath9k, so until that is done and tested, fail to attach NICs whose TX power offset isn't -5 dBm.
This improves both legacy and HT transmission on my merlin board. It allows for stable MCS TX up to MCS15.
Specifics:
* Refactor out a bunch of the TX power calibration code - setting/obtaining the power detector / gain boundaries, programming the PDADC * Take the -5 dBm TX power offset into account on Merlin - "0" in the per-rate TX power register means -5 dBm, not 0 dBm * When doing OLC * Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling with the TX power, to avoid the TX power values from wrapping when low. * Implement the 1 dBm cck power offset when doing OLC * Implement temperature compensation for 2.4ghz mode when doing OLC * Implement an AR9280 specific TX power calibration routine which includes the OLC twiddles, leaving the earlier chipset path (AR5416, AR9160) alone
Whilst here, use these refactored routines for the AR9285 TX power calibration/programming code and enforce correct overflow/underflow handling when fiddling with TX power values.
Obtained from: linux ath9k
|
219218 |
03-Mar-2011 |
adrian |
Port over ar5416OverrideIni() from ath9k ar5008_hw_override_ini().
* change the BB gating logic to explicitly define which chips are covered; the ath9k method isn't as clear. * don't disable the BB gating for now, the ar5416 initvals have it, and the ar9160 initval sets it to 0x0. Figure out why before re-enabling this. * migrate the Merlin (ar9280) applicable WAR from the Kite (ar9285) code (which won't get called for Merlin!) and stuff it in here.
|
218436 |
08-Feb-2011 |
adrian |
There's apparently a bug with Merlin (AR9280) and later chipsets where putting descriptors (not buffers) across a 4k page boundary can cause issues. I've not seen it in production myself but it apparently can cause problems.
So, in preparation for addressing this workaround, (re)-expose the particular HAL capability bit which marks whether the chipset has support for cross-4k- boundary transactions or not.
A subsequent commit will modify the descriptor allocation to avoid allocating descriptor entries that straddle a 4k page boundary.
|
218150 |
01-Feb-2011 |
adrian |
Add a new capability which reports the number of spatial streams a device supports.
The higher levels (net80211, if_ath, ath_rate) need this to make correct choices about what MCS capabilities to advertise and what MCS rates are able to be TXed.
In summary:
* AR5416 - 2/3 antennas, 2x2 streams * AR9160 - 2/3 antennas, 2x2 streams * AR9220 - 2 antennas, 2x2 sstraems * AR9280 - 2 antennas, 2x2 streams * AR9285 - 2 antennas but with antenna diversity, 1x1 stream
|
218068 |
29-Jan-2011 |
adrian |
Bring over some NF calibration changes from ath9k.
Each different radio chipset has a different "good" range of CCA (clear channel access) parameters where, if you write something out of range, it's possible the radio will go deaf.
Also, since apparently occasionally reading the NF calibration returns "wrong" values, so enforce those limits on what is being written into the CCA register.
Write a default value if there's no history available.
This isn't the case right now but it may be later on when "off-channel" scanning occurs without init'ing or changing the NF history buffer. (As each channel may have a different noise floor; so scanning or other off-channel activity shouldn't affect the NF history of the current channel.)
|
217684 |
21-Jan-2011 |
adrian |
ANI changes #1 - split out the ANI polling from the RxMonitor hook.
The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received.
Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
|