272461 |
03-Oct-2014 |
gjb |
Copy stable/10@r272459 to releng/10.1 as part of the 10.1-RELEASE process.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
256281 |
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
251656 |
12-Jun-2013 |
adrian |
Set the antenna "config group" field.
The reference HAL pushes a config group parameter to the driver layer to inform it which particular chip behaviour to implement.
This particular value tags it as an AR9285.
|
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
|
251643 |
12-Jun-2013 |
adrian |
Remove the AR9285 specific structure for LNA diversity and use the HAL.
The AR9300 HAL update included the LNA diversity configuration information so it can be used in the AR9485 configuration code.
|
251483 |
07-Jun-2013 |
adrian |
Add bluetooth fixes to the AR5416/AR92xx HAL:
* Call the bluetooth setup function during the reset path, so the bluetooth settings are actually initialised. * Call the AR9285 diversity functions during bluetooth setup; so the AR9285 diversity and antenna configuration registers are correctly programmed * Misc debugging info.
Tested:
* AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth coexistence but it's part of what I'm currently using.
|
251442 |
05-Jun-2013 |
adrian |
Enable slow diversity combining for the AR9285.
Now that I understand what's going on - and the RX antenna array maps to what the receive LNA configuration actually is - I feel comfortable in enabling this.
If people do have issues with this, there's enough debugging now available that we have a chance to diagnose it without writing it up as 'weird crap.'
Tested:
* AR9285 STA w/ diversity combining enabled in EEPROM
TODO:
* (More) testing in hostap mode
|
251441 |
05-Jun-2013 |
adrian |
As a temporary work-around (read: until there's a nice API for exposing and controlling this form of antenna diversity) - print out the AR9285 antenna diversity configuration at attach time.
This will help track down and diagose if/when people have connectivity issues on cards (eg if they connect a single antenna to LNA1, yet the card has RX configured to only occur on LNA2.)
Tested:
* AR9285 w/ antenna diversity enabled in EEPROM; * AR9285 w/ antenna diversity disabled in EEPROM; mapping only to a single antenna (LNA1.)
|
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.
|
248182 |
12-Mar-2013 |
adrian |
Use the correct antenna configuration variable here. "diversity" just controls whether it's on or off.
Found by: clang
|
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
|
243842 |
04-Dec-2012 |
adrian |
Override the BT coex parameter function for the AR9285.
|
243841 |
04-Dec-2012 |
adrian |
Reformat/reindent.
|
242408 |
31-Oct-2012 |
adrian |
HAL updates!
* Add some more ANI spur immunity levels. * For AR5111 radios attached to an AR5212, limit the 5GHz channels that are available. A later revision of the AR5111 supports the 4.9GHz PSB channels but right now there's no check in place for the radio revision.
If someone wants PSB support on AR5212+AR5111 radios then please let me know and I'll add the relevant version check.
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.
|
240449 |
13-Sep-2012 |
adrian |
Enable fractional 5G mode on half/quarter rate channels.
Obtained from: Linux ath9k
|
239890 |
30-Aug-2012 |
adrian |
Migrate the AR9285 diversity configuration LNA configuration to use some HAL definitions rather than local definitions.
The original source (ath9k) pulled this stuff from the QCA driver and removed the HAL_* prefix. I'm just restoring the correct order of things.
Obtained from: Qualcomm Atheros
|
239803 |
29-Aug-2012 |
adrian |
Set the HAL combined antenna diversity capability if the AR9285 EEPROM settings allow it.
|
239703 |
26-Aug-2012 |
adrian |
Add EEPROM data hooks for the AR9287.
Tested: * AP99 Reference board (AR7241 + AR9287)
|
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
|
237184 |
17-Jun-2012 |
adrian |
AR9287 tidyups:
* Add an OS_A_REG_WRITE() routine - analog writes require a 100usec delay on AR9280 and later, so create a method to do it.
* Use it for the AR9287 analog writes.
* Re-indent and style(9) the code.
|
237183 |
17-Jun-2012 |
adrian |
Add an disabled workaround for the AR9285SE.
This just requires a little HAL change (add a new config parameter) and some glue in if_ath_pci.c, however I'm leaving this up for someone else to do.
Obtained from: Qualcomm Atheros
|
237182 |
17-Jun-2012 |
adrian |
Bring over the AR9285 specific PCIe suspend/resume/ASPM workarounds.
Obtained from: Qualcomm Atheros, Linux ath9k
|
236039 |
26-May-2012 |
adrian |
Add the AR9280 workarounds for PCIe suspend/resume.
These aren't strictly needed at the moment as we're not doing APSM and forcing the NIC in and out of network sleep. But, they don't hurt.
Tested:
* AR9280 (mini-PCIe)
Obtained from: Qualcomm Atheros, Linux ath9k
|
235972 |
25-May-2012 |
adrian |
oops - ath_hal_disablepcie is actually destined for another purpose, not to disable the PCIe PHY in prepration for reset.
Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
|
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).
|
234510 |
20-Apr-2012 |
adrian |
.. oops.
|
234508 |
20-Apr-2012 |
adrian |
"Upgrade" the AR9285 code to support PCI/ART EEPROM on flash.
I've just verified that this boots on an Atheros AP91. I haven't verified it with traffic though, so YMMV.
|
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.
|
230147 |
15-Jan-2012 |
adrian |
Break out the "memory" EEPROM data read method from being AR9130 specific to being more generic.
Other embedded SoCs also throw the configuration/PCI register info into flash.
For now I'm just hard-coding the AR9280 option (for on-board AR9220's on AP94 and commercial designs (eg D-Link DIR-825.))
TODO:
* Figure out how to support it for all 11n SoC NICs by doing it in ar5416InitState(); * Don't hard-code the EEPROM size - add another field which is set by the relevant chip initialisation code. * 'owl_eep_start_loc' may need to be overridden in some cases to 0x0. I need to do some further digging.
|
228833 |
23-Dec-2011 |
adrian |
Remove unused #define's.
Pointy hat to: adrian, for not properly reading things when he copied ar9285.h to ar9287.h.
|
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.
|
227387 |
09-Nov-2011 |
adrian |
Tidy up the AR9287 HAL a tiny bit - fix up AR9280 references.
|
227373 |
09-Nov-2011 |
adrian |
Add in some more PCI/PCIe differentiation.
|
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)
|
224515 |
30-Jul-2011 |
adrian |
Fix the initial calibration sample count when doing ADC calibrations.
Obtained from: Atheros Approved by: re (kib)
|
224243 |
21-Jul-2011 |
adrian |
Break out the PLL setup into (mostly) per-chip methods, rather than polluting the AR5416 code with later chipset support.
Note: ar9280InitPLL() supports Merlin (AR9280) and later (AR9285, AR9287.)
Submitted by: ssgriffonuser@gmail.com Approved by: re (kib)
|
223615 |
28-Jun-2011 |
adrian |
Make sure the extended regdomain word is initialised.
As with the AR9285, the AR9287 has a default word of 0x1F which means all the various bits in that field are set on by default.
|
223466 |
23-Jun-2011 |
adrian |
Re-introduce a global ath_hal_debug again for now, whilst I figure out what to do about the few cases where the HAL state isn't available (regdomain) or isn't yet setup (probe/attach.)
The global ath_hal_debug now affects all instances of the HAL.
This also restores the ability for probe/attach debugging to work; as the sysctl tree may not be attached at that point. Users can just set the global "hw.ath.hal.debug" to a suitable value to enable probe/attach related debugging.
|
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.
|
222424 |
28-May-2011 |
adrian |
Fix AR9287 operation when >1 TX chain is enabled.
I didn't pick this up with the initial commit because I was only testing with 11bg.
|
222324 |
26-May-2011 |
adrian |
Fix a macro name - it's currently unused in this file however, but keep it consistent with ar9280.c.
|
222323 |
26-May-2011 |
adrian |
Revert this erroneous commit and re-disable the AR9285 combined antenna diversity.
|
222316 |
26-May-2011 |
adrian |
Remove the three-chain scaled power check for the AR9287 - it isn't needed.
|
222314 |
26-May-2011 |
adrian |
Add some open-loop TX power debugging for AR9287.
|
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.
|
222310 |
26-May-2011 |
adrian |
Flesh out ar9287SetTransmitPower() based on the AR9285 routine.
Hard-code the per-rate TX power at 5dBm for now so testing can be done.
This passes initial TX testing in 11g mode (but, obviously, at 5dBm.)
|
222308 |
26-May-2011 |
adrian |
Flesh out the TX power calibration for the AR9287.
I'm assuming for now that the AR9287 is only open-loop TX power control (as mine is) so I've hard-coded the attach path to fail if the NIC is not open-loop.
This greatly simplifies the TX calibration path and the amount of code which needs to be ported over.
This still isn't complete - the rate calculation code still needs to be ported and it all needs to be glued together.
Obtained from: Linux ath9k
|
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
|
222276 |
25-May-2011 |
adrian |
Tidy up the ANI API in preparation for looking to expose some more of the ANI statistics and committing some tools which use these.
* Change HAL_ANI_* commands _back_ to be numerical, rather than a bitmap; * modify access to the ANI control bitmap to convert a command to a bitmap; * Fix the ANI noise immunity fiddling for CCK errors - it wasn't checking whether noise immunity was disabled or not.
|
222157 |
21-May-2011 |
adrian |
The Merlin analog register bank is from 0x7800 -> 0x78fc; fix the code to reflect this.
|
221875 |
14-May-2011 |
adrian |
Fixes from the Atheros HAL - formatting; update Merlin checks to be consistent. Nothing functional should change with this commit.
|
221837 |
13-May-2011 |
adrian |
Only do open loop power control and temperature compensation for the AR9280 based NICs if it's actually enabled.
Some of the OLC code was erroneously called during setup and calibration. This may have caused some incorrect behaviour.
|
221834 |
13-May-2011 |
adrian |
Remove duplicate code - add a function which calculates the ratesArray[] table which contains the per-rate target TX power.
This code is shared between the v14 eeprom board setup (AR5416, AR9160, AR9280) and will also be used by the upcoming Kite (AR9287) support.
|
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.
|
221806 |
12-May-2011 |
adrian |
Break out the AR9285 analog registers from ar5416/ar5416phy.h and put them in a new header file, ar9002/ar9285_an.h.
Shuffle the AR9280 analog registers in ar5416/ar541phy.h into a contiguous spot.
|
221722 |
10-May-2011 |
adrian |
AR9285 (Kite) fixes.
* Correct some of the silicon revision checks to match what the Atheros HAL does. (See [1] below.)
* Move the PA cal and init cal method assignment to -after- the mac version/revision IDs are stored. The AR9285 init cal was never being called.
* Enable ANI.
Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen in the wild. Linux ath9k simply removed the prototype code from their codebase. I'm going to leave it in there for now but make it conditionally compilable in the future.
Obtained from: Atheros
|
221702 |
09-May-2011 |
adrian |
Disable diversity combining support until I can get a firm answer from Atheros as to what/when this is supposed to be enabled.
Using the default RX fast diversity settings seems to help quite a bit.
Whilst I'm here, change the prototype to return HAL_BOOL rather than int.
|
221700 |
09-May-2011 |
adrian |
Disable TX STBC - it isn't used for now, but it isn't supported on Kite.
|
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
|
221693 |
09-May-2011 |
adrian |
Remove an un-needed PA cal call here.
|
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.
|
221596 |
07-May-2011 |
adrian |
Read in the extended regulatory domain flags so future code can use them.
These describe FCC/Japan channel and DFS behaviour.
The AR9285 and later chips don't set these bits in the eeprom, the correct behaviour is to just assume all five bits are enabled.
|
221574 |
07-May-2011 |
adrian |
Change AR_SREV_OWL_{X}_OR_LATER to AR_SREV_5416_{X}_OR_LATER.
For now, these are equivalent macros. AR_SREV_OWL{X}_OR_LATER will later change to exclude Howl (AR9130) in line with what the Atheros HAL does.
This should not functionally change anything.
Obtained from: Atheros
|
220989 |
24-Apr-2011 |
adrian |
Use the refactored ar5416WriteTxPowerRateRegisters() call in the ar9285 code.
|
220946 |
22-Apr-2011 |
adrian |
Bring over a pdadc calibration fix from ath9k - unused power detector gain values should be 58, not the previous values.
Obtained From: linux ath9k
|
220722 |
16-Apr-2011 |
adrian |
Don't do Kite antenna switch selection this way (for now); antenna diversity is done elsewhere now.
|
220713 |
16-Apr-2011 |
adrian |
Remove some duplicate code from the AR9285 TX power configuration path.
|
220600 |
13-Apr-2011 |
adrian |
Add in the last bit of the HAL support for Kite diversity.
* add a new method, specifically for doing per-RX packet antenna diversity * set that HAL method only if it's Kite and a Kite chip that does diversity.
|
220599 |
13-Apr-2011 |
adrian |
More kite diversity related changes.
* add a diversity flag to the HAL debugging section * add a check to make sure the kite diversity code doesn't run on boards that don't require it, as not all Kite chips will implement it. * add some debug statements when the diversity code makes changes to the antenna diversity/combining setup.
|
220593 |
13-Apr-2011 |
adrian |
Bring over the antenna diversity logic support for Kite.
Again, this is just the code ported from ath9k and included in the build, it isn't yet enabled.
|
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.
|
220587 |
13-Apr-2011 |
adrian |
Add the initial AR9285 PHY glue for supporting antenna diversity. This code isn't currently used anywhere; it's just linked into the build.
|
220539 |
11-Apr-2011 |
adrian |
De-dup the ar5416 rates array definition.
|
220325 |
04-Apr-2011 |
adrian |
Commit missing bits from the last commit:
* add the hal capability flag * make sure its disabled for the ar9280/ar9285.
|
220027 |
26-Mar-2011 |
adrian |
Introduce hardware PS-POLL support in the HAL.
Linux ath9k only enables this for AR9280 and later NICs; so create a capability for it so it isn't enabled for earlier NICs.
Enabling hardware PS-POLL support will come in a later commit and will be disabled by default.
|
219979 |
25-Mar-2011 |
adrian |
Flip ANI on for the AR5416 and later chips. I haven't verified it on the AR9285 so I'll leave it off for that.
Ath9k sources indiciate that one of the ANI modes interferes with RIFS detection, so match ath9k and disable that.
|
219852 |
22-Mar-2011 |
adrian |
Even though it's very unlikely the misc mode register setting at -attach- would be a problem, make sure it isn't overwritten by whatever is in there at cold reset.
This brings the > ar5416 init path treatment of AR_MISC_MODE.
|
219628 |
14-Mar-2011 |
adrian |
Fix typo that snuck in.
|
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.
|
219586 |
13-Mar-2011 |
adrian |
Move out some of the shared eeprom board value calculation routines into ah.c rather than duplicating them for the v14 (ar5416+) and v4k (ar9285) codebases.
Further chipsets (eg the AR9287) have yet another EEPROM format which will use these routines to calculate things.
|
219585 |
13-Mar-2011 |
adrian |
* Add in some board settings debugging to log what's being written to the TX closed-loop power control registers. * Modify a couple of functions to take the register chain number, rather than the regChainOffset value. This allows for the register chain to be logged.
|
219481 |
11-Mar-2011 |
adrian |
Port over the AR9285 PA calibration and initial calibration code from Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what is supposed to be called for what chipsets, so I'm ignoring the rest of it and just porting the AR9285 init cal path as-is and leaving the rest alone. Subsequent commits may also tidy up the Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
|
219479 |
11-Mar-2011 |
adrian |
Remove the ar9285FillVpdTable() and just use ar5416FillVpdTable().
|
219475 |
11-Mar-2011 |
adrian |
Bring over the same fix from the AR5416 PDADC calibration code.
The ath9k driver has a unified boundary/pdadc function, whereas ours is split into two (one for each EEPROM type.) This is why the AR9280 check is done here where we could safely assume it'll always be AR9280 or later.
|
219450 |
10-Mar-2011 |
adrian |
Kite is a 1x1 stream device.
|
219445 |
10-Mar-2011 |
adrian |
Now that the power curve adjustment code is in, disable the error check I introduced earlier, and turn it into debugging output.
|
219444 |
10-Mar-2011 |
adrian |
Port over the v14 eeprom PDADC curve changes from ath9k.
It looks like these apply in both open and closed loop TX power control, but the only merlin boards i have either have OL -or- a non-default power offset, not both.
|
219441 |
10-Mar-2011 |
adrian |
Introduce the Merlin PWDCLKIND workaround.
This is something bus clock related from what I can gather. It is needed for the AR9220 based Ubiquiti SR71-12 and SR71-15 Mini-PCI NICs.
(Note: those NICs don't work right now because of earlier changes to handle power table offset correctly. That'll be resolved in a follow-up commit.)
|
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.
|
218764 |
17-Feb-2011 |
adrian |
Add in ANI parameters for the AR9280. These aren't enabled by default as they're likely not entirely correct, but they give people something to toy with to compare behaviour/performance.
Disable the anti-noise part, as this apparently interferes with RIFS. I haven't verified this.
|
218708 |
15-Feb-2011 |
adrian |
Disable flipping antennas for AR9280.
Flipping antennas when doing 11n would cause all kinds of strange issues. Just don't do it for now and when it comes time to do it, don't do it 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.
|
218416 |
07-Feb-2011 |
adrian |
Use analog delay macro for modifying an analog register.
|
218183 |
02-Feb-2011 |
adrian |
Call the correct ANI Attach routine.
|
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.)
|
218061 |
29-Jan-2011 |
adrian |
Add a check for the AR9285E; I have no idea what this is.
The only other changes in ath9k for the AR9285E revolve around sleep modes which are not fully implemented here yet.
|
217811 |
25-Jan-2011 |
adrian |
Commit updated AR9285 (Kite) v2 initvals from ath9k.
|
217751 |
23-Jan-2011 |
adrian |
Update the AR9280v2 inivals to match what is in Linux ath9k.
This repairs the behaviour of my AR9280 - both radio chains now seem to correctly be receiving.
|
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.
|
217641 |
20-Jan-2011 |
adrian |
ar9280SetAntennaSwitch() was using the AR5416 chainmasks (3 chains) rather than the AR9280 chainmasks (2 chains)
|
217632 |
20-Jan-2011 |
adrian |
Include the device ids for the AR2427.
This is apparently an AR9285 with the 802.11n specific bits disabled.
This code is completely untested; I'm doing this in response to users who wish to test the functionality out. It's likely as buggy as the AR9285 support is in FreeBSD at the moment.
|
217631 |
20-Jan-2011 |
adrian |
Push the non-AR5416 related stuff into chipset specific directories.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further commits will make it even more crowded. Now is a good time to shuffle these files out before any more extensive work is done on them.
Create an ar9003 directory whilst I'm here; ar9003 specific chipset code will eventually live there.
|