I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.
So - restore functionality.
Tested:
* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
Enough to trigger ANI to get upset and generate useful data.
the top-level HAL.
The athstats program is blindly using a copy of the ar5212 ANI stats structure
to pull out ANI statistics/state and this is problematic for the AR9300
HAL.
So:
* Define HAL_ANI_STATS and HAL_ANI_STATE
* Use HAL_ANI_STATS inside the AR5212 HAL
This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when
exporting it to userland; that'll come in the next commit.
rathe than private in each HAL module.
Whilst here, modify ath_hal_private to always have the per-channel
noisefloor stats, rather than conditionally. This just makes
life easier in general (no strange ABI differences between different
HAL compile options.)
Add a couple of methods (clear/reset, add) rather than using
hand-rolled versions of things.
in prep for the next NF calibration pass.
Totally missing braces. Damn you C.
Submitted by: Sascha Wildner <swildner@dragonflybsd.org>
MFC after: 1 week
ath kernel module:
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) {
^
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
1 error generated.
This warning occurs because both lp[0] and target are unsigned, so the
subtraction expression is also unsigned, and calling abs() is a no-op.
However, the intention was to look at the absolute difference between
the two unsigned quantities. Introduce a small static function to
clarify what we're doing, and call that instead.
Reviewed by: adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1212
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
The AR9380 and later chips have a 128KiB register window, so the register
read diag api needs changing.
The tools are about to be updated as well. No, they're not backwards
compatible.
This seems to probe/attach as an AR9485 and thus nothing else besides
adding the device id seems to be required.
ath0: <Atheros AR1111> mem 0xf4800000-0xf487ffff irq 19 at device 0.0 on pci5
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: AR9485 mac 576.1 RF5110 phy 1926.8
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
The NIC I have here is a 1 antenna, 2GHz only device.
Thankyou to Jim Thompson <jim@netgate.com> for the AR1111 NIC.
Tested:
* AR1111 (pretending not to be an AR9485, but failing miserably);
STA mode with powersave.
Relnotes: yes
Sponsored by: Netgate
Some code will appear soon that is actually setting the chip powerstate
separate from the self-generated frames power state.
* Allow the AR5416 family chips to actually have the power state changed
from the self generated state change.
Tested (STA mode):
* AR5210
* AR5211
* AR5412
* AR5413
* AR5416
* AR9285
the MYBEACON RX filter (only receive beacons which match the BSSID)
or all beacons on the current channel.
* Add the relevant RX filter entry for MYBEACON.
Tested:
* AR5416, STA
* AR9285, STA
TODO:
* once the code is in -HEAD, just make sure that the code which uses it
correctly sets BEACON for pre-AR5416 chips.
Obtained from: QCA, Linux ath9k
the QCA HAL.
This fires off an interrupt if the TSF from the AP / IBSS peer is
wildly out of range. I'll add some code to the ath(4) driver soon
which makes use of this.
TODO:
* verify this didn't break TDMA!
to the hardware.
The QCA HAL has a comment noting that if this isn't done, modifications
to AR_IMR_S2 before AR_IMR is flushed may produce spurious interrupts.
Obtained from: QCA
This way the state changes from sleep->awake before the registers are poked
and from awake->sleep after the registers are poked.
This way spurious warnings aren't printed by my (to be committed)
debugging code.
Tested:
* AR5416, STA
private per-chip HAL.
This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.
It should be a no-op for normal driver work but it does require a
clean kernel/module rebuild, as the size of HAL structures have changed.
Now, this doesn't track whether the hardware is ACTUALLY awake,
as NETWORK_SLEEP wakes the chip up for a short period when traffic
is received. This doesn't actually set the power mode to AWAKE, so
we have to be careful about how we touch things.
But it's enough to start down the path of implementing station mode
chipset power savings, as a large part of the silliness is making
sure the chip is awake during periodic calibration / ANI and
random places where transmit may be occuring. I'd rather not a repeat
of debugging power save on ath9k, where races with calibration
and transmit path stuff took a couple years to shake out.
Tested:
* AR5416, STA mode
The AR5212 series of MACs implement the same channel counters as the
later 11n chips - except, of course, the 11n specific counter (extension
channel busy.)
This allows users of these NICs to use 'athsurvey' to see how busy their
current channel is.
Tested:
* AR5212, AR2413 NICs, STA mode
Approved by: re@ (gleb)
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.
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
* 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.
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
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.)
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
The main problem here is that fast and driver RX diversity isn't actually
configured; I need to figure out why that is. That said, this makes
the single-antenna connected AR9285 and AR2427 (AR9285 w/ no 11n) work
correctly.
PR: kern/179269
The QCA9565 is a 1x1 2.4GHz 11n chip with integrated on-chip bluetooth.
The AR9300 HAL already has support for this chip; it just wasn't
included in the probe/attach path.
Tested:
* This commit brought to you over a QCA9565 wifi connection from
FreeBSD.
* .. ie, basic STA, pings, no iperf or antenna diversity checking just yet.
* 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.
is configured for higher rates (lower than max) but higher TX power
is configured for the lower rates, above the configured cap, to improve
long distance behaviour.
* Add the rest of the missing GPIO output mux types;
* Add in a new debug category;
* And a new MCI btcoex configuration option in ath_hal.ah_config
Obtained from: Qualcomm Atheros
