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

Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.

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

Migrate the AR9285 diversity configuration LNA configuration to use
some HAL definitions rather than local definitions.

The original source (ath9k) pulled this stuff from the QCA driver and
removed the HAL_* prefix. I'm just restoring the correct order of things.

Obtained from: Qualcomm Atheros

Bring over the initial 802.11n bluetooth coexistence support code.

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

Import some initial Kite fixed diversity code from Atheros.

For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.

Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.

Things to todo:

* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.

* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.

For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..

Obtained from: Atheros

Bring over the antenna diversity logic support for Kite.

Again, this is just the code ported from ath9k and included in the build,
it isn't yet enabled.

Port over the AR9285 PA calibration and initial calibration code from
Linux ath9k.

The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.

Obtained from: Linux ath9k

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.)

Push the non-AR5416 related stuff into chipset specific directories.

sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.

Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.

Bring back AR9285 support. This fixes most of the issues and should be
pretty usable.

MFC after: 1 month