Commit Graph

181 Commits

Author SHA1 Message Date
Adrian Chadd
beb4faf377 For chips that are full reset in ar5416ChipReset(), save and restore the TSF.
Merlin (ar9280) and later were full-reset if they're doing open-loop TX
power control but the TSF wasn't being saved/restored.

Add ar5212SetTsf64() which sets the 64 bit TSF appropriately.
2011-03-09 04:39:35 +00:00
Adrian Chadd
2836e2ae73 Break out the ath regulatory domain structures into a separate header file. 2011-03-08 07:42:09 +00:00
Adrian Chadd
48c1d36479 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
2011-03-08 06:59:59 +00:00
Adrian Chadd
8823714276 Add an EEPROM op that extracts out the power table offset.
It defaults to -5 dBm for eeproms earlier than v21.

This apparently only applies to Merlin (AR9280) or later,
earlier 11n chipsets have a power table offset of 0.
All the code in ath9k which checks the power table offset
and takes it into account first ensures the chip is
Merlin or later.
2011-03-06 00:30:43 +00:00
Adrian Chadd
f247e82033 Change HALDEBUG() to be a macro that conditionally calls the debug output routine.
The earlier way of doing debugging would evaluate the function parameters
before calling the HALDEBUG. In the case of detailed register debugging
would mean a -lot- of unneeded register IO and other stuff was going on.

This method evaluates the ath_hal_debug variable before the function
parameters are evaluated, drastically reducing the amount of overhead
enabling HAL debugging during compilation.
2011-03-05 21:20:18 +00:00
Adrian Chadd
9d6de76d8e Port over ar5416OverrideIni() from ath9k ar5008_hw_override_ini().
* change the BB gating logic to explicitly define which chips are covered;
  the ath9k method isn't as clear.
* don't disable the BB gating for now, the ar5416 initvals have it, and the
  ar9160 initval sets it to 0x0. Figure out why before re-enabling this.
* migrate the Merlin (ar9280) applicable WAR from the Kite (ar9285) code
  (which won't get called for Merlin!) and stuff it in here.
2011-03-03 08:38:31 +00:00
Adrian Chadd
ddbac71b7a * fix the ar5416 check macros to be slightly more correct;
* add some stubs for chipsets that we haven't yet obtained support for.
2011-03-03 08:30:28 +00:00
Adrian Chadd
4a02016d6e Add a vocal warning to ath_hal_computetxtime() function is used for non-11n rates.
It's used to calculate:

* the initial per-rate entries for short/long preamble ACK durations;
* packet durations for TDMA slot decisions;
* RTS/CTS protection durations;
* updating the duration field in the 802.11 frame header

This way invalid durations will generate a warning, prompting for it to be
fixed.
2011-02-21 18:58:58 +00:00
Adrian Chadd
ade7b47061 Modify the AR5416 11na rate table to use 24mb OFDM 11a for control traffic,
rather than MCS 0.

Using MCS0 for protecting 11a rates seems a bit silly.
2011-02-21 05:10:34 +00:00
Adrian Chadd
b7f1862c26 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.
2011-02-17 05:56:03 +00:00
Adrian Chadd
744996fcf1 Add a new parameter to selectively enable/disable the ANI operations.
This was inspired by ath9k, which disables ANI anti-noise immunity
parameter tweaking (but leaves the rest of the ANI operations alone.)
2011-02-17 05:52:53 +00:00
Adrian Chadd
4f343ec80f Call the right function. 2011-02-17 05:30:38 +00:00
Adrian Chadd
69efac96c3 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.
2011-02-15 13:29:52 +00:00
Adrian Chadd
b986265911 bring this in line with what ath9k does. 2011-02-14 21:35:11 +00:00
Adrian Chadd
191470d361 Expose the 4k transaction workaround hooks to the driver, but don't (yet)
fix the descriptor allocation.
2011-02-09 16:37:29 +00:00
Adrian Chadd
be97670785 Fix the keycache behaviour for multicast keycache search.
The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)

The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.

This fixes some encryption problems in station mode.

PR: kern/154598
2011-02-09 15:23:16 +00:00
Adrian Chadd
bd7ea37bac I missed this commit - enable 4k transaction support for the ar5416+ar9160. 2011-02-08 14:15:46 +00:00
Adrian Chadd
e0e5b8b471 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.
2011-02-08 12:49:01 +00:00
Adrian Chadd
8f6997190b Add in some AR9280 specific board configuration options.
* The existing radio config code was for the AR5416/AR9160 and missed out
  on some of the AR9280 specific stuff. Include said stuff from ath9k.

* Refactor out the gain control settings into a new function, again pilfered
  from ath9k.

* Use the analog register RMW macro when touching analog registers.

Obtained from:	Linux ath9k
2011-02-07 22:00:31 +00:00
Adrian Chadd
1a506b1a27 Bring over some AR9280-specific v14 additions that exist in ath9k.
Obtained from:	Linux ath9k
2011-02-07 21:48:26 +00:00
Adrian Chadd
806099d3d5 Use analog delay macro for modifying an analog register. 2011-02-07 21:30:56 +00:00
Adrian Chadd
d9a80efdc2 Add a new RMW macro for analog register writes which implements the needed
wait period between operations.
2011-02-07 21:30:13 +00:00
Adrian Chadd
3118fac370 Fix typo in SIFS setup 2011-02-07 17:04:31 +00:00
Adrian Chadd
c7ff3cee42 Add a temporary workaround so the 11n rate scenario setup code sets a useful
TX chainmask.

since the upper layers don't (yet) know about the active TX/RX chainmasks,
it can't tell the rate scenario functions what to use. I'll eventually sort
this out; this restores functionality in the meantime.
2011-02-05 22:54:37 +00:00
Adrian Chadd
70d2183a7d Call the correct ANI Attach routine. 2011-02-02 03:55:34 +00:00
Adrian Chadd
be96a6d39b Just to be sure, make sure the MCS rates are allowed for TX.
Approved by:	rpaulo@
2011-02-01 15:26:30 +00:00
Adrian Chadd
94d748d2a9 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
2011-02-01 03:51:35 +00:00
Adrian Chadd
d39a3a978b Don't incorrectly set the burst duration setting in the TX descriptor.
After inspecting the ath9k source, it seems the AR5416 and later MACs
don't take an explicit RTS/CTS duration. A per-scenario (ie, what multi-
rate retry became) rts/cts control flag and packet duration is provided;
the hardware then apparently fills in whatever details are required.
The per-rate sp/lpack duration calculation just isn't used anywhere
in the ath9k TX packet length calculations.

The burst duration register controls something different; it seems to
be involved with RTS/CTS protection of 11n aggregate frames and is set
via a call to ar5416Set11nBurstDuration().

I've done some light testing with rts/cts protected frames and nothing
seems to break; but this may break said RTS/CTS and CTS-to-self protection.
2011-01-31 15:42:42 +00:00
Adrian Chadd
1e918679c6 Avoid writing CCA threshold values for the EXT radios for non-HT40 channels. 2011-01-29 14:36:31 +00:00
Adrian Chadd
c6c9d8c8ed 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.)
2011-01-29 14:27:20 +00:00
Adrian Chadd
7c913dea08 Fix some errors introduced w/ the last commit; fix setting RTS/CTS in the 11n rate scenario.
* I messed up a couple of things in if_athvar.h; so fix that.
* Undo some guesswork done in ar5416Set11nRateScenario() and introduce a
  flags parameter which lets the caller set a few things. To begin with,
  this includes whether to do RTS or CTS protection.
* If both RTS and CTS is set, only do RTS. Both RTS and CTS shouldn't be
  set on a frame.
2011-01-29 12:30:13 +00:00
Adrian Chadd
94b61069cc Link in the 11n specific TX methods into the HAL. 2011-01-29 12:16:26 +00:00
Adrian Chadd
7efd41107b Add a check for the AR9285E; I have no idea what this is.
The only other changes in ath9k for the AR9285E revolve around sleep modes
which are not fully implemented here yet.
2011-01-29 08:52:06 +00:00
Adrian Chadd
064e40d0ab Make space for the extended 802.11n MCS rate tables. 2011-01-28 08:45:19 +00:00
Adrian Chadd
d054f3a866 Bring in some 802.11n packet duration calculation functions from a mix of Sam/Rui and linux ath9k .
This will eventually be used by rate control modules and by the TX
code for calculating packet duration when handling rts/cts protection.

Obtained from:	sam@, rpaulo@, linux ath9k
2011-01-28 08:35:55 +00:00
Adrian Chadd
0fafe07ff3 Initialise the chainmask from the EEPROM rather than the hard-coded defaults.
The defaults enabled three chains on the AR5416 even if the card has two
chains. This restores that and ensures that only the correct TX/RX
chainmasks are used.

When HT modes are enabled, all TX chains will be correctly enabled.

This should now enable analog chain swapping with 2-chain cards.
I'm not sure if this is needed for just the AR5416 or whether
it also applies to AR9160, AR9280 and AR9287 (later on); I'll have
to get clarification.
2011-01-27 09:26:37 +00:00
Adrian Chadd
4ceb85596b Add missing getCapability call for AR5416. 2011-01-27 08:42:50 +00:00
Adrian Chadd
51fcc8350c Make a note to re-check whether that particular check is needed. 2011-01-27 07:33:17 +00:00
Adrian Chadd
6ef699a0a6 Writing to the analog registers on the AR9220 (Merlin PCI) seems to require a delay.
This, along with an initval change which will appear in a subsequent commit,
fixes bus panics that I have been seing with the AR9220 on a Routerstation Pro
(AR7161 MIPS board.)

Obtained from: Linux ath9k
PR: kern/154220
2011-01-27 02:56:03 +00:00
Adrian Chadd
f68a9f06e1 Add ar5416RestoreChainMask() which will undo any AR5416 specific chainmask
overriding after calibration.

This will get set for other two chain radios, such as AR9280 and later on,
AR9287. It should however be a nul operation.
2011-01-26 10:48:29 +00:00
Adrian Chadd
b868c6d0b1 Add an AR5416 workaround - force a different bias based on 2.4ghz channel frequency.
Obtained from:	Linux ath9k
2011-01-26 10:36:43 +00:00
Adrian Chadd
60a507a514 Break out the chainmask init code into a new function - ar5416InitChainMasks() .
ath9k does a few different things here during config - if it's an early
AR5416 with two chains, it enables all three chains for calibration and
then restores the chainmask to the original values after initial
calibration has completed.

The reason behind this commit is to begin breaking out the chainmask
configuration for this specific reason; follow-up commits will add
the chainmask restore in the ar5416Reset() routine.
2011-01-26 10:08:37 +00:00
Adrian Chadd
5a2def3a5e * fix HAL_DEBUG_INTERRUPT to be a separate bit, it was overlapping with
something else
* add HAL_DEBUG_GPIO, for some GPIO related debugging I'm tinkering with
  at the moment.
2011-01-26 09:37:43 +00:00
Adrian Chadd
3545027dc3 * Re-format the v4k header to be consistent
* Re-do the structure size/component math to make sure the struct matches
  the expected size
* Just to be clear that we care about bitmask ordering, revert my previous
  change and instead define that macro if we're on big-endian.
2011-01-25 07:37:12 +00:00
Adrian Chadd
6468b2baa5 Bring over a fix from ath9k - zero some of the TX descriptors for Kite/AR9285.
Kite doesn't have per-chain control (it has one chain) or antenna control; so
don't try to set those descriptor entries.
2011-01-25 05:47:50 +00:00
Adrian Chadd
2b020858f9 Rename this linux-ism __BIG_ENDIAN_BITFIELD macro to something suitable for FreeBSD.
Warner has pointed out that FreeBSD's bit orders follow byte orders.
2011-01-25 05:41:36 +00:00
Adrian Chadd
d55a8a09e8 Commit updated AR9285 (Kite) v2 initvals from ath9k. 2011-01-25 05:36:29 +00:00
Adrian Chadd
fb14f71662 Fix the Atheros V4K EEPROM definitions to match those in ath9k.
It turns out that the V4K eeprom definitions (used by the AR9285 and
its derivatives) is wrong. These values are at least causing issues
on my AR2427.

With this fix (and initvals in a subsequent commit), the AR2427 behaves
a lot better.

Note - there's still significant drift between the ath9k v4k eeprom
init code (again, used by AR9285 and derivatives) and what's in this
tree. That needs to be investigated and resolved.
2011-01-25 05:35:09 +00:00
Adrian Chadd
514539dcbd Remove an invalid register setup; this is likely a holdover from
the AR5212 code. It doesn't exist in ath9k and I've been told it
doesn't exist in the Atheros internal driver.
2011-01-24 17:03:22 +00:00
Adrian Chadd
d8d0c29db8 Enable the 11n PHY by default whether or not 11n is configured.
The linux ath9k driver and (from what I've been told) the atheros reference
driver does this; it then leaves discarding 11n frames to the 802.11 layer.

Whilst I'm here, merge in a fix from ath9k which maintains a turbo register
setting when enabling the 11n register; and remove an un-needed (duplicate)
flag setting.
2011-01-23 14:49:50 +00:00