#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
265112 |
|
30-Apr-2014 |
adrian |
* Only update ah_powerMode if we're setting the chip sleep state. Some code will appear soon that is actually setting the chip powerstate separate from the self-generated frames power state. * Allow the AR5416 family chips to actually have the power state changed from the self generated state change.
Tested (STA mode):
* AR5210 * AR5211 * AR5412 * AR5413 * AR5416 * AR9285
|
#
263417 |
|
20-Mar-2014 |
adrian |
Shuffle ah_powerMode to be in a sane spot for the given power operation.
This way the state changes from sleep->awake before the registers are poked and from awake->sleep after the registers are poked.
This way spurious warnings aren't printed by my (to be committed) debugging code.
Tested:
* AR5416, STA
|
#
262969 |
|
10-Mar-2014 |
adrian |
Migrate the chip power mode status to public ath_hal, rather than the private per-chip HAL.
This allows the ah_osdep.[ch] code to check whether the power state is valid for doing chip programming.
It should be a no-op for normal driver work but it does require a clean kernel/module rebuild, as the size of HAL structures have changed.
Now, this doesn't track whether the hardware is ACTUALLY awake, as NETWORK_SLEEP wakes the chip up for a short period when traffic is received. This doesn't actually set the power mode to AWAKE, so we have to be careful about how we touch things.
But it's enough to start down the path of implementing station mode chipset power savings, as a large part of the silliness is making sure the chip is awake during periodic calibration / ANI and random places where transmit may be occuring. I'd rather not a repeat of debugging power save on ath9k, where races with calibration and transmit path stuff took a couple years to shake out.
Tested:
* AR5416, STA mode
|
#
234269 |
|
14-Apr-2012 |
adrian |
Both linux ath9k and the reference driver initialises the PLL here during chip wakeup.
Obtained from: Linux ath9k, Atheros
|
#
221800 |
|
12-May-2011 |
adrian |
Fixes from Atheros:
* If AR9130, give the chip extra time to reset * If AR5416, don't shutdown the chip during reset
|
#
221163 |
|
28-Apr-2011 |
adrian |
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.
|
#
203156 |
|
29-Jan-2010 |
rpaulo |
Replace Id keyword with the FreeBSD keyword.
|
#
186333 |
|
19-Dec-2008 |
sam |
add FreeBSD property
|
#
185521 |
|
01-Dec-2008 |
sam |
import ath hal
|
#
185406 |
|
28-Nov-2008 |
sam |
Replace most compile-time support options with linker sets for chip and RF backend support: o add OS_DATA_SET and OS_SET_DECLARE os requirements for setting up linker sets o add AH_CHIP macro for registering chip support (e.g. 5210) o add AH_RF macro for registering RF support (e.g. 2413); note this isn't required for single chip solutions where there's no ambiguity (e.g. 5416/9160+2133) but for 5212 class parts it's required because of the multi-chip solutions o remove all uses of AH_SUPPORT_AR5210, AH_SUPPORT_AR5211, AH_SUPPORT_5212, and AH_SUPPORT_AR9160; still need AH_SUPPORT_AR5416 to enable the 11n descriptor formats and 5312 support is presently broken o remove all uses of AH_SUPPORT_2133, AH_SUPPORT_2413, AH_SUPPORT_5111, AH_SUPPORT_5112, AH_SUPPORT_2417, AH_SUPPORT_2425, and AH_SUPPORT_5413; 5312-related support still requires fixup
Remaining issues: o fixup SoC attach o ath_hal_attach uses a hack to probe w/o access to the vendorid o fallback handling of parts w/o a macrev needs to be restored
|
#
185380 |
|
27-Nov-2008 |
sam |
Update to later code from my repository: o many bug fixes o add new periodic calibration api o break up 5416 periodic calibration code in preparation for 928x o move get noise floor to rf backends o 5416-specific ani (still disabled) o modularize 5210 eeprom format a la other eeprom formats o start cleaning up regdomain code o prepare for proper 1/2 and 1/4 width channel support o bring back 900MHz card support o clean up 5212 rf version handling o add 1/2 and 1/4 width channel support for 5212 parts o split 5212 rfgain handling out o improve ani debugging o add AH_USE_INIPDGAIN compile option o purge a bunch of dead 5212 state o add 1/2 and 1/4 rate modes o remove HAL_CAP_CHAN_HALFRATE and HAL_CAP_CHAN_QUARTERRATE; the same info can now be deduced from the set of supported modes
|
#
185377 |
|
27-Nov-2008 |
sam |
virgin import of ath hal
|