This should hopefully make it clearer to developers what is going on
and when TPC is being hacked on, make it obvious why it isn't working for
series 1, 2, 3.
I won't flip on setting TX power for TX series 1, 2, 3 until I've done
some further testing with Kite to ensure it doesn't break anything.
(Before people ask - yes, TPC is only needed for 5ghz regdomains and
yes, Kite is a 2.4ghz only chip, but there are potential use cases
for 2ghz TPC. I just need to sit down and ensure it's supported and
functional.)
control the antenna control bits for the four TX series and the
TPC settings for TX series 1, 2, 3.
The specifics:
* The TPC setting for TX series 0 is handled in ctl0.
* TPC is currently disabled, so the per-packet TX power is
set via the global per-rate TX power register, not per packet.
* The antenna control bits don't matter for AR5416 and later
so they should stay 0 (which they currently do); they may
be set for Kite but as there's no TX diversity supported
at the moment (it requires the NIC to be built with an
external antenna switch, matching how antenna diversity
is done on legacy NICs), so again keep them 0.
This is in preparation for supporting per-rate TPC on the
AR5416 and later. The Kite (and soon to come Kiwi) code
sets ctl8-11 to 0x0, which doesn't have any effect at
the moment. When TPC is enabled it would result in the
second, third and fourth TX series attmpts to be done with
a TX power of 0. This commit doesn't change that; it'll
be followed up with some commits to properly set the TPC
registers appropriately.
Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will tidy this mess up and have it return HAL_BOOL instead.
is totally disabled.
The Atheros HAL code does this for Sowl/Howl but not for Owl (AR5416) where
RIFS is disabled by default.
This seems to quieten the occasional baseband hang I've been seeing with
the AR9160 in STA mode under constant heavy traffic load.
Obtained from: Atheros
for the AR9280 based NICs if it's actually enabled.
Some of the OLC code was erroneously called during setup
and calibration. This may have caused some incorrect behaviour.
table which contains the per-rate target TX power.
This code is shared between the v14 eeprom board setup (AR5416, AR9160,
AR9280) and will also be used by the upcoming Kite (AR9287) support.
environments.
In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous one hasn't yet
completed. This shouldn't happen unless the environment is noisy but
those exist (hi phk!).
Here, if the previous NF hasn't completed when ar5416LoadNf() is run
(which reads the NF), it skips updating the history buffer, loading
the NF CCA array and kicking off the next NF cal. It's hoped it'll
occur in the next long calibration interval.
Obtained from: Atheros, ath9k, my local HAL
This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).
Instead, the rest of the calibration related code should
ensure that a NF calibration has occured before reading NF
values and kicking off another NF calibration.
The channel should also likely be marked as "noisy" (CWINT)
if the NF calibration takes too long.
* Modify AR_SREV_MERLIN_20() to match the Atheros/Linux ath9k behaviour -
its supposed to match Merlin 2.0 and later Merlin chips.
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 2.0 and later chips
(AR9285, AR9287, etc.)
This seems to make the AR9160 behave better during heavy scanning,
where before it'd hang and require a hard reset to recover.
Obtained From: Linux ath9k, Atheros
modifying AR_DIAG_SW.
There's a hardware workaround which sets disabling some errors
early at startup and clears said bits before the PCU begins
receiving - it does this to avoid RX descriptor status errors.
It's possible these bits aren't being completely properly twiddled
in all instances; but in particular if the diag_reg HAL variable
is set it won't be setting these bits correctly. I'll review this
at some point.
* Disable multicast search on mac address and key id - the driver
doesn't use it at the moment and thus adhoc may be broken for
merlin and later.
* Change this to be for Merlin 1.0 (which from what I understand
wasn't ever publicly released) to be more correct.
Apparently all three RX chains need to be enabled before initial calibration
is done, even if only two are configured.
Reorder the alt chain swap bit to match what the Atheros HAL is doing.
Obtained From: ath9k, Atheros
* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.
channel when the channel is HT/40.
The new ANI code (primarily for the AR9300/AR9400) in ath9k sets this
register but the ANI code for the previous 11n chips didn't set this.
Unlike ath9k, only set this for HT/40 channels.
Obtained From: ath9k
These describe FCC/Japan channel and DFS behaviour.
The AR9285 and later chips don't set these bits in the eeprom, the correct
behaviour is to just assume all five bits are enabled.
* Add Howl (ar9130) to the list of chips that have DFS/BB/MAC hangs
* Don't treat unknown BB hangs as fatal; ath9k/Atheros HAL don't
treat it as such.
* Add HAL_DEBUG_DFS to the debug fields in ath_hal/ah_debug.h
The BB hang check simply loops over an observation register checking
for a stuck state engine, but it can happen under high traffic
conditions. Ath9k and the Atheros HAL simply log a debug message and
continue.
Private to FreeBSD:
* Add HAL_DEBUG_HANG to the debug fields
* Change the hang debugging to HAL_DEBUG_HANG rather than HAL_DEBUG_DFS
like in the Atheros HAL.
Obtained from: Atheros
For now, these are equivalent macros. AR_SREV_OWL{X}_OR_LATER
will later change to exclude Howl (AR9130) in line with what
the Atheros HAL does.
This should not functionally change anything.
Obtained from: Atheros
A quick story, which is partially documented in the commit.
The silicon revision in Linux ath9k and the Atheros HAL use an
AR_SREV_REVISION mask of 0x07.
FreeBSD's HAL uses the AR5212 AR_SREV_REVISION mask of 0x0F.
Thus the OWL silicon revisions were coming through as 0xA, 0xB,
0xC, rather than 0x0, 0x1 and 0x2.
My ath9k-sourced AR_SREV_OWL_<X> macros were thus using the wrong
silicon revision values and wouldn't correctly match.
This commit does a few things:
* Change the AR_SREV_OWL_<x> macros to use the AR_SREV_REVISION_OWL_*
values, not AR_XSREV_REVISION_OWL macros;
* Disable AR_XSREV_REVISION_OWL_* values;
* Modify the IS_5416 to properly check the MAC is OWL, rather than
potentially matching on non-OWL revisions (which shouldn't happen
unless there's a silicon revision of higher than 0x9 in a later
chip..)
* Add a couple more macros from the Atheros HAL for compatibility.
The main difference now is that the Atheros HAL defines
AR_SREV_OWL_{20,22}_OR_LATER subtly differently - it fails on all HOWL
silicon. The AR_SREV_5416_*_OR_LATER macros match on the relevant OWL
version -and- all HOWL versions, along with subsequent versions.
A subsequent commit is going to migrate the uses of AR_SREV_OWL_X_OR_LATER
to AR_SREV_5416_X_OR_LATER to match what's going on in the Atheros HAL.
There's only two uses of AR_SREV_OWL_X_OR_LATER which currently don't
apply to FreeBSD but it may do in the future.
Yes, it's all confusing!
Quoting the ath9k commit message:
At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.
This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.
Reference: https://patchwork.kernel.org/patch/753862/
Obtained from: Linux ath9k
The checks should function as follows:
* AR_SREV_<silicon> : check macVersion matches that version id
* AR_SREV_<silicon>_<revision> : check macVersion and macRevision match
the version / revision respectively
* AR_SREV_<silicon>_<revision>_OR_LATER: check that
+ if the chip silicon version == macVersion, enforce revision >= macRevision
+ if the chip silicon version > macVersion, allow it.
For example, AR_SREV_MERLIN() only matches AR9280 (any revision),
AR_SREV_MERLIN_10() would only match AR9280 version 1.0, but
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 version >= 2.0 _AND_
any subsequent MAC (So AR9285, AR9287, etc.)
The specific fixes which may impact users:
* if there is Merlin hardware > revision 2.0, it'll now be correctly
matched by AR_SREV_MERLIN_20_OR_LATER() - the older code simply
would match on either Merlin 2.0 or a subsequent MAC (AR9285, AR9287, etc.)
* Kite version 1.1/1.2 should now correctly match. As these macros
are used in the AR9285 reset/attach path, and it's assumed that the
hardware is kite anyway, the behaviour shouldn't change. It'll only
change if these macros are used in other codepaths shared with
older silicon.
Obtained from: Linux ath9k, Atheros
The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.
The specifics:
* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130.
This is needed due to the different location the RTC registers live
with this chip; hopefully this will be undone in the future.
This does currently mean that enabling this option will break non-AR9130
builds, so don't enable it unless you're specifically building an image
for the AR913x SoC.
* Add the new probe, attach, EEPROM and PLL methods specific to Howl.
* Add a work-around to ah_eeprom_v14.c which disables some of the checks
for endian-ness and magic in the EEPROM image if an eepromdata block
is provided. This'll be fixed at a later stage by porting the ath9k
probe code and making sure it doesn't break in other setups (which
my previous attempt at this did.)
* Sprinkle Howl modifications throughput the interrupt path - it doesn't
implement the SYNC interrupt registers, so ignore those.
* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods
were
* Sprinkle some other Howl workarounds in the reset path.
* Hard-code an alternative setup for the AR_CFG register for Howl, that
sets up things suitable for Big-Endian MIPS (which is the only platform
this chip is glued to.)
This has been tested on the AR913x based TP-Link WR-1043nd mode, in
legacy, HT/20 and HT/40 modes.
Caveats:
* 2ghz has only been tested. I've not seen any 5ghz radios glued to this
chipset so I can't test it.
* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least,
it isn't implemented in ath9k. Please don't enable this.
* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
spurious (and fatal) interrupt errors.
One user reported seeing this:
Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
ISR_RAC 0x0 SYNC_CAUSE 0x2000
SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.
After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.
The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.
This patch does the following:
* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
and it isn't fatal, the hardware isn't reset via returning
HAL_INT_FATAL.
This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.
It's also marked inactive by the initvals, and enabled after
the baseband/PLL has been configured, but before the RF
registers have been programmed.
The origin and reason for this particular change is currently unknown.
Obtained from: Linux ath9k
