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
to stuck beacons.
* Set the cabq readytime (ie, how long to burst for) to 50% of the total
beacon interval time
* fix the cabq adjustment calculation based on how the beacon offset is
calculated (the SWBA/DBA time offset.)
This is all still a bit magic voodoo but it does seem to have further
quietened issues with missed/stuck beacons under my local testing.
In any case, it better matches what the reference HAL implements.
Obtained from: Qualcomm Atheros
The HAL already included the STBC fields; it just needed to be exposed
to the driver and net80211 stack.
This should allow single-stream STBC TX and RX to be negotiated; however
the driver and rate control code currently don't do anything with it.
* Remove ar5416UpdateChainmasks();
* Remove the TX chainmask override code from the ar5416 TX descriptor
setup routines;
* Write a driver method to calculate the current chainmask based on the
operating mode and update the driver state;
* Call the HAL chainmask method before calling ath_hal_reset();
* Use the currently configured chainmask in the TX descriptors rather than
the hardware TX chainmasks.
Tested:
* AR5416, STA/AP mode - legacy and 11n modes
Right now the only way to set the chainmask is to set the hardware
configured chainmask through capabilities. This is fine for forcing
the chainmask to be something other than what the hardware is capable
of (eg to reduce TX/RX to one connected antenna) but it does change what
the HAL hardware chainmask configuration is.
For operational mode changes, it (may?) make sense to separately control
the TX/RX chainmask.
Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks()
calculates which TX/RX chainmasks to enable based on the operating mode.
(1 for legacy and whatever is supported for 11n operation.) But doing
this in the HAL is suboptimal - the driver needs to know the currently
configured chainmask in order to correctly enable things for each
TX descriptor. This is currently done by overriding the chainmask
config in the ar5416 TX routines but this has to disappear - the AR9300
HAL support requires the driver to dynamically set the TX chainmask based
on the TX power and TX rate in order to meet mini-PCIe slot power
requirements.
So:
* Introduce a new HAL method to set the operational chainmask variables;
* Introduce null methods for the previous generation chipsets;
* Add new driver state to record the current chainmask separate from
the hardware configured chainmask.
Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving
it into the driver; as well as properly programming the TX chainmask
based on the currently configured HAL chainmask.
Tested:
* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified
that AR_SELFGEN_MASK (the chainmask used for self-generated frames like
ACKs and RTSes) is correct, as well as the TX descriptor contents is
correct.
an incorrectly calculated RTS duration value when transmitting aggregates.
These earlier 802.11n NICs incorrectly used the ACK duration time when
calculating what to put in the RTS of an aggregate frame. Instead it
should have used the block-ack time. The result is that other stations
may not reserve enough time and start transmitting _over_ the top of
the in-progress blockack field. Tsk.
This workaround is to popuate the burst duration field with the delta
between the ACK duration the hardware is using and the required duration
for the block-ack. The result is that the RTS field should now contain
the correct duration for the subsequent block-ack.
This doesn't apply for AR9280 and later NICs.
Obtained from: Qualcomm Atheros
Specifically - never jack the TX FIFO threshold up to the absolute
maximum; always leave enough space for two DMA transactions to
appear.
This is a paranoia from the Linux ath9k driver. It can't hurt.
Obtained from: Linux ath9k
This has reduced the number of TX delimiter and data underruns when
doing large UDP transfers (>100mbit).
This stops any HAL_INT_TXURN interrupts from occuring, which is a good
sign!
Obtained from: Qualcomm Atheros
