The HT40 channel population logic was "just" doing pairs of channels starting with
the band entry frequency. Trouble is, a lot of the rules start way off at 5120MHz,
which isn't a valid 5GHz channel. Then, eg for HT40U, it would populate:
* (5120,5140)
* (5160,5180)
* (5200,5220)
* (5240,5260)
.. as the HT40U pairs, with the first being the primary channel. Channel 36
is 5180MHz, and since it's not a primary channel here, it wouldn't populate it.
Then, the next HT40U would be 5200/5220, which is highly wrong.
HT40D had the same problem.
So, this just forces that 5GHz HT40 channels start at channel 36 (5180),
no matter what the band edge says. This includes eg doing 4.9GHz channels.
This erm, meant that the HT40 channels for the low band was always wrong.
Oops!
Tested:
* AR9380, STA mode
* AR9344 SoC, AP mode
MFC after: 1 week
* change the HT_RC_2_MCS to do MCS0..23
* Use it when looking up the ht20/ht40 array for bits-per-symbol
* add a clk_to_psec (picoseconds) routine, so we can get sub-microsecond
accuracy for the math
* .. and make that + clk_to_usec public, so higher layer code that is
returning clocks (eg the ANI diag routines, some upcoming locationing
experiments) can be converted to microseconds.
Whilst here, add a comment in ar5416 so i or someone else can revisit the
latency values.
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone.
Detected with devel/coccinelle following a hint from DragonFlyBSD.
MFC after: 1 month
The pre-11n calculations include SIFS, but the 11n ones don't.
The reason is that (mostly) the 11n hardware is doing the SIFS calculation
for us but the pre-11n hardware isn't. This means that we're over-shooting
the times in the duration field for non-11n frames on 11n hardware, which
is OK, if not a little inefficient.
Now, this is all fine for what the hardware needs for doing duration math
for ACK, RTS/CTS, frame length, etc, but it isn't useful for doing PHY
duration calculations. Ie, given a frame to TX and its timestamp, what
would the end of the actual transmission time be; and similar for an
RX timestamp and figuring out its original length.
So, this adds a new field to the duration routines which requests
SIFS or no SIFS to be included. All the callers currently will call
it requesting SIFS, so this /should/ be a glorious no-op. I'm however
planning some future work around airtime fairness and positioning which
requires these routines to have SIFS be optional.
Notably though, the 11n version doesn't do any SIFS addition at the moment.
I'll go and tweak and verify all of the packet durations before I go and
flip that part on.
Tested:
* AR9330, STA mode
* AR9330, AP mode
* AR9380, STA mode
* the code already stored the length of the RX desc, which I never used.
So, use that and retire the new flag I introduced a while ago.
* Introduce a TX timestamp length field and capability.
* extend the TX timestamp to 32 bits, as the AR5416 and later does a full
32 bit TX timestamp instead of 15 or 16 bits.
* add RX descriptor fields for PHY uploaded information (coming soon)
* add flags for RX/TX fast timestamp, hardware upload, etc
* add a flag for TX to request ToD/ToA location information.
The legacy bits are just from ah.h; the MCI bits are from the ar9300
HAL "freebsd" extras.
A subsequent commit will include ah_btcoex.h into ah.h and remove
the older defintions.
Split getchannels() method in ath_hal/ah_regdomain.c into a subset
of functions for better readability.
Note: due to different internal structure, it cannot use
ieee80211_add_channel*() (however, some parts are done in a
similar manner).
Differential Revision: https://reviews.freebsd.org/D6139
The synth programming here requires the real centre frequency,
which for HT20 channels is the normal channel, but HT40 is
/not/ the primary channel. Everything else was using 'freq',
which is the correct centre frequency, but the hornet config
was using 'ichan' to do the lookup which was also the primary
channel.
So, modify the HAL call that does the mapping to take a frequency
in MHz and return the channel number.
Tested:
* Carambola 2, AR9331, tested both HT/20 and HT/40 operation.
This probe/attaches correctly in my local branch and now displays
a useful message:
ath0: <Qualcomm Atheros QCA953x> at mem 0x18100000-0x1811ffff irq 0 on nexus0
...
ath0: AR9530 mac 1280.0 RF5110 phy 0.0
Right now the only way to force a cold reset is:
* The HAL itself detects it's needed, or
* The sysctl, setting all resets to be cold.
Trouble is, cold resets take quite a bit longer than warm resets.
However, there are situations where a cold reset would be nice.
Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,
etc.
The vendor HAL has a separate method to set the reset reason (which is
how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path
why it occured. This is almost but not quite the same; I may eventually
unify both approaches in the future.
This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC)
and type (eg do COLD.) None of the HAL code uses it yet though; that'll
come later.
It also is a big no-op in each HAL - I need to go teach each of the HALs
about cold/warm reset through this path.
This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.
Now that net80211 doesn't panic, let's flip this back on.
It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next. It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)
Tested:
* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)
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
