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
This doesn't specifically fix the issue(s) i'm seeing in this 2GHz
environment (where setting/increasing spur immunity causes OFDM restart
errors to skyrocket through the roof; but leaving it at 0 would leave
the environment cleaner..)
Pointy-hat-to: me, for committing this broken code in the first place.
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.
No, this isn't HT/5 and HT/10 support. This is the 11a half/quarter
rate support primarily used by the 4.9GHz and GSM band regulatory
domains.
This is definitely a work in progress.
TODO:
* everything in the last commit;
* lots more interoperability testing with the AR5212 half/quarter rate
support for the relevant chips;
* Do some interop testing on half/quarter rate support between _all_
the 11n chips - AR5416, AR9160, AR9280 (and AR9285/AR9287 when 2GHz
half/quarter rate support is coded up.)
used when running the chips in half/quarter rate.
This sets up some default parameters which are then overridden by the
driver (which manually configures things like slot timing at interface
start time.)
Although this is a copy-and-modify from the AR5212 HAL, I did peek
at the reference HAL and the ath9k driver to see what they did.
Ath9k in particular doesn't hard-code this - instead, their version
of ar5416InitUserSettings() does all of the relevant math.
TODO:
* do the math, not hard code things!
* fix the mac clock calculation for the AR9287; since it runs the
MAC clock at a higher rate, requiring all the duration calculations
to change;
* Do a whole lot more validation for half/quarter rates.
Obtained from: Qualcomm Atheros, Linux ath9k
Some of the math is a little wrong thanks to clocks in 11a mode running
at 44MHz when in fast clock mode (rather than 40MHz, which the chips
before AR9280 ran 11a in). That'll have to be addressed in a future commit.
The comparison assumes maxFirstepLevel is a count, rather than a maximum
value. The array is 3 entries in size however 'maxFirstepLevel' is 2.
This bug also exists in the AR5212 HAL.
array, similar to what filltxdesc() uses.
This removes the last reference to ds_data in the TX path outside of
debugging statements. These need to be adjusted/fixed.
Tested:
* AR9280 STA/AP with iperf TCP traffic
The existing API only exposes 'seglen' (the current buffer (segment) length)
with the data buffer pointer set in 'ds_data'. This is fine for the legacy
DMA engine but it won't work for the EDMA engines.
The EDMA engine has a significantly different TX descriptor layout.
* The legacy DMA engine had a ds_data pointer at the same offset in the
descriptor for both TX and RX buffers;
* The EDMA engine has no ds_data for RX - the data is DMAed after the
descriptor;
* The EDMA engine has support for 4 TX buffer/segment pairs in the TX
DMA descriptor;
* The EDMA TX completion is in a different FIFO, and the driver will
'link' the status completion entry to a QCU by a "QCU ID".
I don't know why it's just not filled in by the hardware, alas.
So given that, here are the changes:
* Instead of directly fondling 'ds_data' in ath_desc, change the
ath_hal_filltxdesc() to take an array of buffer pointers as well
as segment len pointers;
* The EDMA TX completion status wants a descriptor and queue id.
This (for now) uses bf_state.bfs_txq and will extract the hardware QCU
ID from that.
* .. and this is ugly and wasteful; it should change to just store
the QCU in the bf_state and save 3/7 bytes in the process.
Now, the weird crap:
* The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than
taking a function argument. I've tidied that up.
* The multicast queue frames get put on a software TXQ and then that is
appended to the hardware CABQ when appropriate. So for now, make sure
that bf_state->bfs_txq points at the CABQ when adding frames to the
multicast queue.
* .. but the multicast queue TX path for now doesn't use the software
queue and instead
(a) directly sets up the descriptor contents at that point;
(b) the frames on the vap->avp_mcastq are then just appended wholesale
to the CABQ.
So for now, I don't have to worry about making the multicast path
work with aggregation or the per-TID software queue. Phew.
What's left to do:
* I need to modify the 11n ath_hal_chaintxdesc() API to do the same.
I'll do that in a subsequent commit.
* Remove bf_state.bfs_txq entirely and store the QCU as appropriate.
* .. then do the runtime "is this going on the right HWQ?" checks using
that, rather than comparing pointer values.
Tested on:
* AR9280 STA/AP
* AR5416 STA/AP
The existing method for testing for MRR is to call the "SetupXTXDesc"
HAL method and see if it returns AH_TRUE or AH_FALSE. This capability
explicitly lists what number of multi-rate attempts are possible.
"1" means "one rate attempt supported".
Specifically, however:
* AR9280 and later support 1-stream STBC RX;
* AR9280 and AR9287 support 1-stream STBC TX.
The STBC support isn't announced (yet) via net80211 and it isn't at all
chosen by the rate control code, so there's no real consumer of this
yet.
Obtained from: Qualcomm Atheros
with AMPDU aggregate delimiters.
If there's an OFDM restart during an aggregate, the hardware ACKs
the previous frame, but communicates the RXed frame to the hardware
as having had CRC delimiter error + OFDM_RESTART phy error.
The frame however didn't have a CRC error and since the hardware ACKed
the aggregate to the sender, it thinks the frame was received.
Since I have no idea how often this occurs in the real world, add a
debug statement so trigger whenever this occurs. I'd appreciate an
email if someone finds this particular situation is triggered.
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
and the CRC error bits set. The radar payload is correct.
When this happens, the stack doesn't see them PHY error frames and
isn't interpreted as a PHY error. So, no radar detection and no radiotap
PHY error handling.
Now, this may introduce some weird issues if the MAC sends up some other
combination of CRC error + PHY error frames; this commit would break that
and mark them as PHY errors instead of CRC errors.
I may tinker with this a little more to pass radar/early radar/spectral
frames up as PHY errors if the CRC bit is set, to restore the previous
behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC
error rather than PHY error.)
Tested on: AR5416, over the air, to a USRP N200 which is generating a
large number of a variety of radar pulses.
TODO: Test on AR9130, AR9160, AR9280 (and maybe radar pulses on
2GHz on AR9285/AR9287.)
PR: kern/169362
* Now that ah_configPCIE is called for both power on and suspend/resume,
make sure the right bit(s) are cleared and set when suspending and
resuming. Specifically:
+ force disable/enable the PCIe PHY upon suspend/resume;
+ reprogram the PCIe WAR register when resuming and upon power-on.
* Add a recipe which powers down any PCIe PHY hardware inside the AR5416
(which is the PCI variant) to save on power. I have (currently) no way
to test exactly how much power is saved, if any.
Tested on:
* AR5416 cardbus - although unfortunately pccard/cbb/cardbus currently
detaches the NIC upon suspend, I don't think it's a proper test case.
* AR5418 PCIe attached to expresscard - since we're not doing PCIe APSM,
it's also not likely a full/good test case.
In both instances I went through a handful of suspend/resume cycles and
ensured that the STA vap reassociated correctly.
TODO:
* Setup a laptop to simply sit in a suspend/resume loop, making sure that
the NIC always correctly comes back;
* Start doing suspend/resume tests with actual traffic going on in the
background, as I bet this process is all quite racy at the present;
* Test adhoc/hostap mode, just to be completely sure it's working correctly;
* See if I can jury rig an external power source to an AR5416 to test out
whether ah_disablePCIE() works.
Obtained from: Qualcomm Atheros
* Add some other WAR bits (very usefully described too) in preparation for
porting over some suspend/resume fixes from ath9k/Atheros.
Obtained from: Qualcomm Atheros
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.
* 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).
in the HAL. That's very memory hungry (32k just for channel statistics)
which would be better served by keeping a summary in the ANI state.
Or, later, keep a survey history in net80211.
So:
* Migrate the ah_chansurvey array to be a single entry, for the current
channel.
* Change the ioctl interface and ANI code to just reference that.
* Clear the ah_chansurvey array during channel reset, both in the AR5212
and AR5416 reset path.
* Always call ar5416GetListenTime()
* Modify ar5416GetListenTime() to:
+ don't update the ANI state if there isn't any ANI state;
+ don't update the channel survey state if there's no active
channel - just to be paranoid
+ copy the channel survey results into the current sample slot
based on the current channel; then increment the sample counter
and sample history counter.
* Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE,
rather than a set of percentages. The ANI code wasn't using the
percentages anyway.
TODO:
* Create a new function which fetches the survey results periodically
* .. then modify the ANI code to use the pre-fetched values rather than
fetching them again
* Roll the 11n ext busy function from ar5416_misc.c to update all the
counters, then do the result calculation
* .. then, modify the MIB counter routine to correctly fetch a snapshot -
freeze the counters, fetch the values, then reset the counters.
The reference driver has a 3ms delay for the AR9130 but I'm not as yet
sure why. From what I can gather, it's likely waiting for some FIFO
flush to occur.
At some point in the future it may be worthwhile adding a WMAC
FIFO flush here, but that'd require some side-call through to the SoC
DDR flush routines.
Obtained from: Atheros
which will be needed for AR7010 and AR9287 USB access.
The names differ slightly from Linux and Atheros, for the sake of
consistency.
A lot more work is required in order to convert the 11n HAL support to
fully support USB.
at least until I can root cause what's going on.
The only platform I've seen this on is the AR9220 when attached to
the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent
accesses cause further MIPS bus exceptions. I don't have any other
big-endian platforms to test this on.
If I get a chance (or two), I'll try to whack this on a bus analyser
and see exactly what happens.
I'd rather leave this on, especially for slower, embedded platforms.
But the #ifdef hell is something I'm trying to avoid.
Linux ath9k doesn't have this issue as it doesn't try queuing multi-
descriptor frames to the hardware.
Before, I was only setting the first and last descriptor in the final
frame correctly - and that was done by accident. The first descriptor in
the last sub-frame was being correctly updated by ath_tx_setds_11n();
the last descriptor in the last sub-frame was being correctly updated
by ath_buf_set_rate(). But both of those are "incorrect".
The correct behaviour is:
* AR_IsAggr is set for all descriptors for all subframes in an aggregate.
* AR_MoreAggr is set for all descriptors for all non-final sub-frames
in an aggregate.
Ie, all descriptors in the last sub-frame of an aggregate must have this
field set to 0.
I still need to do a couple of extra passes to ensure the pad delimiter
field is being correctly handled in all descriptors in the last sub-frame.
by capabilities.
Add an ar5416SetCapability() function, which contains logic to override
the chainmask and update the relevant stream.
This is designed to be called after the attach function, which presets
the TX/RX chainmask and stream.
TODO: check the chainmask against the hardware chainmask so non-existing
chains aren't enabled.
* 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.
relying on what the register defaults are.
This forces the blink mode to be proportional to the TX and RX frames
which match the RX filter.
This (along with a few tweaks to if_ath_led.c to configure the correct
GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful
fashion, however those LEDs are marked "Link" and "Act(ivity)", which
don't really map well to the "power" / "network" LED interface which
the MAC provides. Some further tinkering is needed to see what other
useful operating modes are possible.
state from correctly updating things.
The reference driver directly enables/disables the LED state as required,
rather than nailing it up like it currently is. That'll have to come
later by adding some further HAL methods.
Obtained from: Atheros
