summaryrefslogtreecommitdiffstats
path: root/sys/dev/ath/ath_hal
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Importing pfSense patches net80211HEAD.tgz and conf.file.ieee80211.diff"Renato Botelho2016-02-2236-261/+76
| | | | This reverts commit 6ee75bdd7bf7c20359dd6e38c243586cb062edea.
* Importing pfSense patches net80211HEAD.tgz and conf.file.ieee80211.diffRenato Botelho2015-08-1736-76/+261
|
* 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)
* Add a HAL local routine to map the 2GHz channel frequency to an IEEEadrian2013-06-262-0/+22
| | | | | | | channel. There's some HAL code in the AR9300 HAL that requires a back-mapping and using the net80211 code isn't appropriate here.
* Set the antenna "config group" field.adrian2013-06-121-0/+1
| | | | | | | The reference HAL pushes a config group parameter to the driver layer to inform it which particular chip behaviour to implement. This particular value tags it as an AR9285.
* Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.adrian2013-06-126-653/+11
| | | | | | | | | | | | | | | | | The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
* Remove the AR9285 specific structure for LNA diversity and use the HAL.adrian2013-06-123-19/+13
| | | | | The AR9300 HAL update included the LNA diversity configuration information so it can be used in the AR9485 configuration code.
* Add bluetooth fixes to the AR5416/AR92xx HAL:adrian2013-06-076-5/+22
| | | | | | | | | | | | | * Call the bluetooth setup function during the reset path, so the bluetooth settings are actually initialised. * Call the AR9285 diversity functions during bluetooth setup; so the AR9285 diversity and antenna configuration registers are correctly programmed * Misc debugging info. Tested: * AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth coexistence but it's part of what I'm currently using.
* Enable slow diversity combining for the AR9285.adrian2013-06-051-0/+2
| | | | | | | | | | | | | | | | | | Now that I understand what's going on - and the RX antenna array maps to what the receive LNA configuration actually is - I feel comfortable in enabling this. If people do have issues with this, there's enough debugging now available that we have a chance to diagnose it without writing it up as 'weird crap.' Tested: * AR9285 STA w/ diversity combining enabled in EEPROM TODO: * (More) testing in hostap mode
* As a temporary work-around (read: until there's a nice API for exposingadrian2013-06-051-0/+29
| | | | | | | | | | | | | | | and controlling this form of antenna diversity) - print out the AR9285 antenna diversity configuration at attach time. This will help track down and diagose if/when people have connectivity issues on cards (eg if they connect a single antenna to LNA1, yet the card has RX configured to only occur on LNA2.) Tested: * AR9285 w/ antenna diversity enabled in EEPROM; * AR9285 w/ antenna diversity disabled in EEPROM; mapping only to a single antenna (LNA1.)
* Add a new capability flag to announce that the chip implements LNA mixingadrian2013-06-054-1/+6
| | | | | | | | | | | | for the RX path. This is different to the div comb HAL flag, that says it actually can use this for RX diversity (the "slow" diversity path implemented but disabled in the AR9285 HAL code.) Tested: * AR9285, STA operation
* Document the AR9285/AR9485 LNA configuration information that'sadrian2013-06-051-0/+26
| | | | | | | | stored in the ctl/ext RSSI field for chain 2. Tested: * AR9285, STA
* Add the combined (mixed) diversity support capability bit for theadrian2013-06-042-0/+4
| | | | AR9285/AR9485.
* Fix receive on the AR9285 (Kite) with only one antenna connected.adrian2013-06-031-1/+14
| | | | | | | | | The main problem here is that fast and driver RX diversity isn't actually configured; I need to figure out why that is. That said, this makes the single-antenna connected AR9285 and AR2427 (AR9285 w/ no 11n) work correctly. PR: kern/179269
* Fix build break - the SetCapability calls return HAL_BOOL,adrian2013-05-211-1/+1
| | | | not HAL_STATUS.
* Extend the TXOP enforce capability to support checking whether it'sadrian2013-05-211-0/+6
| | | | supported.
* Make the HT rate duration calculation work for MCS rates > 15.adrian2013-05-201-2/+2
|
* Implement STBC receive frame statistics.adrian2013-05-083-0/+10
| | | | | | | The AR9280 and later can receive STBC. This adds some statistics tracking to count these frames. A patch to athstats will be forthcoming.
* Add device identification and probe/attach support for the QCA9565.adrian2013-05-023-0/+5
| | | | | | | | | | | | The QCA9565 is a 1x1 2.4GHz 11n chip with integrated on-chip bluetooth. The AR9300 HAL already has support for this chip; it just wasn't included in the probe/attach path. Tested: * This commit brought to you over a QCA9565 wifi connection from FreeBSD. * .. ie, basic STA, pings, no iperf or antenna diversity checking just yet.
* Setup needed tables for TPC on AR5416->AR9287 chips.adrian2013-04-175-81/+344
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add ah_ratesArray[] to the ar5416 HAL state - this stores the maximum values permissable per rate. * Since different chip EEPROM formats store this value in a different place, store the HT40 power detector increment value in the ar5416 HAL state. * Modify the target power setup code to store the maximum values in the ar5416 HAL state rather than using a local variable. * Add ar5416RateToRateTable() - to convert a hardware rate code to the ratesArray enum / index. * Add ar5416GetTxRatePower() - which goes through the gymnastics required to correctly calculate the target TX power: + Add the power detector increment for ht40; + Take the power offset into account for AR9280 and later; + Offset the TX power correctly when doing open-loop TX power control; + Enforce the per-rate maximum value allowable. Note - setting a TPC value of 0x0 in the TX descriptor on (at least) the AR9160 resulted in the TX power being very high indeed. This didn't happen on the AR9220. I'm guessing it's a chip bug that was fixed at some point. So for now, just assume the AR5416/AR5418 and AR9130 are also suspect and clamp the minimum value here at 1. Tested: * AR5416, AR9160, AR9220 hostap, verified using (2GHz) spectrum analyser * Looked at target TX power in TX descriptor (using athalq) as well as TX power on the spectrum analyser. TODO: * The TX descriptor code sets the target TX power to 0 for AR9285 chips. I'm not yet sure why. Disable this for TPC and ensure that the TPC TX power is set. * AR9280, AR9285, AR9227, AR9287 testing! * 5GHz testing! Quirks: * The per-packet TPC code is only exercised when the tpc sysctl is set to 1. (dev.ath.X.tpc=1.) This needs to be done before you bring the interface up. * When TPC is enabled, setting the TX power doesn't end up with a call through to the HAL to update the maximum TX power. So ensure that you set the TPC sysctl before you bring the interface up and configure a lower TX power or the hardware will be clamped by the lower TX power (at least until the next channel change.) Thanks to Qualcomm Atheros for all the hardware, and Sam Leffler for use of his spectrum analyser to verify the TX channel power.
* Use the TPC bank by default for AR9160.adrian2013-04-171-1/+1
| | | | | | | | | | Tested: * AR9160, hostap, verified TX power using (2GHz) spectrum analyser TODO: * 5GHz verification!
* Now that the register definitions are in -HEAD, enable this.adrian2013-04-151-8/+8
|
* Bring over some AR9271 register definitions from the QCA HAL.adrian2013-04-151-0/+19
| | | | Obtained from: Qualcomm Atheros
* Add a new TX power field - it's inteded to be used where low TX poweradrian2013-04-051-0/+1
| | | | | | is configured for higher rates (lower than max) but higher TX power is configured for the lower rates, above the configured cap, to improve long distance behaviour.
* HAL additions to enable MCI Bluetooth coexistence in the AR9300 HAL.adrian2013-04-052-1/+20
| | | | | | | | * Add the rest of the missing GPIO output mux types; * Add in a new debug category; * And a new MCI btcoex configuration option in ath_hal.ah_config Obtained from: Qualcomm Atheros
* Add new regulatory domain.adrian2013-03-242-0/+26
| | | | Obtained from: Qualcomm Atheros
* CABQ calculation changes to try and fix some weird corner cases leadingadrian2013-03-231-4/+4
| | | | | | | | | | | | | | | to stuck beacons. * Set the cabq readytime (ie, how long to burst for) to 50% of the total beacon interval time * fix the cabq adjustment calculation based on how the beacon offset is calculated (the SWBA/DBA time offset.) This is all still a bit magic voodoo but it does seem to have further quietened issues with missed/stuck beacons under my local testing. In any case, it better matches what the reference HAL implements. Obtained from: Qualcomm Atheros
* Use the correct antenna configuration variable here. "diversity" justadrian2013-03-121-2/+2
| | | | | | controls whether it's on or off. Found by: clang
* Add another register definition bit - whether to populate EVM or PLCPadrian2013-03-101-0/+1
| | | | | | data in the RX status descriptor. Obtained from: Qualcomm Atheros
* add a method to set/clear the VMF field in the TX descriptor.adrian2013-03-044-2/+17
| | | | Obtained from: Qualcomm Atheros
* Add in the STBC TX/RX capability support into the HAL and driver.adrian2013-02-272-0/+7
| | | | | | | | The HAL already included the STBC fields; it just needed to be exposed to the driver and net80211 stack. This should allow single-stream STBC TX and RX to be negotiated; however the driver and rate control code currently don't do anything with it.
* Part #2 of the TX chainmask changes:adrian2013-02-252-45/+0
| | | | | | | | | | | | | | | * Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes
* Begin adding support to explicitly set the current chainmask.adrian2013-02-2513-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add a workaround for AR5416, AR9130 and AR9160 chipsets - work aroundadrian2013-02-221-1/+70
| | | | | | | | | | | | | | | | | | | an incorrectly calculated RTS duration value when transmitting aggregates. These earlier 802.11n NICs incorrectly used the ACK duration time when calculating what to put in the RTS of an aggregate frame. Instead it should have used the block-ack time. The result is that other stations may not reserve enough time and start transmitting _over_ the top of the in-progress blockack field. Tsk. This workaround is to popuate the burst duration field with the delta between the ACK duration the hardware is using and the required duration for the block-ack. The result is that the RTS field should now contain the correct duration for the subsequent block-ack. This doesn't apply for AR9280 and later NICs. Obtained from: Qualcomm Atheros
* Be slightly more paranoid with the TX DMA buffer maximum threshold.adrian2013-02-212-2/+23
| | | | | | | | | | Specifically - never jack the TX FIFO threshold up to the absolute maximum; always leave enough space for two DMA transactions to appear. This is a paranoia from the Linux ath9k driver. It can't hurt. Obtained from: Linux ath9k
* Remove this unneeded printf(), sorry!adrian2013-02-211-4/+0
|
* Configure larger TX FIFO default and maximum level values.adrian2013-02-201-2/+18
| | | | | | | | | | This has reduced the number of TX delimiter and data underruns when doing large UDP transfers (>100mbit). This stops any HAL_INT_TXURN interrupts from occuring, which is a good sign! Obtained from: Qualcomm Atheros
* If any of the TX queues have underrun reporting enabled, enableadrian2013-02-201-0/+2
| | | | | | HAL_INT_TXURN in the interrupt mask register. This should now allow for TXURN interrupts to be posted.
* The encryption type field needs to be preserved for each descriptoradrian2013-02-091-0/+6
| | | | | | | | | making up a frame, in both a sub-frame and for all frames in an aggregate. Tested: * AR5416, STA mode
* Clean some 'svn:executable' properties in the tree.pfg2013-01-261-0/+0
| | | | | Submitted by: Christoph Mallon MFC after: 3 days
* Place-holders for enable/active parameter flags.adrian2013-01-111-0/+2
|
* Fix the short repeat option code to not flip the option to 0 whenadrian2013-01-021-2/+2
| | | | we call this w/ NOVAL set.
* Bring over the basic spectral scan framework code from Qualcomm Atheros.adrian2013-01-028-2/+286
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This includes the HAL routines to setup, enable/activate/disable spectral scan and configure the relevant registers. This still requires driver interaction to enable spectral scan reporting. Specifically: * call ah_spectralConfigure() to configure and enable spectral scan; * .. there's currently no way to disable spectral scan... that will have to follow. * call ah_spectralStart() to force start a spectral report; * call ah_spectralStop() to force stop an active spectral report. The spectral scan results appear as PHY errors (type 0x5 on the AR9280, same as radar) but with the spectral scan bit set (0x10 in the last byte of the frame) identifying it as a spectral report rather than a radar FFT report. Caveats: * It's likely quite difficult to run spectral _and_ radar at the same time. Enabling spectral scan disables the radar thresholds but leaves radar enabled. Thus, the driver (for now) needs to ensure that only one or the other is enabled. * .. it needs testing on HT40 mode. Tested: * AR9280 in STA mode, HT/20 only TODO: * Test on AR9285, AR9287; * Test in both HT20 and HT40 modes; * .. all the driver glue. Obtained from: Qualcomm Atheros
* Add the initial HAL glue for the spectral analysis support.adrian2012-12-302-0/+28
| | | | | | | | | | * Finish adding the HAL capability to announce whether a NIC supports spectral scan or not; * Add spectral scan methods to the HAL structure; * Add HAL_SPECTRAL_PARAM for configuration of the spectral scan logic. The capability ID and HAL_SPECTRAL_PARAM struct are from Qualcomm Atheros.
* Add spectral scan capability.adrian2012-12-301-1/+2
|
* Add the AR9280 and later spectral scan register definitions.adrian2012-12-281-0/+14
| | | | Obtained from: Linux ath9k, Qualcomm Atheros (datasheet)
* Add radar_bin_thresh_sel (bit 24:26), which defines whenadrian2012-12-281-0/+2
| | | | to consider the radar FFT report bins as "strong".
* Note why fast frames is disabled for 802.11n NICs now.adrian2012-12-211-1/+7
| | | | | | It actually works, but net80211 handles A-MPDU and Fast frames incorrectly; it tries enabling both in some instances, with tragic results.
* Add XC900 SKU mapping.adrian2012-12-071-0/+3
|
OpenPOWER on IntegriCloud