Copy stable/10@r272459 to releng/10.1 as part of
the 10.1-RELEASE process.

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

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

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

Bring over the basic spectral scan framework code from Qualcomm Atheros.

This includes the HAL routines to setup, enable/activate/disable spectral
scan and configure the relevant registers.

This still requires driver interaction to enable spectral scan reporting.
Specifically:

* call ah_spectralConfigure() to configure and enable spectral scan;
* .. there's currently no way to disable spectral scan... that will have
to follow.
* call ah_spectralStart() to force start a spectral report;
* call ah_spectralStop() to force stop an active spectral report.

The spectral scan results appear as PHY errors (type 0x5 on the AR9280,
same as radar) but with the spectral scan bit set (0x10 in the last byte
of the frame) identifying it as a spectral report rather than a radar
FFT report.

Caveats:

* It's likely quite difficult to run spectral _and_ radar at the same
time. Enabling spectral scan disables the radar thresholds but
leaves radar enabled. Thus, the driver (for now) needs to ensure
that only one or the other is enabled.

* .. it needs testing on HT40 mode.

Tested:

* AR9280 in STA mode, HT/20 only

TODO:

* Test on AR9285, AR9287;
* Test in both HT20 and HT40 modes;
* .. all the driver glue.

Obtained from: Qualcomm Atheros

HAL updates!

* Add some more ANI spur immunity levels.
* For AR5111 radios attached to an AR5212, limit the 5GHz channels
that are available. A later revision of the AR5111 supports the 4.9GHz
PSB channels but right now there's no check in place for the radio
revision.

If someone wants PSB support on AR5212+AR5111 radios then please let
me know and I'll add the relevant version check.

Obtained from: Qualcomm Atheros

Don't use AR_PHY_MODE to setup half/quarter rate.

I'm not sure where in the deep, distant past I found the AR_PHY_MODE
registers for half/quarter rate mode, but unfortunately that doesn't
seem to work "right" for non-AR9280 chips.

Specifically:

* don't touch AR_PHY_MODE
* set the PLL bits when configuring half/quarter rate

I've verified this on the AR9280 (5ghz fast clock) and the AR5416.

The AR9280 works in both half/quarter rate; the AR5416 unfortunately
only currently works at half rate. It fails to calibrate on quarter rate.

Add the AR9280 workarounds for PCIe suspend/resume.

These aren't strictly needed at the moment as we're not doing APSM
and forcing the NIC in and out of network sleep. But, they don't hurt.

Tested:

* AR9280 (mini-PCIe)

Obtained from: Qualcomm Atheros, Linux ath9k

oops - ath_hal_disablepcie is actually destined for another purpose,
not to disable the PCIe PHY in prepration for reset.

Extend the enablepci method to have a "poweroff" flag, which if equal
to true means the hardware is about to go to sleep.

Prepare for improved (read: pcie) suspend/resume support.

* Flesh out the pcie disable method for 11n chips, as they were defaulting
to the AR5212 (empty) PCIe disable method.

* Add accessor macros for the HAL PCIe enable/disable calls.

* Call disable on ath_suspend()

* Call enable on ath_resume()

NOTE:

* This has nothing to do with the NIC sleep/run state - the NIC still
will stay in network-run state rather than supporting network-sleep
state. This is preparation work for supporting correct suspend/resume
WARs for the 11n PCIe NICs.

TODO:

* It may be feasible at this point to keep the chip powered down during
initial probe/attach and only power it up upon the first configure/reset
pass. This however would require correct (for values of "correct")
tracking of the NIC power configuration state from the driver and that
just isn't attempted at the moment.

Tested:

* AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).

.. oops.

"Upgrade" the AR9285 code to support PCI/ART EEPROM on flash.

I've just verified that this boots on an Atheros AP91. I haven't verified
it with traffic though, so YMMV.

Support AR9281/AR5B91 - a 1x2 stream device based on the AR9280.

* Override the TX/RX stream count if the EEPROM reports a single RX or
TX stream, rather than assuming the device will always be a 2x2 strea
device.

* For AR9280 devices, don't hard-code 2x2 stream. Instead, allow the
ar5416FillCapabilityInfo() routine to correctly determine things.

The latter should be done for all 11n chips now that
ar5416FillCapabilityInfo() will set the TX/RX stream count based on the
active TX/RX chainmask in the EEPROM.

Thanks to Maciej Milewski for donating some AR9281 NICs to me for
testing.

Break out the "memory" EEPROM data read method from being AR9130 specific
to being more generic.

Other embedded SoCs also throw the configuration/PCI register
info into flash.

For now I'm just hard-coding the AR9280 option (for on-board AR9220's on
AP94 and commercial designs (eg D-Link DIR-825.))

TODO:

* Figure out how to support it for all 11n SoC NICs by doing it in
ar5416InitState();
* Don't hard-code the EEPROM size - add another field which is set
by the relevant chip initialisation code.
* 'owl_eep_start_loc' may need to be overridden in some cases to 0x0.
I need to do some further digging.

Add in some more PCI/PCIe differentiation.

Fix a corner case in the HAL debugging changes, where ah was NULL.

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.

Undo this for now. It's "right", but it means everything will rely on
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@

Add in a dirty hack that allows for AR9280/AR9285/AR9287 embedded
systems, in the same way that AR9130 embedded systems work.

This isn't -everything- that is required - the PCI glue still
needs to be taught about the eepromdata hint, along the same
lines as the AHB glue.

Approved by: re (kib, blanket)

Fix the initial calibration sample count when doing ADC calibrations.

Obtained from: Atheros
Approved by: re (kib)

Break out the PLL setup into (mostly) per-chip methods, rather than
polluting the AR5416 code with later chipset support.

Note: ar9280InitPLL() supports Merlin (AR9280) and later (AR9285, AR9287.)

Submitted by: ssgriffonuser@gmail.com
Approved by: re (kib)

Re-introduce a global ath_hal_debug again for now, whilst I figure out what
to do about the few cases where the HAL state isn't available (regdomain)
or isn't yet setup (probe/attach.)

The global ath_hal_debug now affects all instances of the HAL.

This also restores the ability for probe/attach debugging to work; as
the sysctl tree may not be attached at that point. Users can just set
the global "hw.ath.hal.debug" to a suitable value to enable probe/attach
related debugging.

Add some missing DFS chipset functionality to the FreeBSD HAL.

Please note - this doesn't in any way constitute a full DFS
implementation, it merely adds the relevant capability bits and
radar detection threshold register access.

The particulars:

* Add new capability bits outlining what the DFS capabilities
are of the various chipsets.
* Add HAL methods to set and get the radar related register values.
* Add AR5212 and AR5416+ DFS radar related register value
routines.
* Add a missing HAL phy error code that's related to radar event
processing.
* Add HAL_PHYERR_PARAM, a data type that encapsulates the radar
register values.

The AR5212 routines are just for completeness. The AR5416 routines
are a super-set of those; I may later on do a drive-by pass to
tidy up duplicate code.

Obtained from: Linux, Atheros

Tidy up the ANI API in preparation for looking to expose some more
of the ANI statistics and committing some tools which use these.

* Change HAL_ANI_* commands _back_ to be numerical, rather than a
bitmap;
* modify access to the ANI control bitmap to convert a command to
a bitmap;
* Fix the ANI noise immunity fiddling for CCK errors - it wasn't
checking whether noise immunity was disabled or not.

The Merlin analog register bank is from 0x7800 -> 0x78fc; fix the code
to reflect this.

Fixes from the Atheros HAL - formatting; update Merlin checks to be consistent.
Nothing functional should change with this commit.

Fix the 5ghz fast clock logic.

The macro which I incorrectly copied into ah_internal.h assumed
that it'd be called with an AR_SREV_MERLIN_20() check to ensure
it was only enabled for Merlin (AR9280) silicon revision 2.0 or
later.

Trouble is, the 5GHz fast clock EEPROM flag is only valid for
EEPROM revision 16 or greater; it's assumed to be enabled
by default for Merlin rev >= 2.0. This meant it'd be incorrectly
set for AR5416 and AR9160 in 5GHz mode.

This would have affected non-default clock timings such as SIFS,
ACK and slot time. The incorrect slot time was very likely wrong
for 5ghz mode.

Do a HAL capabilities sync pass based on the Atheros HAL.

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

Read in the extended regulatory domain flags so future code can use them.

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.

Commit missing bits from the last commit:

* add the hal capability flag
* make sure its disabled for the ar9280/ar9285.

Introduce hardware PS-POLL support in the HAL.

Linux ath9k only enables this for AR9280 and later NICs; so
create a capability for it so it isn't enabled for earlier
NICs.

Enabling hardware PS-POLL support will come in a later commit
and will be disabled by default.

Flip ANI on for the AR5416 and later chips. I haven't verified it on
the AR9285 so I'll leave it off for that.

Ath9k sources indiciate that one of the ANI modes interferes with
RIFS detection, so match ath9k and disable that.

Even though it's very unlikely the misc mode register setting at -attach-
would be a problem, make sure it isn't overwritten by whatever is in
there at cold reset.

This brings the > ar5416 init path treatment of AR_MISC_MODE.

Now that the power curve adjustment code is in, disable the error check
I introduced earlier, and turn it into debugging output.

Introduce the Merlin PWDCLKIND workaround.

This is something bus clock related from what I can gather. It is needed for
the AR9220 based Ubiquiti SR71-12 and SR71-15 Mini-PCI NICs.

(Note: those NICs don't work right now because of earlier changes to handle
power table offset correctly. That'll be resolved in a follow-up 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

Add in ANI parameters for the AR9280. These aren't enabled by default
as they're likely not entirely correct, but they give people something
to toy with to compare behaviour/performance.

Disable the anti-noise part, as this apparently interferes with
RIFS. I haven't verified this.

Disable flipping antennas for AR9280.

Flipping antennas when doing 11n would cause all kinds of strange issues.
Just don't do it for now and when it comes time to do it, don't do it here.

There's apparently a bug with Merlin (AR9280) and later chipsets where
putting descriptors (not buffers) across a 4k page boundary can cause issues.
I've not seen it in production myself but it apparently can cause problems.

So, in preparation for addressing this workaround, (re)-expose the particular
HAL capability bit which marks whether the chipset has support for cross-4k-
boundary transactions or not.

A subsequent commit will modify the descriptor allocation to avoid allocating
descriptor entries that straddle a 4k page boundary.

Call the correct ANI Attach routine.

Add a new capability which reports the number of spatial streams a device supports.

The higher levels (net80211, if_ath, ath_rate) need this to make correct
choices about what MCS capabilities to advertise and what MCS rates are
able to be TXed.

In summary:

* AR5416 - 2/3 antennas, 2x2 streams
* AR9160 - 2/3 antennas, 2x2 streams
* AR9220 - 2 antennas, 2x2 sstraems
* AR9280 - 2 antennas, 2x2 streams
* AR9285 - 2 antennas but with antenna diversity, 1x1 stream

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

ANI changes #1 - split out the ANI polling from the RxMonitor hook.

The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.

Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.

ar9280SetAntennaSwitch() was using the AR5416 chainmasks (3 chains)
rather than the AR9280 chainmasks (2 chains)

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.

Include the initial support for external EEPROMs.

The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.

I believe earlier parts can do something similar but I haven't
experienced it first-hand.

This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.

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

MFC after: 1 month

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.

preliminary ar9280 support:
o add 9280 attach that sets up ini, cal, etc.
o new rf backend for 9280 and later parts
o split ini setup and spur mitigation support out to methods
and provide 9280-specific support
o minor fixups to shared code to handle 9280-specific work

Obtained from: Atheros (ini values and some code)