Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

dev/ath: minor spelling fixes in comments.

No functional change.

Reviewed by: adrian

Oops; correctly reload the CCA registers with the uncapped value
in prep for the next NF calibration pass.

Totally missing braces. Damn you C.

Submitted by: Sascha Wildner <swildner@dragonflybsd.org>
MFC after: 1 week

Bump this up to where it used to be.

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.

Reduce the NF wait timeout. When doing heavy 11n RX loads, this can actually
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.

Fix 5ghz calibration logic when using AR9280 w/ fast clock.

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)

I noticed that the Merlin NICs I had (AR9220, AR9280) never completed
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40mhz modes.

Since Sowl (AR9160) seems to return valid-looking calibration data
in 5ghz 20MHz modes, I'm only disabling it for Merlin for now.
It may turn out I can disable it for all chipsets and only enable
it for 40MHz modes.

Approved by: re (kib)

Fix the AR9280 initial AGC calibration code.

It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.

Obtained from: Atheros
Approved by: re (kib)

Make sure only two chains are calibrated for the AR9287.

Fix NF calibration breakage introduced by me in a past commit.

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.

Even though initial calibrations aren't done (yet), add this so we're
consistent with the Atheros HAL.

Only do open loop power control and temperature compensation
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.

Make the NF calibration logic (hopefully!) more resistive to noisy
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

Always log if the NF CCA load fails; so users with debugging enabled
can see they're likely in a very noisy environment.

Remove unused variable

Remove the initial NF completion check.

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.

Remove a now unneeded comment..

Don't perform NF calibration for radio chains which aren't in use:

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

Export the per-chain ctl/ext noise floor values, raw and uncut, to the
upper-level HAL.

Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currently has no real reference
to compare the per-chain RSSI values to.

This is needed before per-chain RSSI values (for ctl and ext radios)
are can be thrown upstairs to the net80211 code.

I broke periodic adc calibrations - so restore them to working order.

Disable a check I added a while ago to ensure the initial NF cal completed.

Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not. Then don't
abort the radio setup; just continue merrily along.

This should fix the issue that users were having where scanning would
occasionally fail on the active channel, causing traffic to cease
until the radio scanned again.

Cave in and disable the ADC DC gain/offset calibrations if they're
not needed.

These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensating for the
differences in DC gain and DC offset -between- the two ADCs.)
Otherwise the chip reads values of 0x0 for the secondary ADC
(as I guess it's not enabled here) and thus writes potentially
bogus info into the chip.

I've tested this on the AR9160 and AR9280; both behave themselves
in 11g mode with these calibrations disabled.

Introduce methods for the initial calibration and the new PA calibration
routines.

These are needed for the AR9285/AR2427 and AR9287 calibration routines
which will be introducecd in a later commit.

Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.

Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.

This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.

Specifics:

* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone

Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.

Obtained from: linux ath9k

Avoid writing CCA threshold values for the EXT radios for non-HT40 channels.

Bring over some NF calibration changes from ath9k.

Each different radio chipset has a different "good" range of CCA
(clear channel access) parameters where, if you write something
out of range, it's possible the radio will go deaf.

Also, since apparently occasionally reading the NF calibration
returns "wrong" values, so enforce those limits on what is being
written into the CCA register.

Write a default value if there's no history available.

This isn't the case right now but it may be later on when "off-channel"
scanning occurs without init'ing or changing the NF history buffer.
(As each channel may have a different noise floor; so scanning or
other off-channel activity shouldn't affect the NF history of
the current channel.)

Add a comment from my local HAL about what is actually going on here
with these ADC DC Gain/Offset calibrations.

The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.

The AR5416 returns lots of garbage, so there's no need to do the
calibration there.

The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.

Fix indenting/whitespace issues introduced by me.

The comment is misleading - that register setting seems to kick off the
initial chip NF cal.

* Fix indentation
* Restore comment erroneously deleted from the previous commit

Loading the NF CCA values may take longer than expected to occur.
If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.

This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.

Obtained from: Linux

Use ar5212IsNFCalInProgress() to check for NF calibration progress.

Fix indentation.

Ensure that the correct rxchainmask is used when doing calibration in the
AR5416 and later chipsets.

ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.

Internal NF calibration should not occur in parallel with any other
calibration. Ensure that the NF calibration completes before continuing
with the rest of the calibration setup process.

Revert part of the 9285 support because it breaks the 9280 support. I'll
try to do the 9285 support without interfering with any other chipset
revisions support.

Fix TX power problems with AR9285.

Add support for the AR9285 chipset, which is found on many netbooks
available today.

This card is a low power 802.11bgn that only does 11n rates up to MCS 7
(that's 65 Mbps in 20Mhz mode and 135 in 40Mhz mode).
802.11n is not yet supported, but will be in the future.

The driver still has a problem regarding to the setting of txpower on
the card, so don't expect good performance yet. After fixing this
problem, an MFC is possible.

Special thanks to iXsystems and S Smirnov <tonve at yandex.ru> for help
with the purchase of a netbook with this card.

Sponsored by: iXsystems, Inc.

fix compilation w/ AH_DEBUG

Overhaul regulatory support:
o remove HAL_CHANNEL; convert the hal to use net80211 channels; this
mostly involves mechanical changes to variable names and channel
attribute macros
o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant
with the net80211 channel available
o change api for ath_hal_init_channels: no more reglass id's, no more outdoor
indication (was a noop), anM contents
o add ath_hal_getchannels to have the hal construct a channel list without
altering runtime state; this is used to retrieve the calibration list for
the device in ath_getradiocaps
o add ath_hal_set_channels to take a channel list and regulatory data from
above and construct internal state to match (maps frequencies for 900MHz
cards, setup for CTL lookups, etc)
o compact the private channel table: we keep one private channel
per frequency instead of one per HAL_CHANNEL; this gives a big
space savings and potentially improves ani and calibration by
sharing state (to be seen; didn't see anything in testing); a new config
option AH_MAXCHAN controls the table size (default to 96 which
was chosen to be ~3x the largest expected size)
o shrink ani state and change to mirror private channel table (one entry per
frequency indexed by ic_devdata)
o move ani state flags to private channel state
o remove country codes; use net80211 definitions instead
o remove GSM regulatory support; it's no longer needed now that we
pass in channel lists from above
o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A
o simplify initial channel list construction based on the EEPROM contents;
we preserve country code support for now but may want to just fallback
to a WWR sku and dispatch the discovered country code up to user space
so the channel list can be constructed using the master regdomain tables
o defer to net80211 for max antenna gain
o eliminate sorting of internal channel table; now that we use ic_devdata
as an index, table lookups are O(1)
o remove internal copy of the country code; the public one is sufficient
o remove AH_SUPPORT_11D conditional compilation; we always support 11d
o remove ath_hal_ispublicsafetysku; not needed any more
o remove ath_hal_isgsmsku; no more GSM stuff
o move Conformance Test Limit (CTL) state from private channel to a lookup
using per-band pointers cached in the private state block
o remove regulatory class id support; was unused and belongs in net80211
o fix channel list construction to set IEEE80211_CHAN_NOADHOC,
IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT
o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are
now set in the constructed net80211 channel
o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one
of the driver-private flag bits of the net80211 channel
o move 900MHz frequency mapping into the hal; the mapped frequency is stored
in the private channel and used throughout the hal (no more mapping in the
driver and/or net80211)
o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the
calculation and available in the net80211 channel
o change noise floor calibration logic to work with compacted private channel
table setup; this may require revisiting as we no longer can distinguish
channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used
only to calculate status data we can live with it for now
o change ah_getChipPowerLimits internal method to operate on a single channel
instead of all channels in the private channel table
o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency
(always the same except for 900MHz channels)
o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory
problems
o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now
o change ath_hal_getwirelessmodes to really return wireless modes supported
by the hardware (was previously applying regulatory constraints)
o return channel interference status with IEEE80211_CHANSTATE_CWINT (should
change to a callback so hal api's can take const pointers)
o remove some #define's no longer needed with the inclusion of
<net80211/_ieee80211.h>

Sponsored by: Carlson Wireless

add FreeBSD property

import ath hal

Replace most compile-time support options with linker sets for
chip and RF backend support:
o add OS_DATA_SET and OS_SET_DECLARE os requirements for setting
up linker sets
o add AH_CHIP macro for registering chip support (e.g. 5210)
o add AH_RF macro for registering RF support (e.g. 2413); note
this isn't required for single chip solutions where there's no
ambiguity (e.g. 5416/9160+2133) but for 5212 class parts it's
required because of the multi-chip solutions
o remove all uses of AH_SUPPORT_AR5210, AH_SUPPORT_AR5211, AH_SUPPORT_5212,
and AH_SUPPORT_AR9160; still need AH_SUPPORT_AR5416 to enable the 11n
descriptor formats and 5312 support is presently broken
o remove all uses of AH_SUPPORT_2133, AH_SUPPORT_2413, AH_SUPPORT_5111,
AH_SUPPORT_5112, AH_SUPPORT_2417, AH_SUPPORT_2425, and AH_SUPPORT_5413;
5312-related support still requires fixup

Remaining issues:
o fixup SoC attach
o ath_hal_attach uses a hack to probe w/o access to the vendorid
o fallback handling of parts w/o a macrev needs to be restored

Update to later code from my repository:
o many bug fixes
o add new periodic calibration api
o break up 5416 periodic calibration code in preparation for 928x
o move get noise floor to rf backends
o 5416-specific ani (still disabled)
o modularize 5210 eeprom format a la other eeprom formats
o start cleaning up regdomain code
o prepare for proper 1/2 and 1/4 width channel support
o bring back 900MHz card support
o clean up 5212 rf version handling
o add 1/2 and 1/4 width channel support for 5212 parts
o split 5212 rfgain handling out
o improve ani debugging
o add AH_USE_INIPDGAIN compile option
o purge a bunch of dead 5212 state
o add 1/2 and 1/4 rate modes
o remove HAL_CAP_CHAN_HALFRATE and HAL_CAP_CHAN_QUARTERRATE; the
same info can now be deduced from the set of supported modes