I need to investigate this a little closer, but it seems that in noisy
environments the NF load takes longer than 5 * DELAY(10) and this is
messing up future NF calibrations. (The background: NF calibrations
begin at the value programmed in after the load has completed, so
if this is never loaded in, the NF calibrations only ever start at
the currently calibrated NF value, rather than starting at something
high (say -50.)
More investigation about the effect on 11n RX and calibration results
are needed.
Sponsored by: Hobnob, Inc.
The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has
issues with PCI transactions on SMP machines. This work-around enforces
that register access is serialised through a (global for now) spinlock.
This should stop the hangs people have seen with the AR5416 PCI devices
on SMP hosts.
Obtained by: Linux, Atheros
to fetch the current channel busy statistics, rather than duplicating
it here.
This forms the (very crude) basis for doing basic channel surveying.
Sponsored by: Hobnob, Inc.
enabled if required by STA operation.
This quietens a lot of OFDM errors seen in hostap mode, where
there are no beacon RSSI levels to tune the dynamic range of the
baseband.
This may reduce reception range at the fringes, but does increase
stability.
Sponsored by: Hobnob, Inc.
The 5ghz hostap mode (where DFS is being done) requires ANI to be disabled
or the radar detection parameters don't work as advertised (as they're based
on signal strength level, and tweaking ANI affects the signal strangth,
dynamic range and power increase the baseband is looking for in order to
detect it as a "signal".)
Obtained from: Linux, Atheros
Sponsored by: Hobnob, Inc.
* If we fall through from an ANI command (eg because it's out of range,
or it's disabled) then fall through to the next ANI command rather then
being stuck there.
* Fix some off-by-one comparisons, meaning the final level in some parameters
were never tweaked.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
This forces a full reset of the baseband/radio and seems needed to clear
some issues (with Merlin at least) when the baseband gets confused in a
very noisy environment.
Sponsored by: Hobnob, Inc.
RX clear, RX extension clear.
This is useful for estimating channel business.
The same routines should be written for AR5210->AR5212 where appopriate.
Obtained from: Atheros
some unmerged interrupt status debugging code from my branch.
* Add ah_intrstate[8] which will have the record of the last
call to ath_hal_getintr().
* Wrap the KTR code behind ATH_KTR_INTR_DEBUG.
* Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING.
This is only done for the AR5416 and later NICs but it will be
trivial to add to the earlier NICs if required.
Neither are enabled by default, although to minimise HAL binary
API differences, the ah_intrstate[] array is always compiled into
the ath_hal struct.
* preserve AR_TxIntrReq on every descriptor in an aggregate chain,
not just the first descriptor;
* always blank out the descriptor in ar5416ChainTxDesc() when forming
aggregates - the way I'm using this in the 11n branch is to first
chain aggregates together, then use the other HAL calls to fill in
the details.
* Add the TID field in the TX status descriptor;
* Add in the 11n first/middle/last functions for fiddling
with the descriptors. These are from the Linux and the
reference driver, but I'm not (currently) using them.
* Add further AR_ISR_S5 register definitions.
Obtained from: Linux ath9k, Atheros
interfere with traffic, as the NF load can take quite a while and poking the
AGC every 10uS is just a bit silly.
Instead, just leave the baseband NF calibration where it is and just read it
back next time a longcal interval happens.
The final missing bit here is enabling the PCI configuration register
read, but there's currently no glue available for the HAL to read (and
write) PCI configuration space registers.
Obtained from: Atheros
The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI, which adjust operational parameters based on the
BB radio register reads. This was introduced in the AR5008 chip
and fixed with the first released AR9002 series NIC (AR9280v2.)
A followup commit will implement the acutal WAR when reading
BB registers. I'm still not sure how I'll implement it - whether
it should be done in the osdep layer, or whether it should just
live in the AR5416 HAL. Either way, they can use this capability
bit to determine whether to implement the WAR or not.
Thankyou to various sources inside Atheros who have helped me track
down what this particular issue is.
Obtained from: Atheros
Pre-11n devices and AR5416 use AR_PHY(263) for current RX RSSI.
AR9130 and later have a fourth calibration register (for doing
ADC calibration) and thus the register has moved to AR_PHY(271).
This isn't currently used by any of the active code; I'm committing
this for completeness and in case any third party code attempts to
use it for legacy reasons.
* The AR_ISR_RAC interrupt processing method has a subtle bug in all
the MAC revisions (including pre-11n NICs) until AR9300v2.
If you're unlucky, the clear phase clears an update to one of the
secondary registers, which includes TX status.
This shows up as a "watchdog timeout" if you're doing very low levels
of TX traffic. If you're doing a lot of non-11n TX traffic, you'll
end up receiving a TX interrupt from some later traffic anyway.
But when TX'ing 11n aggregation session traffic (which -HEAD isn't yet
doing), you may find that you're only able to TX one frame (due to
BAW restrictions) and this may end up hitting this race condition.
The only solution is to not use RAC and instead use AR_ISR and the
AR_ISR_Sx registers. The bit in AR_ISR which represents the secondary
registers are not cleared; only the AR_ISR_Sx bits are. This way
any updates which occur between the read and subsequent write will
stay asserted and (correctly) trigger a subsequent interrupt.
I've tested this on the AR5416, AR9160, AR9280. I will soon test
the AR9285 and AR9287.
* The AR_ISR TX and RX bits (and all others!) are set regardless of
whether the contents of the AR_IMR register. So if RX mitigation is
enabled, RXOK is going to be set in AR_ISR and it would normally set
HAL_INT_RX.
Fix the code to not set HAL_INT_RX when RXOK is set and RX mitigation
is compiled in. That way the RX path isn't prematurely called.
I would see:
* An interrupt would come in (eg a beacon, or TX completion) where
RXOK was set but RXINTM/RXMINT wasn't;
* ath_rx_proc() be called - completing RX frames;
* RXINTM/RXMINT would then fire;
* ath_rx_proc() would then be called again but find no frames in the
queue.
This fixes the RX mitigation behaviour to not overly call ath_rx_proc().
* Start to flesh out more correct timer interrupt handling - it isn't
kite/merlin specific. It's actually based on whether autosleep support
is enabled or not.
This is sourced from my 11n TX branch and has been tested for a few weeks.
Finally, the interrupt handling change should likely be implemented
for AR5210, AR5211 and AR5212.
There are some timing concerns which I've yet to fully map out.
In any case, there's an existing software driven mitigation method
for TX interrupts and when TX'ing 11n frames, the whole frame itself
generates an interrupt rather then the subframes.
Although I tried to fix this earlier by introducing HALDEBUG_G(), it
turns out there seem to be other cases where the pointer value is still
NULL.
* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL
before deferencing it
* Remove HALDEBUG_G() as it's no longer needed
This is hopefully a merge candidate for 9.0-RELEASE as enabling
debugging at startup could result in a kernel panic.
rather than the whole beacon interval.
The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in the driver rather than
the HAL (Ath reference) or ath9k_hw (ath9k.)
This quietens stuck beacon conditions on my AR9220/AR9280
based NICs when a lot of burst broadcast/multicast traffic
is going on. It doesn't seem to annoy the earlier MACs as
much as the AR9280 and later one.
Obtained from: Linux ath9k, Atheros
local variable with a beacon interval of 100 TU. This never gets modified
if the beacon interval configuration changes.
This may have been correct in earlier times, but with the advent of
staggered beacons (which default to 1 / ATH_BCBUF beacon interval, so
25 TU here) this value is incorrect.
It is used to configure the default CABQ readytime. So here, the cabq
was being configured to be much greater than the target beacon timer
(TBTT.)
The driver should be configuring a cabq readytime value rather then
leaving it to the HAL to choose sensible defaults. This should be
done in the future - I'm simply trying to ensure sensible defaults
are chosen.
This is another commit in a series of TDMA support fixes for the 11n NICs.
* Move ath_hal_getnexttbtt() into the HAL; write methods for it.
This returns a timer value in TSF, rather than TU.
* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they
likely now belong.
* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF.
The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor;
the AR5416 and later write 32 bit TSF snapshots into the RX descriptor.
* Use the new capability to choose between 15 and 31 bit TSF adjustment
functions in ath_extend_tsf().
* Write ar5416GetTsf64() and ar5416SetTsf64() methods.
ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.
According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA
stations can now associate/talk, but there are still issues with traffic
stability which need to be investigated.
The ath_hal_extendtsf() function is also used in RX packet timestamping;
this may improve adhoc mode on the 11n chipsets. It also will affect the
timestamps seen in radiotap frames.
Submitted by: Kang Yin Su <cantona@cantona.net>
Approved by: re (kib)
reference driver does clear the async interrupts after each service.
I'll tinker with this in a future commit.
Obtained from: Atheros
Approved by: re (kib)
When the fast clock (44mhz) is enabled for 5ghz HT20, the
dual ADCs aren't enabled. Trying to do the ADC calibrations
here would result in calibration never completing; this
resulted in IQ calibration never running and thus performance
issues in 11a/11n HT20 mode.
Leave it enabled for non-fastclock (40mhz) 11a mode and
HT40 modes.
This has been fixed in discussion with Felix Fietkau (nbd)
and discussions with the Atheros baseband team.
Linux ath9k now has a similar fix.
Approved by: re (kib)
* Fix SLEEP1/SLEEP2 register definitions; the CAB/Beacon timeout
fields have changed in AR5416 and later
* The TIM_PERIOD and DTIM_PERIOD registers are now microsecond fields,
not TU.
Obtained from: Linux ath9k, Atheros reference
Approved by: re (kib, blanket)
or later. Previous hardware had some as TU, some as 1/8th
TU.
* Modify AR_NEXT_DBA and AR_NEXT_SWBA to use a new macro,
ONE_EIGHTH_TU_TO_USEC(), which converts the 1/8th TU
fields to USEC. This is just cosmetic and matches the
Atheros reference driver.
* Fix AR_NEXT_TBTT, which is USEC, not TU.
Submitted by: paradyse@gmail.com
Approved by: re (kib, blanket)
Remove this debugging, it's not needed anymore and when not enabled,
those variables trigger a compiler warning.
Approved by: re (kib, blanket)
Pointy-hat-to: adrian, for not testing a non-debug compile of this code enough
allows it to be overridden at runtime.
Thus, add a function which updates ah_dfsDomain after a channel set
call to ath_hal_set_channels().
Approved by: re (kib, blanket)
and the Atheros reference code.
The radar detection code needs to know what the current DFS domain is.
Since net80211 doesn't currently know this information, it's extracted
from the HAL regulatory domain information.
The specifics:
* add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which
updates the radar filters whenever the regulatory domain changes.
* add HAL_DFS_DOMAIN which describes the currently configured DFS domain .
* add a new HAL internal variable which tracks the currently configured
HAL DFS domain.
* add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently
configured HAL DFS domain setting.
* update the HAL DFS domain setting whenever the channel setting is
updated.
Since this isn't currently used by any radar code, these should all
be no-ops for existing users.
Obtained from: Atheros
Submitted by: KBC Networks, sibridge
Approved by: re (kib, blanket)
if 5ghz fast clock is enabled in the current operating mode.
It's slightly dirty, but it's part of the reference HAL and used by
the (currently closed-source) radar event code to map radar pulses
back to microsecond durations.
Obtained from: Atheros
Approved by: re (kib, blanket)
the ar9130 code.
Since at least one kernel config specifies individual ath HAL chips
rather than just "device ath_hal" (arm/AVILA), I'm doing this so people
aren't caught out when they update to -HEAD or 9.0 and discover their
ath setup doesn't compile.
I'll revisit this with a proper fix sometime before 9.0-RELEASE.
Approved by: re (kib, blanket)
Pointed out by: ray@
Pointy hat to: adrian@
