#
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 |
#
250856 |
|
21-May-2013 |
adrian |
Fix build break - the SetCapability calls return HAL_BOOL, not HAL_STATUS.
|
#
250841 |
|
21-May-2013 |
adrian |
Extend the TXOP enforce capability to support checking whether it's supported.
|
#
247286 |
|
25-Feb-2013 |
adrian |
Begin adding support to explicitly set the current chainmask.
Right now the only way to set the chainmask is to set the hardware configured chainmask through capabilities. This is fine for forcing the chainmask to be something other than what the hardware is capable of (eg to reduce TX/RX to one connected antenna) but it does change what the HAL hardware chainmask configuration is.
For operational mode changes, it (may?) make sense to separately control the TX/RX chainmask.
Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks() calculates which TX/RX chainmasks to enable based on the operating mode. (1 for legacy and whatever is supported for 11n operation.) But doing this in the HAL is suboptimal - the driver needs to know the currently configured chainmask in order to correctly enable things for each TX descriptor. This is currently done by overriding the chainmask config in the ar5416 TX routines but this has to disappear - the AR9300 HAL support requires the driver to dynamically set the TX chainmask based on the TX power and TX rate in order to meet mini-PCIe slot power requirements.
So:
* Introduce a new HAL method to set the operational chainmask variables; * Introduce null methods for the previous generation chipsets; * Add new driver state to record the current chainmask separate from the hardware configured chainmask.
Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving it into the driver; as well as properly programming the TX chainmask based on the currently configured HAL chainmask.
Tested:
* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified that AR_SELFGEN_MASK (the chainmask used for self-generated frames like ACKs and RTSes) is correct, as well as the TX descriptor contents is correct.
|
#
243743 |
|
01-Dec-2012 |
adrian |
Add a new HAL capability - check and enforce whether the NIC supports enforcing the TXOP and TBTT limits:
* Frames which will overlap with TBTT will not TX; * Frames which will exceed TXOP will be filtered.
This is not enabled by default; it's intended to be enabled by the TDMA code on 802.11n capable chipsets.
|
#
243472 |
|
24-Nov-2012 |
adrian |
Add a comment which covers what's going on with the 64 bit TSF write.
After chatting with the MAC team, the TSF writes (at least on the 11n MACs, I don't know about pre-11n MACs) are done as 64 bit writes that can take some time. So, doing a 32 bit TSF write is definitely not supported. Leave a comment here which explains that.
Whilst here, add a comment which outlines that after a reset or TSF write, the TSF write may take a while (up to 50uS) to update. A write or reset shouldn't be done whilst the previous one is in flight. Also (and this isn't currently done) a read shouldn't occur until the SLEEP32_TSF_WRITE_STAT is clear. Right now we're not doing that, mostly because we haven't been doing lots of TSF resets/writes until recently.
|
#
243424 |
|
23-Nov-2012 |
adrian |
Implement a HAL method to set a 64 bit TSF value.
TODO: implement it (and test) for the AR5210/AR5211.
|
#
240446 |
|
13-Sep-2012 |
adrian |
Call the ar5212SetCoverageClass() function for now.
Some of the math is a little wrong thanks to clocks in 11a mode running at 44MHz when in fast clock mode (rather than 40MHz, which the chips before AR9280 ran 11a in). That'll have to be addressed in a future commit.
|
#
237868 |
|
01-Jul-2012 |
adrian |
Migrate the MAC/BB hang structures out from ar5416_misc.h into the HAL.
The ar9300 HAL also uses these types, so it makes no sense to duplicate them.
|
#
234873 |
|
01-May-2012 |
adrian |
Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t, to return whether it was successful.
Add placeholder (blank) methods for previous chips, for both it and the 11n extension channel busy call.
|
#
234752 |
|
28-Apr-2012 |
adrian |
Extend the ANI code to implement basic channel survey support.
* Always call ar5416GetListenTime() * Modify ar5416GetListenTime() to: + don't update the ANI state if there isn't any ANI state; + don't update the channel survey state if there's no active channel - just to be paranoid + copy the channel survey results into the current sample slot based on the current channel; then increment the sample counter and sample history counter. * Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE, rather than a set of percentages. The ANI code wasn't using the percentages anyway.
TODO:
* Create a new function which fetches the survey results periodically * .. then modify the ANI code to use the pre-fetched values rather than fetching them again * Roll the 11n ext busy function from ar5416_misc.c to update all the counters, then do the result calculation * .. then, modify the MIB counter routine to correctly fetch a snapshot - freeze the counters, fetch the values, then reset the counters.
|
#
231927 |
|
20-Feb-2012 |
adrian |
Break out the radar code into a separate source file.
This mirrors the internal HAL organisation and reduces the differences between the HAL codebases slightly.
Obtained from: Atheros
|
#
231864 |
|
17-Feb-2012 |
adrian |
Fix the return type.
Submitted by: arundel Found by: clang/llvm
|
#
231709 |
|
14-Feb-2012 |
adrian |
Fix the usefir128 config bit flipping.
|
#
231708 |
|
14-Feb-2012 |
adrian |
Improve the radar register config API.
* Fix the "enabled" flag to actually reflect whether radar detection is enabled or not. * Add flags for the relstep/relpwr checks.
|
#
231371 |
|
10-Feb-2012 |
adrian |
Enforce the hardware chainmask when allowing the user to override the chainmask.
This way a disabled radio chain can't be enabled by a user.
|
#
231368 |
|
10-Feb-2012 |
adrian |
Extend the HAL code to allow the RX and TX chainmask to be overridden by capabilities.
Add an ar5416SetCapability() function, which contains logic to override the chainmask and update the relevant stream.
This is designed to be called after the attach function, which presets the TX/RX chainmask and stream.
TODO: check the chainmask against the hardware chainmask so non-existing chains aren't enabled.
|
#
228889 |
|
26-Dec-2011 |
adrian |
Update the hardware LED blinking code to do something useful rather than relying on what the register defaults are.
This forces the blink mode to be proportional to the TX and RX frames which match the RX filter.
This (along with a few tweaks to if_ath_led.c to configure the correct GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful fashion, however those LEDs are marked "Link" and "Act(ivity)", which don't really map well to the "power" / "network" LED interface which the MAC provides. Some further tinkering is needed to see what other useful operating modes are possible.
|
#
228837 |
|
23-Dec-2011 |
adrian |
Disable the code which hard-sets the LEDs on. This prevents the LED state from correctly updating things.
The reference driver directly enables/disables the LED state as required, rather than nailing it up like it currently is. That'll have to come later by adding some further HAL methods.
Obtained from: Atheros
|
#
228817 |
|
22-Dec-2011 |
adrian |
Use the correct types when calling the decompression mask function.
There's currently no public code which uses this feature and the current reference driver doesn't enable this feature at all. It's possible it was used by a previous version of the driver and that indeed it should return HAL_STATUS; but at this point I'm happy to require that they complain and submit a patch.
This was found by LLVM compile-time type checking.
Submitted by: dim
|
#
228800 |
|
22-Dec-2011 |
dim |
Revert r228786. We'll need to work around the warnings in another way.
Requested by: adrian MFC after: 1 week
|
#
228786 |
|
21-Dec-2011 |
dim |
Fix enum conversion problems in sys/dev/ath/ath_hal/ar5212/ar5212_misc.c and sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:
sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:577:24: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion] return HAL_EINVAL; ~~~~~~ ^~~~~~~~~~
and:
sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:164:9: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion] return HAL_OK; ~~~~~~ ^~~~~~
In both cases, enums HAL_BOOL and HAL_STATUS are mixed up.
MFC after: 1 week
|
#
227374 |
|
09-Nov-2011 |
adrian |
Port over a new routine which grabs the percentage of time spent in TX frame, RX frame, RX clear, RX extension clear.
This is useful for estimating channel business.
The same routines should be written for AR5210->AR5212 where appopriate.
Obtained from: Atheros
|
#
226761 |
|
25-Oct-2011 |
adrian |
Fix an incorrect flag.
Obtained from: Atheros
|
#
225957 |
|
03-Oct-2011 |
adrian |
Add an AR5416 aware version of the "current RSSI" function.
Pre-11n devices and AR5416 use AR_PHY(263) for current RX RSSI. AR9130 and later have a fourth calibration register (for doing ADC calibration) and thus the register has moved to AR_PHY(271).
This isn't currently used by any of the active code; I'm committing this for completeness and in case any third party code attempts to use it for legacy reasons.
|
#
225934 |
|
03-Oct-2011 |
adrian |
Port over the radar pulse decoding code common to the AR5416 and later chipsets.
Obtained from: Atheros
|
#
225444 |
|
07-Sep-2011 |
adrian |
Update the TSF and next-TBTT methods to work for the AR5416 and later NICs. This is another commit in a series of TDMA support fixes for the 11n NICs.
* Move ath_hal_getnexttbtt() into the HAL; write methods for it. This returns a timer value in TSF, rather than TU.
* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they likely now belong.
* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF. The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor; the AR5416 and later write 32 bit TSF snapshots into the RX descriptor. * Use the new capability to choose between 15 and 31 bit TSF adjustment functions in ath_extend_tsf().
* Write ar5416GetTsf64() and ar5416SetTsf64() methods. ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.
According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA stations can now associate/talk, but there are still issues with traffic stability which need to be investigated.
The ath_hal_extendtsf() function is also used in RX packet timestamping; this may improve adhoc mode on the 11n chipsets. It also will affect the timestamps seen in radiotap frames.
Submitted by: Kang Yin Su <cantona@cantona.net> Approved by: re (kib)
|
#
224709 |
|
08-Aug-2011 |
adrian |
Add another HAL method - ah_isFastClockEnabled - which returns AH_TRUE if 5ghz fast clock is enabled in the current operating mode.
It's slightly dirty, but it's part of the reference HAL and used by the (currently closed-source) radar event code to map radar pulses back to microsecond durations.
Obtained from: Atheros Approved by: re (kib, blanket)
|
#
224517 |
|
30-Jul-2011 |
adrian |
Fix AR5416 radar parameter initialisation.
* I messed up the order of parameter true/false; oops! * AR_PHY_RADAR_1 was being written at the wrong place, and was writing potential garbage to the hardware.
Approved by: re (kib)
|
#
224244 |
|
21-Jul-2011 |
adrian |
Modify the radar API a little to be easier to "change" via run-time tools.
* introduce pe_enabled, which (will) indicate whether the radar detection stuff is enabled or not. Right now it's incorrectly set, based on something previously written. I'll sort it out later.
* Don't set HAL_PHYERR_PARAM_ENABLE in pe_relstep to say whether radar detection is on.
* Return whether blockradar, fir128 and enmaxrssi is enabled.
* Change some of the phyerr params to be integers rather than HAL_BOOL so they can be set to the NOPARAM value when the setup function is called. This is in line with other radar parameters.
* Add new configuration parameters for fir128, blockradar and enmaxrssi, rather than defaulting to off, on and on respectively.
Approved by: re (kib)
|
#
223459 |
|
23-Jun-2011 |
adrian |
Break out most of the HAL related tweaks into a per-HAL instance, rather than global variables.
This specifically allows for debugging to be enabled per-NIC, rather than globally.
Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI consistent regardless of whether AH_DEBUG is enabled or not, enable the debug parameter always but only conditionally compile in the debug methods if needed.
The ALQ support is currently still global pending some brainstorming.
Submitted by: ssgriffonuser@gmail.com Reviewed by: adrian, bschmidt
|
#
222815 |
|
07-Jun-2011 |
adrian |
Flesh out a new HAL method to fetch the radar PHY error frame information.
For the AR5211/AR5212, this is apparently a one byte pulse duration counter value. It is only coded up here for the AR5212 as I don't have any AR5211-series hardware to test it on.
This information was extracted from the Madwifi DFS branch along with some local additions.
Please note - all this does is extract out the radar event duration, it in no way reflects the presence of a radar. Further code is needed to take a set of radar events and filter them to extract out correct radar pulse trains (and ignore other events.)
For further information, please see:
http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection
This includes references to the relevant patents which describe what is going on.
Obtained from: Madwifi
|
#
222644 |
|
03-Jun-2011 |
adrian |
Bring over the relevant registers to use when implementing the quiet time portion of 802.11h.
The AR5212 code has been brought over as a reference, it's currently untested.
Obtained from: Atheros
|
#
222584 |
|
01-Jun-2011 |
adrian |
Add some missing DFS chipset functionality to the FreeBSD HAL.
Please note - this doesn't in any way constitute a full DFS implementation, it merely adds the relevant capability bits and radar detection threshold register access.
The particulars:
* Add new capability bits outlining what the DFS capabilities are of the various chipsets. * Add HAL methods to set and get the radar related register values. * Add AR5212 and AR5416+ DFS radar related register value routines. * Add a missing HAL phy error code that's related to radar event processing. * Add HAL_PHYERR_PARAM, a data type that encapsulates the radar register values.
The AR5212 routines are just for completeness. The AR5416 routines are a super-set of those; I may later on do a drive-by pass to tidy up duplicate code.
Obtained from: Linux, Atheros
|
#
221878 |
|
14-May-2011 |
adrian |
When disabling RIFS for Sowl (AR9160) and Howl (AR9130), make sure RIFS is totally disabled.
The Atheros HAL code does this for Sowl/Howl but not for Owl (AR5416) where RIFS is disabled by default.
This seems to quieten the occasional baseband hang I've been seeing with the AR9160 in STA mode under constant heavy traffic load.
Obtained from: Atheros
|
#
221603 |
|
07-May-2011 |
adrian |
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.
|
#
221582 |
|
07-May-2011 |
adrian |
Instead of returning an unknown mac/bb signature, just return 0.
|
#
221580 |
|
07-May-2011 |
adrian |
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
|
#
221535 |
|
06-May-2011 |
adrian |
Add a function which enables or disables RX RIFS searching, and migrate the code which does this into it.
|
#
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.
|
#
220772 |
|
18-Apr-2011 |
adrian |
Add global TX timeout handling.
The global TX timeout counter increments whenever a frame is ready to be transmitted and the medium is busy.
|
#
220718 |
|
16-Apr-2011 |
adrian |
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.
|
#
220323 |
|
04-Apr-2011 |
adrian |
At least set the coverage class value here; worry about populating the register values at a later date.
|
#
217634 |
|
20-Jan-2011 |
adrian |
Only enable 11n modes if the chipset suports 11n.
Since the AR2427 doesn't allow 802.11n, it shouldn't have them configured.
|
#
203750 |
|
10-Feb-2010 |
rpaulo |
't' stands for Turbo and is a valid mode, so fix previous commit.
Pointed out by: sam
|
#
203680 |
|
08-Feb-2010 |
rpaulo |
Fix typo in comment.
|
#
203158 |
|
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
|