8 Commits

Author SHA1 Message Date
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
3d45fa543f Add an explanation of the inivals 2011-04-03 11:59:52 +00:00
Adrian Chadd
423c974c28 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.
2011-03-25 00:40:08 +00:00
Adrian Chadd
299bb4987b 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.
2011-03-22 00:12:26 +00:00
Adrian Chadd
70d2183a7d Call the correct ANI Attach routine. 2011-02-02 03:55:34 +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
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
204582f2f3 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