aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/ath/ath_hal/ar5416
Commit message (Collapse)AuthorAgeFilesLines
* ath(4): Fix a typo in a device messsageGordon Bergling2025-10-311-1/+1
| | | | | | - s/Orignal/Original/ MFC after: 5 days
* ath: Fix typo (triple M)Jose Luis Duran2024-02-031-1/+1
| | | | | Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/963
* sys: Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-1628-56/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* ath(4): Fix two typos in source code commentsGordon Bergling2022-09-031-2/+2
| | | | | | - s/overriden/overridden/ MFC after: 3 days
* ath(4): Remove a double word in a few source code commentsGordon Bergling2022-04-091-1/+1
| | | | | | - s/for for/for/ MFC after: 3 days
* ath: clean up empty lines in .c and .h filesMateusz Guzik2020-09-0113-37/+19
| | | | Notes: svn path=/head/; revision=365116
* [ath_hal] Add KeyMiss for AR5212/AR5416 series chips.Adrian Chadd2020-06-271-2/+3
| | | | | | | | | | | | | | This is a flag from the MAC that says the received packet didn't match a keycache slot. This isn't technically a problem as WEP keys don't match keycache slots (they're "global" keys), but it could be useful for tracking down CCMP decryption failures. Right now it's a no-op - it mirrors what the AR9300 HAL does and it just increments a counter. But, hey, maybe one day I'll use it for diagnosing keycache/CCMP decrypt issues. Notes: svn path=/head/; revision=362671
* [ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set ↵Adrian Chadd2020-05-253-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it during ath_reset() Although I added the reset type field to ath_hal_reset() years ago, I never finished adding it both throughout the HALs and in if_ath.c. This will eventually deprecate the ath_hal force_full_reset option because it can be requested at the driver layer. So: * Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type * Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset * Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions * Use HAL_RESET_NORMAL in most calls to ath_reset() * .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs. This should be a glorified no-op outside of actual hardware issues. I've tested things with ath_hal force_full_reset set to 1 for years now, so I know that feature and a full reset works (albeit much slower than a warm reset!) and it does unwedge hardware. The eventual aim is to use this for all the places where the driver detects a potential hang as well as if long calibration - ie, noise floor calibration - fails to complete. That's one of the big hardware related things that causes station mode operation to hang without easy recovery. Differential Revision: https://reviews.freebsd.org/D24981 Notes: svn path=/head/; revision=361486
* [ath] [ath_rate] Extend ath_rate_sample to better handle 11n rates and ↵Adrian Chadd2020-05-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | aggregates. My initial rate control code was .. suboptimal. I wanted to at least get MCS rates sent, but it didn't do anywhere near enough to handle low signal level links or remotely keep accurate statistics. So, 8 years later, here's what I should've done back then. * Firstly, I wasn't at all tracking packet sizes other than the two buckets (250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and 65536. I may go add 2048 at some point if I find it's useful. This is important for a few reasons. First, when forming A-MPDU or AMSDU aggregates the frame sizes are larger, and thus the TX time calculation is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels isn't some fixed thing, both due to channel conditions and radios themselves. Notably, there was some observations done a few years ago on 11n chipsets which noticed longer aggregates showed an increase in failed A-MPDU sub-frame reception as you got further along in the transmit time. It could be due to a variety of things - transmitter linearity, channel conditions changing, frequency/phase drift, etc - but the observation was to potentially form shorter aggregates to improve BER. * .. and then modify the ath TX path to report the length of the aggregate sent, so as the statistics kept would line up with the correct bucket. * Then on the rate control look-up side - i was also only using the first frame length for an A-MPDU rate control lookup which isn't good enough here. So, add a new method that walks the TID software queue for that node to find out what the likely length of data available is. It isn't ALL of the data in the queue because we'll only ever send enough data to fit inside the block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr() would do. * .. and cache that in the first ath_buf in the aggregate so it and the eventual AMPDU length can be returned to the rate control code. * THEN, modify the rate control code to look at them both when deciding which bucket to attribute the sent frame on. I'm erring on the side of caution and using the size bucket that the lookup is based on. Ok, so now the rate lookups and statistics are "more correct". However, MCS rates are not the same as 11abg rates in that they're not a monotonically incrementing set of faster rates and you can't assume that just because a given MCS rate fails, the next higher one wouldn't work better or be a lower average tx time. So, I had to do a bunch of surgery to the best rate and sample rate math. This is the bit that's a WIP. * First, simplify the statistics updates (update_stats()) to do a single pass on all rates. * Next, make sure that each rate average tx time is updated based on /its/ failure/success. Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS 12 would have their average tx time updated for /their/ part of the transmission, not the whole transmission. * Next, EWMA wasn't being fully calculated based on the /failures/ in each of the rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure that the statistics noted that /all/ subframes failed at those rates, rather than the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average TX time are updated correctly. * When picking a sample rate and initial rate, probe rates aroud the current MCS but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at MCS8 then don't probe MCS7 as part of it, it's not likely to succeed. * Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and .. then each comparison would accept the higher rate. Just skip those; sampling will fill in the details. So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of instability around higher MCS rates because there are bursts of loss/retransmissions that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks. Ok, so why this still something I'm poking at? rather than porting minstrel_ht? ath_rate_sample tries to minimise airtime, not maximise throughput. I have extended it with an EWMA based on sub-frame success/failures - high MCS rates that have partially successful receptions still show super short average frame times, but a /lot/ of retransmits have to happen for that to work. So for MCS rates I also track this EWMA and ensure that the rates I'm choosing don't have super crappy packet failures. I don't mind not getting lower peak throughput versus minstrel_ht; instead I want to see if I can make "minimise airtime" work well. Tested: * AR9380, STA mode * AR9344, STA mode * AR9580, STA/AP mode Notes: svn path=/head/; revision=361085
* [ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle ↵Adrian Chadd2019-04-212-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | resetting ANI. One of the fun issues with scanning has been how the existing ANI values were programmed into the hardware when channels were changed. If you're on a really crappy channel and ANI has made you deaf then when you scan you continue to be deaf on all channels. This code passes in a flag to startpcureceive which in AR5416 and later is also used to enable ANI. This allows it to know if it's a normal operation or a scan operation. This fixes my situation at home where a temporary spot of a device going deaf due to interference starts scanning and .. can't hear anything until I restart. Now, this isn't the full fix - ideally: (a) all the ANI config and per-channel information would be migrated to the shared HAL stuff and enabled for all of the NICs; (b) when a station reassociates and some other error conditions (like missed beacons, NF calibration failures, etc) a knob to reset ANI parameters would likely help recovery. But hey, I'm committing bits of code again! woo! Tested: * AR9344 (2G), STA operation Notes: svn path=/head/; revision=346470
* [ath_hal] Return failure if noise floor calibration fails.Adrian Chadd2018-06-081-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | If we fail noise floor calibration then we may end up with a deaf NIC which we can't recover without a full chip reset. Earlier chips seem to get less stuck in this condition versus AR9280/later and AR9300/later, but whilst here just fix up the AR5212 era chips to also return NF calibration failures. This HAL routine would only return failure if the channel was not configured. This is a no-op until the driver side code for doing resets and the HAL code for being told about the reset type (and then handling it!) is implemented. Tested: * AR9280, STA mode * AR2425, STA mode * AR9380, STA mode Notes: svn path=/head/; revision=334849
* [ath_hal] Don't do ANI processing if we've reset.Adrian Chadd2018-06-081-0/+3
| | | | | | | | | | | | If we've reset then we can't trust the current state of the ANI tracking, so just wait until next time. Tested: * AR5424, STA mode (2GHz) Notes: svn path=/head/; revision=334848
* [ath_hal] migrate the shared HAL_RESET_* pieces out into ath_hal.Adrian Chadd2018-05-251-6/+0
| | | | | | | | | I'm in the process of reworking how the reset path works with an eye to better recovery when the chips hang and/or go RF/PHY deaf. This is the first step in a lot of unification and API changes. Notes: svn path=/head/; revision=334197
* SPDX: license IDs for some ISC-related files.Pedro F. Giffuni2017-12-0827-27/+81
| | | | Notes: svn path=/head/; revision=326695
* [ath_hal] fixes for finer grain timestamping, some 11n macrosAdrian Chadd2016-09-091-0/+3
| | | | | | | | | | | | | | | | * change the HT_RC_2_MCS to do MCS0..23 * Use it when looking up the ht20/ht40 array for bits-per-symbol * add a clk_to_psec (picoseconds) routine, so we can get sub-microsecond accuracy for the math * .. and make that + clk_to_usec public, so higher layer code that is returning clocks (eg the ANI diag routines, some upcoming locationing experiments) can be converted to microseconds. Whilst here, add a comment in ar5416 so i or someone else can revisit the latency values. Notes: svn path=/head/; revision=305637
* sys/dev: replace comma with semicolon when pertinent.Pedro F. Giffuni2016-08-091-2/+2
| | | | | | | | | | | | | Uses of commas instead of a semicolons can easily go undetected. The comma can serve as a statement separator but this shouldn't be abused when statements are meant to be standalone. Detected with devel/coccinelle following a hint from DragonFlyBSD. MFC after: 1 month Notes: svn path=/head/; revision=303891
* [ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.Adrian Chadd2016-07-081-3/+2
| | | | | | | | | * the code already stored the length of the RX desc, which I never used. So, use that and retire the new flag I introduced a while ago. * Introduce a TX timestamp length field and capability. Notes: svn path=/head/; revision=302461
* [ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.Adrian Chadd2016-06-041-0/+4
| | | | | | | It just stomps all; which is enough for some testing. Notes: svn path=/head/; revision=301304
* [ath_hal] add support for setting the azimuth timestamp in the outgoing TX ↵Adrian Chadd2016-05-311-0/+6
| | | | | | | | | payload. FYI: This is an unsupported/deprecated feature of the 11n hardware. Notes: svn path=/head/; revision=301042
* dev/ath: minor spelling fixes in comments.Pedro F. Giffuni2016-05-025-8/+8
| | | | | | | | | No functional change. Reviewed by: adrian Notes: svn path=/head/; revision=298939
* Cleanup unnecessary semicolons from the kernel.Pedro F. Giffuni2016-04-101-1/+1
| | | | | | | Found with devel/coccinelle. Notes: svn path=/head/; revision=297793
* Fix kernel build, broken in r290612Renato Botelho2015-11-091-1/+1
| | | | | | | Approved by: adrian Notes: svn path=/head/; revision=290616
* ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.Adrian Chadd2015-11-092-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path. Notes: svn path=/head/; revision=290612
* Flip on fast frames support for AR5416 and AR9300 series NICs.Adrian Chadd2015-10-101-7/+1
| | | | | | | | | | | | | | | | | | | | | | This was off because the net80211 aggregation code was using the same state pointers for both fast frames and ampdu tx support which led to some pretty unfortunate panic-y behaviour. Now that net80211 doesn't panic, let's flip this back on. It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates of fast frames; that'll come next. It's a pre-requisite to supporting AMSDU + AMPDU anyway, which actually speeds things up quite considerably (think packing lots of little ACK frames into a single AMSDU.) Tested: * QCA955x SoC, AP mode * AR5416, STA mode * AR9170, STA mode (with local fast frame patches) Notes: svn path=/head/; revision=289099
* Move the HAL channel survey support out to be in the top-level HAL,Adrian Chadd2015-03-292-12/+4
| | | | | | | | | | | | | | | rathe than private in each HAL module. Whilst here, modify ath_hal_private to always have the per-channel noisefloor stats, rather than conditionally. This just makes life easier in general (no strange ABI differences between different HAL compile options.) Add a couple of methods (clear/reset, add) rather than using hand-rolled versions of things. Notes: svn path=/head/; revision=280828
* Oops; correctly reload the CCA registers with the uncapped valueAdrian Chadd2015-01-171-1/+2
| | | | | | | | | | | | in prep for the next NF calibration pass. Totally missing braces. Damn you C. Submitted by: Sascha Wildner <swildner@dragonflybsd.org> MFC after: 1 week Notes: svn path=/head/; revision=277290
* Add initial support for the AR9485 CUS198 / CUS230 variants.Adrian Chadd2014-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These variants have a few differences from the default AR9485 NIC, namely: * a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity. To make this possible: * Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC. This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf. Tested: * AR9380 (STA) * AR9485 CUS198 (STA) Obtained from: Qualcomm Atheros, Linux ath9k Notes: svn path=/head/; revision=272292
* * Only update ah_powerMode if we're setting the chip sleep state.Adrian Chadd2014-04-301-3/+9
| | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=265112
* Note that the AR5416 and later hardware supports the MYBEACON RX filter.Adrian Chadd2014-04-271-0/+5
| | | | Notes: svn path=/head/; revision=265033
* Program the AR_TSFOOR_THRESHOLD register with a default lifted fromAdrian Chadd2014-04-271-0/+26
| | | | | | | | | | | | | | | the QCA HAL. This fires off an interrupt if the TSF from the AP / IBSS peer is wildly out of range. I'll add some code to the ath(4) driver soon which makes use of this. TODO: * verify this didn't break TDMA! Notes: svn path=/head/; revision=265031
* Fix the AR_SLEEP1 and AR_SLEEP2 definitions. Oops!Adrian Chadd2014-04-271-2/+2
| | | | | | | | | | | | Tested: * AR9285, STA * AR5416, STA Obtained from: QCA, Linux ath9k Notes: svn path=/head/; revision=265030
* Do a read-after-write to ensure the interrupt register update is flushedAdrian Chadd2014-04-271-0/+3
| | | | | | | | | | | | to the hardware. The QCA HAL has a comment noting that if this isn't done, modifications to AR_IMR_S2 before AR_IMR is flushed may produce spurious interrupts. Obtained from: QCA Notes: svn path=/head/; revision=265029
* Shuffle ah_powerMode to be in a sane spot for the given power operation.Adrian Chadd2014-03-201-1/+3
| | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=263417
* Migrate the chip power mode status to public ath_hal, rather than theAdrian Chadd2014-03-101-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=262969
* Add bluetooth fixes to the AR5416/AR92xx HAL:Adrian Chadd2013-06-073-1/+12
| | | | | | | | | | | | | | | | * 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. Notes: svn path=/head/; revision=251483
* Fix receive on the AR9285 (Kite) with only one antenna connected.Adrian Chadd2013-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 Notes: svn path=/head/; revision=251340
* Fix build break - the SetCapability calls return HAL_BOOL,Adrian Chadd2013-05-211-1/+1
| | | | | | | not HAL_STATUS. Notes: svn path=/head/; revision=250856
* Extend the TXOP enforce capability to support checking whether it'sAdrian Chadd2013-05-211-0/+6
| | | | | | | supported. Notes: svn path=/head/; revision=250841
* Implement STBC receive frame statistics.Adrian Chadd2013-05-082-0/+9
| | | | | | | | | | The AR9280 and later can receive STBC. This adds some statistics tracking to count these frames. A patch to athstats will be forthcoming. Notes: svn path=/head/; revision=250346
* Setup needed tables for TPC on AR5416->AR9287 chips.Adrian Chadd2013-04-173-31/+270
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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. Notes: svn path=/head/; revision=249580
* Now that the register definitions are in -HEAD, enable this.Adrian Chadd2013-04-151-8/+8
| | | | Notes: svn path=/head/; revision=249517
* Bring over some AR9271 register definitions from the QCA HAL.Adrian Chadd2013-04-151-0/+19
| | | | | | | Obtained from: Qualcomm Atheros Notes: svn path=/head/; revision=249516
* CABQ calculation changes to try and fix some weird corner cases leadingAdrian Chadd2013-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 Notes: svn path=/head/; revision=248670
* Add another register definition bit - whether to populate EVM or PLCPAdrian Chadd2013-03-101-0/+1
| | | | | | | | | data in the RX status descriptor. Obtained from: Qualcomm Atheros Notes: svn path=/head/; revision=248129
* add a method to set/clear the VMF field in the TX descriptor.Adrian Chadd2013-03-043-1/+14
| | | | | | | Obtained from: Qualcomm Atheros Notes: svn path=/head/; revision=247774
* Part #2 of the TX chainmask changes:Adrian Chadd2013-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 Notes: svn path=/head/; revision=247287
* Begin adding support to explicitly set the current chainmask.Adrian Chadd2013-02-253-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=247286
* Add a workaround for AR5416, AR9130 and AR9160 chipsets - work aroundAdrian Chadd2013-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 Notes: svn path=/head/; revision=247145
* Be slightly more paranoid with the TX DMA buffer maximum threshold.Adrian Chadd2013-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 Notes: svn path=/head/; revision=247092
* Remove this unneeded printf(), sorry!Adrian Chadd2013-02-211-4/+0
| | | | Notes: svn path=/head/; revision=247073
generated by cgit v1.3 (git 2.53.0) at 2026-09-05 20:11:12 +0000