summaryrefslogtreecommitdiffstats
path: root/sys/dev/ath/ath_hal/ar5212
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Importing pfSense patches net80211HEAD.tgz and conf.file.ieee80211.diff"Renato Botelho2016-02-226-30/+27
| | | | This reverts commit 6ee75bdd7bf7c20359dd6e38c243586cb062edea.
* Importing pfSense patches net80211HEAD.tgz and conf.file.ieee80211.diffRenato Botelho2015-08-176-27/+30
|
* MFC r274922:dim2014-12-041-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following -Werror warning from clang 3.5.0, while building the ath kernel module: sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value] if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) { ^ sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs' #define abs(_a) __builtin_abs(_a) ^ sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs' #define abs(_a) __builtin_abs(_a) ^ 1 error generated. This warning occurs because both lp[0] and target are unsigned, so the subtraction expression is also unsigned, and calling abs() is a no-op. However, the intention was to look at the absolute difference between the two unsigned quantities. Introduce a small static function to clarify what we're doing, and call that instead. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D1212
* Add channel survey support to the AR5212 HAL.adrian2013-10-083-18/+102
| | | | | | | | | | | | | | | The AR5212 series of MACs implement the same channel counters as the later 11n chips - except, of course, the 11n specific counter (extension channel busy.) This allows users of these NICs to use 'athsurvey' to see how busy their current channel is. Tested: * AR5212, AR2413 NICs, STA mode Approved by: re@ (gleb)
* Begin adding support to explicitly set the current chainmask.adrian2013-02-253-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* When programming the beacon timer configuration, be very explicit aboutadrian2012-11-271-4/+13
| | | | | | | | | | | | | | | | | | | | what the maximum legal values are. The current beacon timer configuration from TDMA wraps things at HAL_BEACON_PERIOD-1 TU. For the 11a chips this is fine, but for the 11n chips it's not enough resolution. Since the 11a chips have a limit on what's "valid", just enforce this so when I do write larger values in, they get suitably wrapped before programming. Tested: * AR5413, TDMA slave Todo: * Run it for a (lot) longer on a clear channel, ensure that no strange slippages occur. * Re-validate this on STA configurations, just to be sure.
* Implement a HAL method to set a 64 bit TSF value.adrian2012-11-231-0/+1
| | | | TODO: implement it (and test) for the AR5210/AR5211.
* .. include ah_desc.h here now.adrian2012-11-172-0/+2
|
* Remove the ah_desc.h reference; it's not needed.adrian2012-11-171-1/+0
| | | | | I'm using these descriptor header files in userland and I'm trying to avoid populating a compatibility ah_desc.h file.
* Remove duplicate const specifiers in many drivers (I hope I got all ofdim2012-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | them, please let me know if not). Most of these are of the form: static const struct bzzt_type { [...list of members...] } const bzzt_devs[] = { [...list of initializers...] }; The second const is unnecessary, as arrays cannot be modified anyway, and if the elements are const, the whole thing is const automatically (e.g. it is placed in .rodata). I have verified this does not change the binary output of a full kernel build (except for build timestamps embedded in the object files). Reviewed by: yongari, marius MFC after: 1 week
* HAL updates!adrian2012-10-311-1/+23
| | | | | | | | | | | | | * Add some more ANI spur immunity levels. * For AR5111 radios attached to an AR5212, limit the 5GHz channels that are available. A later revision of the AR5111 supports the 4.9GHz PSB channels but right now there's no check in place for the radio revision. If someone wants PSB support on AR5212+AR5111 radios then please let me know and I'll add the relevant version check. Obtained from: Qualcomm Atheros
* AR5212 radar pulse fixes.adrian2012-09-021-13/+12
| | | | | | | | | | | | | | | | | | | | | | Fix the strong signal diversity capability setting - I had totally messed up the indentation. Set the default values to match what's in the .ini for now, rather than what values I had previously gleaned from places. This seems to work quite well for the early AR5212 NICs I have. Of course, later NICs have different PHYs and the radar configuration is very card/board dependent.. Tested: * ath1: AR5212 mac 5.3 RF5111 phy 4.1 ath1: 2GHz radio: 0x0023; 5GHz radio: 0x0017 This detects 1, 5, 25, 50, 75, 100uS pulses reliably (with no interference.) However, 10uS pulses don't detect reliably. That may be around the transition between short and long pulses so some further tuning may improve things.
* Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also popsadrian2012-09-011-4/+14
| | | | | | | | | | | | | | up on (at least) the AR5413. The 30 second summary - if a CRC error frame comes in during PHY error processing, that CRC bit will be set for all subsequent frames until a non-CRC error frame is processed. So to allow for accurate PHY error processing (Radar, and ANI on the AR5212 HAL chips) just tag the frame as being both CRC and PHY - let the driver decide what to do with it. PR: kern/169362
* Add AR5413 radar parameters and strong signal diversity capability.adrian2012-08-292-21/+155
| | | | | | | | | | | | This is a re-implementation based on the reference carrier code for the AR5413. Tested: * Pulse detection for AR5212 and AR5413, to ensure the correct behaviour for both chips PR: kern/170904 Obtained from: Qualcomm Atheros
* Correctly handle the "pe_enabled" flag - both when configuring DFS andadrian2012-08-241-1/+7
| | | | | | fetching the current DFS configuration. PR: kern/170904
* Add default values for the NumTxMaps capability.adrian2012-08-241-0/+1
|
* Add the method to fetch the default DFS parameters for the AR5212 PHY.adrian2012-08-243-1/+33
| | | | | | I need to check whether new parameters were added for the AR5413 NIC. PR: kern/170904
* Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.adrian2012-08-052-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing API only exposes 'seglen' (the current buffer (segment) length) with the data buffer pointer set in 'ds_data'. This is fine for the legacy DMA engine but it won't work for the EDMA engines. The EDMA engine has a significantly different TX descriptor layout. * The legacy DMA engine had a ds_data pointer at the same offset in the descriptor for both TX and RX buffers; * The EDMA engine has no ds_data for RX - the data is DMAed after the descriptor; * The EDMA engine has support for 4 TX buffer/segment pairs in the TX DMA descriptor; * The EDMA TX completion is in a different FIFO, and the driver will 'link' the status completion entry to a QCU by a "QCU ID". I don't know why it's just not filled in by the hardware, alas. So given that, here are the changes: * Instead of directly fondling 'ds_data' in ath_desc, change the ath_hal_filltxdesc() to take an array of buffer pointers as well as segment len pointers; * The EDMA TX completion status wants a descriptor and queue id. This (for now) uses bf_state.bfs_txq and will extract the hardware QCU ID from that. * .. and this is ugly and wasteful; it should change to just store the QCU in the bf_state and save 3/7 bytes in the process. Now, the weird crap: * The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than taking a function argument. I've tidied that up. * The multicast queue frames get put on a software TXQ and then that is appended to the hardware CABQ when appropriate. So for now, make sure that bf_state->bfs_txq points at the CABQ when adding frames to the multicast queue. * .. but the multicast queue TX path for now doesn't use the software queue and instead (a) directly sets up the descriptor contents at that point; (b) the frames on the vap->avp_mcastq are then just appended wholesale to the CABQ. So for now, I don't have to worry about making the multicast path work with aggregation or the per-TID software queue. Phew. What's left to do: * I need to modify the 11n ath_hal_chaintxdesc() API to do the same. I'll do that in a subsequent commit. * Remove bf_state.bfs_txq entirely and store the QCU as appropriate. * .. then do the runtime "is this going on the right HWQ?" checks using that, rather than comparing pointer values. Tested on: * AR9280 STA/AP * AR5416 STA/AP
* Flesh out the multi-rate retry capability.adrian2012-07-281-0/+1
| | | | | | | | The existing method for testing for MRR is to call the "SetupXTXDesc" HAL method and see if it returns AH_TRUE or AH_FALSE. This capability explicitly lists what number of multi-rate attempts are possible. "1" means "one rate attempt supported".
* Break out the TX descriptor link field into HAL methods.adrian2012-07-193-0/+33
| | | | | | | | | | | | | | | | The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy chips: * The RX DMA descriptors don't have a ds_link field; * The TX DMA descriptors have a ds_link field however at a different offset. This is a reimplementation based on what the reference driver and ath9k does. A subsequent commit will enable it in the TX and beacon paths. Obtained from: Linux ath9k, Qualcomm Atheros
* Extend the RX HAL API to include the RX queue identifier.adrian2012-07-092-4/+8
| | | | | | | | | | The AR93xx and later chips support two RX FIFO queues - a high and low priority queue. For legacy chips, just assume the queues are high priority. This is inspired by the reference driver but is a reimplementation of the API and code.
* oops - ath_hal_disablepcie is actually destined for another purpose,adrian2012-05-251-3/+4
| | | | | | | not to disable the PCIe PHY in prepration for reset. Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
* Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t,adrian2012-05-013-2/+15
| | | | | | | to return whether it was successful. Add placeholder (blank) methods for previous chips, for both it and the 11n extension channel busy call.
* After thinking about this a bit more, let's not keep statistics per-channeladrian2012-04-283-5/+5
| | | | | | | | | | | | | | | in the HAL. That's very memory hungry (32k just for channel statistics) which would be better served by keeping a summary in the ANI state. Or, later, keep a survey history in net80211. So: * Migrate the ah_chansurvey array to be a single entry, for the current channel. * Change the ioctl interface and ANI code to just reference that. * Clear the ah_chansurvey array during channel reset, both in the AR5212 and AR5416 reset path.
* Fetch the channel survey code from the HAL.adrian2012-04-282-0/+9
| | | | | This information is currently not being populated by any of the HAL modules.
* Stop using the hardware register value byte order swapping for now,adrian2012-04-191-4/+3
| | | | | | | | | | | | | | | at least until I can root cause what's going on. The only platform I've seen this on is the AR9220 when attached to the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent accesses cause further MIPS bus exceptions. I don't have any other big-endian platforms to test this on. If I get a chance (or two), I'll try to whack this on a bus analyser and see exactly what happens. I'd rather leave this on, especially for slower, embedded platforms. But the #ifdef hell is something I'm trying to avoid.
* Radar API related fixes.adrian2012-01-303-0/+18
| | | | | | | | | | | | * For legacy NICs, the combined RSSI should be used. For earlier AR5416 NICs, use control chain 0 RSSI rather than combined RSSI. For AR5416 > version 2.1, use the combined RSSI again. * Add in a missing AR5212 HAL method (get11nextbusy) which may be called by radar code. This serves no functional change for what's currently in FreeBSD.
* Use the correct types when calling the decompression mask function.adrian2011-12-221-1/+1
| | | | | | | | | | | | 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
* Revert r228786. We'll need to work around the warnings in another way.dim2011-12-221-1/+1
| | | | | Requested by: adrian MFC after: 1 week
* Fix enum conversion problems in sys/dev/ath/ath_hal/ar5212/ar5212_misc.cdim2011-12-211-1/+1
| | | | | | | | | | | | | | | | | | 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
* The AR5413 datasheet specifies that AR_TxIntrReq should be set consistentlyadrian2011-10-251-2/+9
| | | | for all frames, so do so.
* Save and restore the association ID across interface resets.adrian2011-10-253-3/+6
| | | | | Obtained from: Atheros MFC after: 1 week
* Port over some missing code from the ar5212 reference driver reset path.adrian2011-10-182-2/+147
| | | | | | | | The final missing bit here is enabling the PCI configuration register read, but there's currently no glue available for the HAL to read (and write) PCI configuration space registers. Obtained from: Atheros
* Fix a corner case in the HAL debugging changes, where ah was NULL.adrian2011-09-302-3/+3
| | | | | | | | | | | | | Although I tried to fix this earlier by introducing HALDEBUG_G(), it turns out there seem to be other cases where the pointer value is still NULL. * Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL before deferencing it * Remove HALDEBUG_G() as it's no longer needed This is hopefully a merge candidate for 9.0-RELEASE as enabling debugging at startup could result in a kernel panic.
* Change the default CABQ time to be 70% of the beacon interval,adrian2011-09-281-6/+31
| | | | | | | | | | | | | | | rather than the whole beacon interval. The reference driver and Linux ath9k both choose 80% of the beacon interval and they do it in the driver rather than the HAL (Ath reference) or ath9k_hw (ath9k.) This quietens stuck beacon conditions on my AR9220/AR9280 based NICs when a lot of burst broadcast/multicast traffic is going on. It doesn't seem to annoy the earlier MACs as much as the AR9280 and later one. Obtained from: Linux ath9k, Atheros
* The AR5212 setup path (also used by the AR5416 code) configures aadrian2011-09-281-0/+2
| | | | | | | | | | | | | | | | | | local variable with a beacon interval of 100 TU. This never gets modified if the beacon interval configuration changes. This may have been correct in earlier times, but with the advent of staggered beacons (which default to 1 / ATH_BCBUF beacon interval, so 25 TU here) this value is incorrect. It is used to configure the default CABQ readytime. So here, the cabq was being configured to be much greater than the target beacon timer (TBTT.) The driver should be configuring a cabq readytime value rather then leaving it to the HAL to choose sensible defaults. This should be done in the future - I'm simply trying to ensure sensible defaults are chosen.
* Update the TSF and next-TBTT methods to work for the AR5416 and later NICs.adrian2011-09-083-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Add another HAL method - ah_isFastClockEnabled - which returns AH_TRUEadrian2011-08-083-0/+12
| | | | | | | | | | | 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)
* Fix ANI handling to work correctly when (trying) to receive radar errors.adrian2011-07-301-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | * Teach the AR5212/AR5416 ANI code to use the RX filter methods, rather than calling the RX filter routines directly. * Make HAL_ANI_PRESENT and HAL_ANI_MODE unconditionally available, regardless of whether ah_ani_function is masking it. * (Mostly) fully disable ANI if interference mitigation is disabled. When disabled, the ANI code doesn't touch any ANI/PHY registers, leaving them the default value. This is in line with what the Atheros reference driver does. * Correctly set the ANI parameters during ANI reset, rather than when ANI is enabled. In this way, if ANI is disabled or enabled whilst the NIC is not active (and there's no current channel), bogus parameters or a NULL pointer deference doesn't occur. There's still some lingering issues - notably, the MIB events/interrupts aren't fully disabled, so MIB interrupts still occur. I'll worry about that later. Approved by: re (kib)
* Re-introduce a global ath_hal_debug again for now, whilst I figure out whatadrian2011-06-232-3/+3
| | | | | | | | | | | | to do about the few cases where the HAL state isn't available (regdomain) or isn't yet setup (probe/attach.) The global ath_hal_debug now affects all instances of the HAL. This also restores the ability for probe/attach debugging to work; as the sysctl tree may not be attached at that point. Users can just set the global "hw.ath.hal.debug" to a suitable value to enable probe/attach related debugging.
* Fix indenting issues introduced by the previous commit.adrian2011-06-231-2/+2
|
* Break out most of the HAL related tweaks into a per-HAL instance,adrian2011-06-232-5/+5
| | | | | | | | | | | | | | | | | 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
* Since HAL_PHYERR_* is used in the radar code, always include ah_desc.h.adrian2011-06-071-2/+0
|
* Flesh out a new HAL method to fetch the radar PHY error frame information.adrian2011-06-073-0/+48
| | | | | | | | | | | | | | | | | | | | | | | 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
* Bring over the relevant registers to use when implementing the quiet timeadrian2011-06-034-0/+18
| | | | | | | | | portion of 802.11h. The AR5212 code has been brought over as a reference, it's currently untested. Obtained from: Atheros
* Add some missing DFS chipset functionality to the FreeBSD HAL.adrian2011-06-013-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | 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
* The current ANI capability information uses a different set ofadrian2011-05-251-7/+9
| | | | | | | | | | | | | | | | values for the commands, compared to the internal command values (HAL_ANI_CMD.) My eventual aim is to make the HAL_ANI_CMD internal enum match the public API and then remove all this messiness. This now allows HAL_CAP_INTMIT users to use a public HAL_CAP_INTMIT_ enum rather than magic constants. The only magic constants currently used by if_ath are "enable" and "present". Some local tools of mine allow for direct, manual fiddling of the ANI variables and I'll convert these to use the public enum API before I commit them.
* The ANI control for the AR5416 and later chips was calling ar5212AniControl(),adrian2011-05-243-2/+8
| | | | | | | | | | which did AR5212 specific initialisation. This would cause some slight silliness when enabling/disabling ANI. Just to be completely correct - and to ensure the phy error mask/RX filter register isn't incorrectly played with - make the ANI control function a method, have it set appropriately for AR5212/AR5416, and call that from the ANI control interface.
* Fix case, introduced in my previous commit.adrian2011-05-171-1/+1
| | | | | Pointy hat goes to: adrian, for having multiple build screens open and checking the wrong one.
* Use the halMcastKeySrchSupport capability bit to selectively enable/disableadrian2011-05-171-1/+1
| | | | | | | | | the multicast key search support for AR5212, AR5416 and later. The general HAL routine ath_hal_getcapability() implement checking this but it's overridden by a check in ar5212_misc:ar5212GetCapability(). This restores the later functionality in case it's found to be broken in any of the 11n chipsets.
OpenPOWER on IntegriCloud