Commit Graph

107 Commits

Author SHA1 Message Date
adrian
e85dde4087 Make sure that the AR_MISC_MODE value from the initvals are properly respected.
This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."

The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.

The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.

This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)

The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.
2011-03-19 03:15:28 +00:00
adrian
895978da06 Use the HAL method rather than directly calling ar5212ResetTxQueue().
Since ath9k does some slightly different bit fiddling when setting up
the TX queues, it may that the TX queue setup/reset functions will need
overriding later on.
2011-03-19 03:09:21 +00:00
adrian
483d4d7b61 Add debugging messages to the AR5416 ANI code that's found in the AR5212 ANI code. 2011-03-19 00:46:10 +00:00
adrian
f90fad94e2 Fix the nfarray offsets for the ar2133/ar5133 radio - (AR5416, AR9160, etc.)
The offsets didn't match the assumption that nfarray[] is ordered by the
chainmask bits and programmed via the register order in ar5416_cca_regs[].
This repairs that damage and ensures that chain 1 is programmed correctly.
(And extension channels will now be programmed correctly also.)

This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416
setups - because Chain 1 would be programmed -80 or -85 dBm, which is
higher than the actual noise floor and thus convincing the radio that
indeed it can't ever transmit.
2011-03-13 13:00:45 +00:00
adrian
64cd31ce69 Move out some of the shared eeprom board value calculation routines into ah.c
rather than duplicating them for the v14 (ar5416+) and v4k (ar9285) codebases.

Further chipsets (eg the AR9287) have yet another EEPROM format which will use
these routines to calculate things.
2011-03-13 05:54:05 +00:00
adrian
d4ef3ac078 * Add in some board settings debugging to log what's being written
to the TX closed-loop power control registers.
* Modify a couple of functions to take the register chain number,
  rather than the regChainOffset value. This allows for the
  register chain to be logged.
2011-03-13 05:30:14 +00:00
adrian
1e92db1bb1 Introduce methods for the initial calibration and the new PA calibration
routines.

These are needed for the AR9285/AR2427 and AR9287 calibration routines
which will be introducecd in a later commit.
2011-03-11 11:35:36 +00:00
adrian
3158c29d9a Remove the ar9285FillVpdTable() and just use ar5416FillVpdTable(). 2011-03-11 11:07:53 +00:00
adrian
9e1a253852 Don't call ar5416SetTransmitPower() directly from ar5416SetTxPowerLimit();
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.

It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
2011-03-11 03:46:27 +00:00
adrian
713a1e3163 Merlin fix - first pdadc gain index is 0 - minpwr/2 .
Obtained from:	Linux ath9k
2011-03-10 06:06:26 +00:00
adrian
2bd8cf3534 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.)
2011-03-10 02:09:06 +00:00
adrian
3fb3a9435d 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
c0c76118d8 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
364ba3d049 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
8d723827ef * 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
879ce9c16d 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
31a3684881 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
d0b77b6d17 Call the right function. 2011-02-17 05:30:38 +00:00
adrian
e5e1902441 bring this in line with what ath9k does. 2011-02-14 21:35:11 +00:00
adrian
951fbe8cc6 I missed this commit - enable 4k transaction support for the ar5416+ar9160. 2011-02-08 14:15:46 +00:00
adrian
f8faf0fc91 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
146115253f 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
e42de5418c 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
1fe70193d4 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
7fba065058 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
77d48002a1 Avoid writing CCA threshold values for the EXT radios for non-HT40 channels. 2011-01-29 14:36:31 +00:00
adrian
16700c0fc2 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
1923543717 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
876bfc9fd7 Link in the 11n specific TX methods into the HAL. 2011-01-29 12:16:26 +00:00
adrian
d0ef1d0ef8 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
fee911616d 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
9e4c2dfc54 Add missing getCapability call for AR5416. 2011-01-27 08:42:50 +00:00
adrian
dfa1118b46 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
da97332384 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
09011c696c 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
41d0e0ecb5 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
7116b24f38 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
a5667769eb 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
adrian
8309d73878 Fix some typos. 2011-01-21 07:28:48 +00:00
adrian
8bd8fc209e Add missing getCapability call for AR5416. 2011-01-21 07:26:53 +00:00
adrian
88a17f226b 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.
2011-01-21 05:21:00 +00:00
adrian
2d762880b3 Only enable 11n modes if the chipset suports 11n.
Since the AR2427 doesn't allow 802.11n, it shouldn't have them
configured.
2011-01-20 09:46:18 +00:00
adrian
ec46d68e0c 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.
2011-01-20 09:03:40 +00:00
adrian
909155a389 Add a comment from my local HAL about what is actually going on here
with these ADC DC Gain/Offset calibrations.

The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.

The AR5416 returns lots of garbage, so there's no need to do the
calibration there.

The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
2011-01-20 08:40:22 +00:00
adrian
0779b4e7dc 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.
2011-01-20 07:56:09 +00:00
adrian
155d93ad41 Add a new HAL method to retrieve the completion schedule. It sets
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.

The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.
2011-01-20 05:49:15 +00:00
adrian
4481103708 Fix indenting/whitespace issues introduced by me. 2010-08-15 11:40:53 +00:00
adrian
5641813833 The comment is misleading - that register setting seems to kick off the
initial chip NF cal.
2010-08-15 11:32:05 +00:00
adrian
a8c5860291 A local addition, not imported from ath9k.
AR_PHY_CALMODE is explicitly reset on interface reset for other chipsets;
this commit also sets it for the AR9160.
2010-08-14 15:48:18 +00:00
adrian
a5baf37074 * Merge in AR9160 initval updates from Linux-2.6.34.
* Grab the AR_PHY_CCA and AR_PHY_EXT_CCA initvals from Linux wireless-testing.

Obtained from: Linux-2.6.34
2010-08-14 15:46:18 +00:00