Commit Graph

305 Commits

Author SHA1 Message Date
Adrian Chadd
46dde1e6fa Add a new flag - HAL_DEBUG_UNMASKABLE - which always logs a debug message
(when debug is enabled) no matter what.
2011-05-11 13:22:41 +00:00
Adrian Chadd
5645b9a093 Remove unused variable 2011-05-11 13:20:25 +00:00
Adrian Chadd
85191ae6e8 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.
2011-05-11 11:02:20 +00:00
Adrian Chadd
37fb34b48b Remove a now unneeded comment.. 2011-05-11 10:30:31 +00:00
Adrian Chadd
c454afe290 Restore the RSSI threshold after writing the board values.
This would be overwritten by the board initvals written in ah->writeIni().
2011-05-11 09:47:48 +00:00
Adrian Chadd
12c5d1f2bf AR9285 (Kite) fixes.
* 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
2011-05-10 04:32:27 +00:00
Adrian Chadd
352dbd822c Disable diversity combining support until I can get a firm answer
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.
2011-05-09 17:30:25 +00:00
Adrian Chadd
48d813ef34 Fix a regression I introduced - only swap analog chains if the RX chainmask
is 0x5.
2011-05-09 17:10:48 +00:00
Adrian Chadd
e8def8942a Disable TX STBC - it isn't used for now, but it isn't supported on Kite. 2011-05-09 16:49:40 +00:00
Adrian Chadd
60abf57fd5 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
2011-05-09 15:19:49 +00:00
Adrian Chadd
b4d225808d Remove an un-needed PA cal call here. 2011-05-09 14:04:49 +00:00
Adrian Chadd
c9cd76313b 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.
2011-05-08 15:55:52 +00:00
Adrian Chadd
aa66982300 * Add AR_SREV_KITE macro for later use
* 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.)
2011-05-08 15:25:22 +00:00
Adrian Chadd
f678fb43eb These EEPROM bits actually defined whether HT/20 and HT/40 support
for the given channel is available.

It isn't used yet; ar5416GetWirelessModes() needs to be taught
about this rather than assuming HT20/HT40 is available.
2011-05-08 08:18:30 +00:00
Adrian Chadd
5c892e7497 Fiddle with the PLL initialisation order to match ath9k/Atheros HAL.
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
2011-05-08 07:21:09 +00:00
Adrian Chadd
351384c64f Properly indent the WAR code i pasted in from ath9k a few months
ago.
2011-05-08 05:45:06 +00:00
Adrian Chadd
60d3878423 * Add in a comment about ar5416InitUserSettings() potentially
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.
2011-05-08 05:25:42 +00:00
Adrian Chadd
5accb5fd53 Fiddle with the AR5416 1.0 chainmask setup.
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
2011-05-08 03:24:17 +00:00
Adrian Chadd
af8223ba6d Fix the IS_5416 checks to actually work correctly.
I've verified that my AR5416 revision 2.2 (minor revision 0x0A) now
matches the correct checks.
2011-05-07 18:42:41 +00:00
Adrian Chadd
26e8415d1d 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.
2011-05-07 15:30:23 +00:00
Adrian Chadd
b657b11d8d Update the ext channel cycpwr threshold 1 register for the extension
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
2011-05-07 13:08:48 +00:00
Adrian Chadd
f93ef5516b 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.
2011-05-07 11:05:16 +00:00
Adrian Chadd
001ac28926 Instead of returning an unknown mac/bb signature, just return 0. 2011-05-07 06:52:04 +00:00
Adrian Chadd
b810285f24 Add some comments about which HAL capabilities are currently FreeBSD
specific.

The Atheros HAL and FreeBSD HAL share the same capabilities up
until HAL_CAP_11D, where things begin to diverge.

I'll look at tidying these up soon.

Obtained from:	Atheros
2011-05-07 06:47:09 +00:00
Adrian Chadd
de1334e8d7 Some BB hang changes:
* 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
2011-05-07 06:45:35 +00:00
Adrian Chadd
ef1901a3c9 Change AR_SREV_OWL_{X}_OR_LATER to AR_SREV_5416_{X}_OR_LATER.
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
2011-05-07 02:59:24 +00:00
Adrian Chadd
d1915e7308 Fix the OWL revision checks.
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!
2011-05-07 02:54:52 +00:00
Adrian Chadd
e7cb5d548d Add a function which enables or disables RX RIFS searching, and migrate
the code which does this into it.
2011-05-06 15:33:56 +00:00
Adrian Chadd
47ff47a858 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
2011-05-05 08:11:22 +00:00
Adrian Chadd
ed8659ed69 Another Howl (AR9130) fix.
I haven't seen a 5ghz AR9130 based board yet though!

Obtained from:	Atheros
2011-05-05 04:43:05 +00:00
Adrian Chadd
d2615832bf Fix up the chipset checks for the AR5416 and later silicon.
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
2011-05-05 03:42:04 +00:00
Adrian Chadd
59298273a9 Import some HOWL (AR9130) related fixes from Atheros.
Obtained from:	Atheros
2011-05-05 02:59:31 +00:00
Adrian Chadd
5a04ce2fdf Remove this useless bit of code for Kite. The RIFS register value is overriden
by the initvals, so disabling RIFS before calling writeIni() effectively does
nothing.
2011-05-04 09:26:33 +00:00
Adrian Chadd
1422779793 Remove some holdovers from the AR5212 origin of this code.
These aren't relevant here.
2011-04-29 12:52:18 +00:00
Adrian Chadd
9f25ad52ce Introduce AR9130 (HOWL) WMAC support to the FreeBSD HAL.
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.
2011-04-28 12:47:40 +00:00
Adrian Chadd
041df70857 Wrap the MIMO stuff in #ifdef AH_SUPPORT_AR5416, as the channel
state doesn't have MIMO stuff in it by default.
2011-04-25 15:51:49 +00:00
Adrian Chadd
c2442d279a Break out the PLL setup into an overridable method.
The only method right now is ar5416InitPLL() which handles multiple
chipsets; this can now be overridden by newer chipset HAL code.
2011-04-24 15:53:57 +00:00
Adrian Chadd
98ebd982c3 Use the refactored ar5416WriteTxPowerRateRegisters() call in the ar9285 code. 2011-04-24 15:48:07 +00:00
Adrian Chadd
b998ae6409 Eliminate code duplication between AR5416/AR9160/AR9280 and AR9285.
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.
2011-04-24 14:50:29 +00:00
Adrian Chadd
6f5fe81e02 Fix a corner-case of interrupt handling which resulted in potentially
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.
2011-04-23 06:37:09 +00:00
Adrian Chadd
0d07bcba27 Fix the merlin LNA configuration code - these are bit flags, not raw values to be
written into the registers.
2011-04-22 17:57:13 +00:00
Adrian Chadd
635636ea69 The second regdomain word is a set of bitflags describing
regulatory domain behaviour. Document what the v14 EEPROM
flags are.
2011-04-22 10:59:20 +00:00
Adrian Chadd
0d2dd30cbd Bring over a pdadc calibration fix from ath9k - unused power detector
gain values should be 58, not the previous values.

Obtained From:	linux ath9k
2011-04-22 10:57:46 +00:00
Adrian Chadd
d0a0ebc6c3 Rework the Global TX timeout handling to look more like ath9k.
It correctly now sets the AR_IMR BCNMISC register, along with
the GTT register in AR_IMR_S2.
2011-04-18 14:03:05 +00:00
Adrian Chadd
6ad02dbafe Add global TX timeout handling.
The global TX timeout counter increments whenever a frame is ready
to be transmitted and the medium is busy.
2011-04-18 12:15:43 +00:00
Adrian Chadd
d10f1cdc8c Mark the PHY as inactive before the chip is reset.
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
2011-04-17 13:46:13 +00:00
Adrian Chadd
b39c47d922 Don't do Kite antenna switch selection this way (for now); antenna
diversity is done elsewhere now.
2011-04-16 13:47:17 +00:00
Adrian Chadd
52d84465a2 Disable classic-style fast diversity on the AR5416 and later.
Antenna diversity on the >= AR5416 is implemented differently than the
AR5212 and previous chips. So for now, and not to confuse things, just
disable it for now.
2011-04-16 12:46:46 +00:00
Adrian Chadd
18a3a3309f Remove some duplicate code from the AR9285 TX power configuration path. 2011-04-16 11:59:37 +00:00
Adrian Chadd
81484cdb07 Add in the last bit of the HAL support for Kite diversity.
* add a new method, specifically for doing per-RX packet
  antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
  does diversity.
2011-04-13 15:12:48 +00:00