It turns out that this is useful on hornet and wasp SoCs but it isn't
enabled in ye olde HAL /unless/ you were using a version from one of the
business units building USB targetted devices. It eventually got fixed
for all of them as people started wanting to use the USB ports on their
SoCs (eg for flash storage, bluetooth, 4G/LTE widgets, etc.)
This is actually a fix from ath9k but I'm merging it with the available-but-
disabled code in the QCA reference HAL.
Tested:
* AR9331 SoC
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
* flesh out a "get default DFS parameters" routine
* remove the stub that returns NULL
* fix up the enable DFS method to do what FreeBSD does - specifically, allow pe_enabled
to be set/cleared.
This allows the radar pulse reporting code to function, but it doesn't yet
do anything useful.
* add debugging
* disable the manual noise floor calibration and tracking done by the HAL;
this interferes with the normal calibration path and will lock up the RX
side
* don't program short report / priority if they're provided as NOVAL.
* add support to read the timer and capability
* add support to enable/disable the location timer.
On AR9380 at least, enabling the location timer is required to make
the timer tick, otherwise location packets return a timestamp of 0.
However, it then makes /all/ RX packets use the RX location timestamp
instead of the TSF timestamp.
So, unless I find another magical way to do location timestamping,
we will have to dynamically switch things on/off and ensure the
TX/RX path handles the "different" timestamps correctly.
Tested:
* AR9380, STA mode
* LOC_INFO is mostly just "did this packet come with a locationing
timestamp instead of TSF";
* Decode not-sounding, uploaded-data, data-valid, data type and
number of extension spatial streams.
* If fast_ts is set then the TX timestamp is the fast timestamp, not
normal TSF.
* If the TX descriptor has the position bit set then request locationing
and clear sounding-disable. This way we (a) get the response with
the TX timestamp from the location side of things, and (b) we get
a CSI dump of the response ACK, which we will eventually use in the
locationing path.
* 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.
Among other things, this introduces the idea of DBA-gated queues that
aren't the CABQ. The TDMA support requires this.
Tested:
* AR9580 (hostap mode)
* AR9380 (sta mode)
Approved by: re (gjb)
This is in preparation for some other TDMA fixes which will hopefully
end with having working TDMA.
But, it does avoid lots of read/modify/writes in the txq setup path.
* Allow readyTime to just be programmed in directly
* The beacon interval and all of the beacon timing sysctl's are in TU,
not TSF. So, we were doing the wrong math on the CAB programming
in the first place.
This seems to make 5G work better.
It doesn't fix powersave handling though, that still sees the PHY get
stuck during initial calibration and everything goes pear shaped.
I'll look into that later.
Tested:
* QCAFN222 NIC, STA mode, 5GHz
Obtained from: Linux ath9k
Turns out I wasn't even initialising or programming a lot of stuff
for the AR9462 2.1 chip. Oops.
This mostly gets it working. powersave scan results in some pretty
hilarious NFcal hangs and I don't see beacons reliably.
There are still some xlna gain tables missing that ath9k has; I'll
follow up with some fixes and then see if the QCAFN222 NIC I have
tests this path.
Tested:
* QCAFN222 NIC, STA mode, 2GHz and 5GHz
These are apparently conditional on there being a shared PA/LNA, which
at least on AR9462/QCA9535 devices I have isn't a thing.
I'm .. not yet sure which devices it /is/ a thing, so I'll come back
to that.
Tested:
* QCA9565 STA + bluetooth
Obtained from: Linux ath9k
* Add extra debugging - the weights debugging is really useful to ensure
things are programmed into the wlan coexistence table. The weights are
what traffic priority each of the various modes get (tx, tx-high-priority,
rx-beacon, etc) if they're all zero, things work very poorly.
* Add in coex init routines from ath9k for AR9462 and QCA9565 1ANT and 2ANT.
This control things like beacon stomping, ACK handling, antennas, PA/LNA
shared, etc.
* Some ancillary bits.
TODO:
* There's some conditional stuff around MCI_ANT_ARCH_PA_LNA_SHARED() in ath9k
which doesn't always enable force-on LNA. That'll have to be examined
and merged in as appropriate.
Obtained from: linux ath9k
Notably, this also sets AR_BTCOEX_WL_LNADIV to FORCE_ON, so LNA diversity
is always enabled and under control of the wifi chip.
Tested:
* QCA9565, STA + bluetooth mode
Obtained from: Linux ath9k
This configures the LNA antenna diversity control, which should be on
if wlan owns the LNA for bluetooth coexistence. Otherwise, make sure
it's off.
I think this is eventually intended to allow 1-antenna bluetooth +
wifi setups for QCA9565, but I'm not sure where that's actually configured
in ath9k.
Obtained from: Linux ath9k
It turns out that the srev checks can't be done in the early attach
in ar9300_freebsd.c, because the poweron and srev check hasn't yet
happened.
So:
* Re-add the MCI overrides in attach
* Add QCA9565 (Aphrodite) check for the LNA diversity stuff.
Tested:
* QCA9565, STA mode + bluetooth
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 is a 2x2 2GHz 802.11n part. It works enough at the moment to
bring up, scan and associate. I haven't started using this as
a day to day AP.
The specifics:
* add honeybee initvals
* add in changes; a mix from the QCA HAL and ath9k;
* fix a bug in AR_SREV_AR9580_10_OR_LATER(), which is only used
for one capability check and we don't even implement it - so it's
a big no-op.
Shady things:
* ath9k has the "platform data" define the 25/40MHz clock.
This HAL .. doesn't. Honeybee gets hard-coded to 25MHz which
it likely shouldn't be. I'll have to go and identify/fix those.
Tested:
* Qualcomm Atheros AP143 reference design board.
Obtained from: Qualcomm Atheros; Linux ath9k
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)
This is required for (more) correct TDMA support. Without it, the
code tries to calculate the required guard interval based on the
current rate, and since this is an 11n NIC and people try using
11n, it calls ath_hal_computetxtime() on an 11n rate which then
panics.
This doesn't fix TDMA slave mode on AR9300 - it just makes it
have one less bug.
Reported by: Berislav Purgar <bpurgar@gmail.com>
