* Add an OS_A_REG_WRITE() routine - analog writes require a 100usec delay
on AR9280 and later, so create a method to do it.
* Use it for the AR9287 analog writes.
* Re-indent and style(9) the code.
This just requires a little HAL change (add a new config parameter) and
some glue in if_ath_pci.c, however I'm leaving this up for someone else
to do.
Obtained from: Qualcomm Atheros
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
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.
* 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).
* 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.
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.
attached this way.
The AR5212 based NICs have a variety of RF frontends, so there's a linker set
which the AR5212 attach routine calls. The same framework is used for the
AR5416 and later but as there's a fixed RF frontend for each 11n NIC, it
is just directly attached.
However in the case of compiling a cut down HAL (eg _just_ AR9130 WMAC support),
the linker set ends up being empty and this causes the compile to fail.
So this is just a workaround for that - it means those users who wish an 11n
only HAL can compile the 11n chipsets and RF frontend they need, and just
"ath_ar5212" for the AR5212/AR5416 common code, and it'll just work.
Sponsored by: Hobnob, Inc.
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.
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@
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)
This seems to indicate whether to program the NIC for fractional 5ghz
mode (ie, 5mhz spaced channels, rather than 10 or 20mhz spacing) or not.
The default (0) seems to mean "only program fractional mode if needed".
A different value (eg 1) seems to always enable fractional 5ghz mode
regardless of the frequency.
Obtained from: Atheros
Approved by: re (kib)
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)
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.
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
This has been disabled until now because there hasn't been any supported
device which has this feature. Since the AR9287 is the first device to
support it, and since now the HAL has functional AR9287+11n support,
flip this on.
AR9287 EEPROM layout.
The AR9287 only supports 2ghz, so I've removed the 5ghz code (but left
the 5ghz edge flags in there for now) and hard-coded the 2ghz-only
path.
Whilst I'm there, fix a typo (ar9285->ar9287.)
This meets basic TX throughput testing - iperf TX tests == 27-28mbit in 11g,
matching the rest of my 11g kit.
I'm assuming for now that the AR9287 is only open-loop TX power control
(as mine is) so I've hard-coded the attach path to fail if the NIC is
not open-loop.
This greatly simplifies the TX calibration path and the amount of code
which needs to be ported over.
This still isn't complete - the rate calculation code still needs to be
ported and it all needs to be glued together.
Obtained from: Linux ath9k
It isn't linked into the build because it's missing the TX power
and PDADC programming code.
This code is mostly based on the ath9k codebase, compared against
the Atheros codebase as appropriate.
What's implemented:
* probe/attach
* EEPROM board value programming
* RX initial calibration
* radio channel programming
* general MAC / baseband setup
* async fifo setup
* open-loop tx power calibration
What's missing before it can be enabled by default:
* TX power / calibration setting code
* closed-loop tx power calibration routines
* TSF2 handling
* generic timer support from ath9k
Obtained from: Atheros, ath9k
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.
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.
* grab the main, alt and selected LNA config
* add some optional / disabled logging code
* add a check to reject packets with an invalid main rssi too,
in case the alt is the active receive chain and main is -ve.
Note: The software-controlled combined diversity code is still disabled.
* Correct some of the silicon revision checks to match what
the Atheros HAL does. (See [1] below.)
* Move the PA cal and init cal method assignment to -after-
the mac version/revision IDs are stored. The AR9285 init
cal was never being called.
* Enable ANI.
Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen
in the wild. Linux ath9k simply removed the prototype code from
their codebase. I'm going to leave it in there for now but
make it conditionally compilable in the future.
Obtained from: Atheros
from Atheros as to what/when this is supposed to be enabled.
Using the default RX fast diversity settings seems to help quite
a bit.
Whilst I'm here, change the prototype to return HAL_BOOL rather than int.
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
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.
* 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.
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.
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
