summaryrefslogtreecommitdiff
path: root/sys/dev/ath/if_ath.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Convert the callouts back to using mutexes.Adrian Chadd2014-11-151-10/+4
| | | | | | | | | | | I did this wrong - I should've included a state flag for each callout to see if it was supposed to run or not. I didn't do that. Instead, just use mutexes anyway. Suggested by: jhb Notes: svn path=/head/; revision=274535
* Migrate the callouts from using mutex locks to being mpsafe withAdrian Chadd2014-11-141-9/+23
| | | | | | | | | the locks being held by the callers. Kill callout_drain() and use callout_stop(). Notes: svn path=/head/; revision=274493
* Add initial support for the AR9485 CUS198 / CUS230 variants.Adrian Chadd2014-09-301-2/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO.Adrian Chadd2014-09-201-42/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original code was .. well, slightly more than incorrect. It showed up as stalled RX queues if the NIC needed to be frequently reinitialised (eg during scans.) This is inspired by work done by Matt Dillon over at the DragonflyBSD project. So: * track when EDMA RX has been stopped and when the MAC has been reset; * re-initialise the ring only after a reset; * track whether RX has been stopped/started - just for debugging now; * don't bother with the RX EOL stuff for EDMA - we don't need the interrupt at all. We also don't need to disable/enable the interrupt or start DMA - once new frames are pushed into the ring via the normal RX path, it'll just restart RX DMA on its own. Tested: * AR9380, STA mode * AR9380, AP mode * AR9485, STA mode * AR9462, STA mode Notes: svn path=/head/; revision=271887
* Mechanically convert to if_inc_counter().Gleb Smirnoff2014-09-181-6/+8
| | | | Notes: svn path=/head/; revision=271823
* Shut down RX before TX - in theory, this should make the chip less likelyAdrian Chadd2014-08-231-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to get upset. The Qualcomm Atheros reference design code goes through significant hacks to shut down RX before TX. It doesn't even try do do it in the driver - it actually makes the DMA stop routines in the HAL shut down RX before shutting down TX. So, to make this work for chips that aren't the AR9380 and later, do it in the driver. Shuffle the TX stop/drain HAL calls to be called *after* the RX stop HAL call. Tested: * AR5413 (STA) * AR5212 (STA) * AR5416 (STA) * AR9380 (STA) * AR9331 (AP) * AR9341 (AP) TODO: * test ar92xx series NIC and the AR5210/AR5211, in case there's something even odder about those. Notes: svn path=/head/; revision=270430
* an isn't used, so eliminate it.Warner Losh2014-08-081-2/+0
| | | | Notes: svn path=/head/; revision=269714
* Pull in r267961 and r267973 again. Fix for issues reported will follow.Hans Petter Selasky2014-06-281-6/+3
| | | | Notes: svn path=/head/; revision=267992
* Revert r267961, r267973:Glen Barber2014-06-271-3/+6
| | | | | | | | | | | | | These changes prevent sysctl(8) from returning proper output, such as: 1) no output from sysctl(8) 2) erroneously returning ENOMEM with tools like truss(1) or uname(1) truss: can not get etype: Cannot allocate memory Notes: svn path=/head/; revision=267985
* Extend the meaning of the CTLFLAG_TUN flag to automatically check ifHans Petter Selasky2014-06-271-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | there is an environment variable which shall initialize the SYSCTL during early boot. This works for all SYSCTL types both statically and dynamically created ones, except for the SYSCTL NODE type and SYSCTLs which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to be used in the case a tunable sysctl has a custom initialisation function allowing the sysctl to still be marked as a tunable. The kernel SYSCTL API is mostly the same, with a few exceptions for some special operations like iterating childrens of a static/extern SYSCTL node. This operation should probably be made into a factored out common macro, hence some device drivers use this. The reason for changing the SYSCTL API was the need for a SYSCTL parent OID pointer and not only the SYSCTL parent OID list pointer in order to quickly generate the sysctl path. The motivation behind this patch is to avoid parameter loading cludges inside the OFED driver subsystem. Instead of adding special code to the OFED driver subsystem to post-load tunables into dynamically created sysctls, we generalize this in the kernel. Other changes: - Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask" to "hw.pcic.intr_mask". - Removed redundant TUNABLE statements throughout the kernel. - Some minor code rewrites in connection to removing not needed TUNABLE statements. - Added a missing SYSCTL_DECL(). - Wrapped two very long lines. - Avoid malloc()/free() inside sysctl string handling, in case it is called to initialize a sysctl from a tunable, hence malloc()/free() is not ready when sysctls from the sysctl dataset are registered. - Bumped FreeBSD version to indicate SYSCTL API change. MFC after: 2 weeks Sponsored by: Mellanox Technologies Notes: svn path=/head/; revision=267961
* Wake up the hardware before calling ath_mode_init() in the ioctl() path.Adrian Chadd2014-05-051-0/+2
| | | | | | | | | Tested: * AR5416, STA + powersave Notes: svn path=/head/; revision=265370
* Break out the multicast programming into its own hardware specificAdrian Chadd2014-05-051-6/+30
| | | | | | | | | | | | | | | | | | | call, which assumes the hardware is awake. Turn ath_update_mcast() into a routine that's only called from the net80211 layer - and it forces the hardware awake first. This fixes a LOR from the EDMA RX path which calls ath_mode_init() with the RX lock held - the driver lock can't also be grabbed. This path assumes that the ath_mode_init() callers all wake up the NIC first. Tested: * AR9485, STA mode, powersave Notes: svn path=/head/; revision=265350
* Add tracking for self-generated frames when the VAP is in sleep state.Adrian Chadd2014-05-021-10/+100
| | | | | | | | | | | | | | | | | | | | | | The hardware can generate its own frames (eg RTS/CTS exchanges, other kinds of 802.11 management stuff, especially when it comes to 802.11n) and these also have PWRMGT flags. So if the VAP is asleep but the NIC is in force-awake for some reason, ensure that the self-generated frames have PWRMGT set to 1. Now, this (like basically everything to do with powersave) is still racy - the only way to guarantee that it's all actually consistent is to pause transmit and let it finish before transitioning the VAP to sleep, but this at least gets the basic method of tracking and updating the state debugged. Tested: * AR5416, STA mode * AR9380, STA mode Notes: svn path=/head/; revision=265205
* Bring over some initial power save management support, reset pathAdrian Chadd2014-04-301-18/+448
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA Notes: svn path=/head/; revision=265115
* Wrap the rate control re-init code in a lock, to serialise it withAdrian Chadd2014-04-231-0/+2
| | | | | | | | | | | | | | | | | | | concurrent updates from any completing transmits in other threads. This was exposed when doing power save work - net80211 is constantly doing reassociations and it's causing the rate control state to get blanked out. This could cause the rate control code to assert. This should be MFCed to stable/10 as it's a stability fix. Tested: * AR5416, STA MFC after: 7 days Notes: svn path=/head/; revision=264798
* Don't call ath_init() inside the lock.Adrian Chadd2014-03-201-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Yes, this means that sc_invalid is slightly racy, but there are other issues here which need fixing. This fixes a source of eventual LORs - ath_init() grabs ATH_LOCK to do work and releases it before it calls ieee80211_start_all(). ieee80211_start_all() will grab the net80211 comlock to iterate over the VAPs. TODO: * .. I should just migrate the ieee80211_start_all() work to a deferred task so it can be done later; it doesn't have to be immediately done. Tested: * AR5416, STA mode Notes: svn path=/head/; revision=263416
* The r48589 promised to remove implicit inclusion of if_var.h soon. PrepareGleb Smirnoff2013-10-261-0/+1
| | | | | | | | | | | to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=257176
* Move a lot of debugging printf's to DPRINTF.Rui Paulo2013-10-171-3/+4
| | | | | | | | Approved by: adrian MFC after: 2 weeks Notes: svn path=/head/; revision=256658
* Use the new ieee80211_tx_complete() function.Adrian Chadd2013-08-271-11/+2
| | | | Notes: svn path=/head/; revision=254957
* Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.Adrian Chadd2013-06-121-0/+12
| | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=251655
* Bring over the initial static bluetooth coexistence configurationAdrian Chadd2013-06-071-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.) Notes: svn path=/head/; revision=251487
* Implement a bit of a hack to store the AR9285/AR9485 RX LNA configuration inAdrian Chadd2013-06-051-0/+1
| | | | | | | | | | | | | | | | | | | | | the RX antenna field. The AR9285/AR9485 use an LNA mixer to determine how to combine the signals from the two antennas. This is encoded in the RSSI fields (ctl/ext) for chain 2. So, let's use that here. This maps RX antennas 0->3 to the RX mixer configuration used to receive a frame. There's more that can be done but this is good enough to diagnose if the hardware is doing "odd" things like trying to receive frames on LNA2 (ie, antenna 2 or "alt" antenna) when there's only one antenna connected. Tested: * AR9285, STA mode Notes: svn path=/head/; revision=251401
* Fix the order of TX shutdown and reset.Adrian Chadd2013-06-031-4/+25
| | | | | | | | | | | | | | | | | * Grab the reset lock first, so any subsequent interrupt, TX, RX work will fail * Then shut down interrupts * Then wait for TX/RX to finish running At this point no further work will be running, so it's safe to do the reset path code. PR: kern/179232 Notes: svn path=/head/; revision=251342
* Turn the reassociate debug print into a DPRINTF.Adrian Chadd2013-05-291-1/+2
| | | | Notes: svn path=/head/; revision=251099
* Migrate ath(4) to now use if_transmit instead of the legacy if_startAdrian Chadd2013-05-261-211/+237
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure. Notes: svn path=/head/; revision=251014
* Implement a separate hardware queue threshold for aggregate and non-aggrAdrian Chadd2013-05-211-1/+2
| | | | | | | | | | | | | | | | | | | traffic. When transmitting non-aggregate traffic, we need to keep the hardware busy whilst transmitting or small bursts in txdone/tx latency will kill us. This restores non-aggregate iperf performance, especially when doing TDMA. Tested: * AR5416<->AR5416, TDMA * AR5416 STA <-> AR9280 AP Notes: svn path=/head/; revision=250866
* Enable the use of TDMA on an 802.11n channel (with aggregation disabled,Adrian Chadd2013-05-211-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test. Notes: svn path=/head/; revision=250865
* Since we're now using the ah pointer, always declare it.Adrian Chadd2013-05-191-2/+0
| | | | | | | This fixes non-DEBUG builds. Notes: svn path=/head/; revision=250795
* Be (very) careful about how to add more TX DMA work.Adrian Chadd2013-05-181-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode. Notes: svn path=/head/; revision=250783
* Re-add some code to exclude transmitting if we're in reset.Adrian Chadd2013-05-181-0/+19
| | | | | | | | This fixes some "transmitting during reset" bugs that crept in after I messed around with this part of the transmit path. Notes: svn path=/head/; revision=250777
* Dump out the holding buffer descriptor contents and addresses stopping DMA.Adrian Chadd2013-05-161-2/+12
| | | | Notes: svn path=/head/; revision=250703
* Implement my first cut at "correct" node power-save andAdrian Chadd2013-05-151-3/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160 Notes: svn path=/head/; revision=250665
* Add ALQ beacon debugging.Adrian Chadd2013-05-131-0/+5
| | | | Notes: svn path=/head/; revision=250619
* Improve the debugging output - use the MAC address rather than variousAdrian Chadd2013-05-131-17/+40
| | | | | | | pointer values everywhere. Notes: svn path=/head/; revision=250611
* Since the node state is 100% back under the TX lock, just kill the useAdrian Chadd2013-05-131-11/+4
| | | | | | | | | of atomics. I'll re-think this nonsense later. Notes: svn path=/head/; revision=250609
* Begin tidying up the reassociation and node sleep/wakeup paths.Adrian Chadd2013-05-131-22/+37
| | | | | | | | | | | | | | | | | | | | | * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time. Notes: svn path=/head/; revision=250606
* Make sure the holding descriptor and link pointer are both freed duringAdrian Chadd2013-05-101-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | a non-loss reset. When the drain functions are called, the holding descriptor and link pointers are NULLed out. But when the processq function is called during a non-loss reset, this doesn't occur. So the next time a DMA occurs, it's chained to a descriptor that no longer exists and the hardware gets angry. Tested: * AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss reset. TODO: * Further AR9380 testing just to check that the behaviour for the EDMA chips is sane. PR: kern/178477 Notes: svn path=/head/; revision=250444
* Fix the holding descriptor logic to actually be "right" (for valuesAdrian Chadd2013-05-081-8/+51
| | | | | | | | | | | | | | | | | | | | | | | of "right".) Flip back on the "always continue TX DMA using the holding descriptor" code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL. Since the holding descriptor is accessed via txq->axq_link and _that_ is done behind the TXQ lock rather than the TX path lock, the holding descriptor stuff itself needs to be behind the TXQ lock. So, do the mental gymnastics needed to do this. I've not seen any of the hardware failures that I was seeing when I last tried to do this. Tested: * AR5416, STA mode Notes: svn path=/head/; revision=250391
* Revert a previous commit - this is causing hardware errors.Adrian Chadd2013-05-081-14/+13
| | | | | | | | | | | | | I'm not sure why this is failing. The holding descriptor should be being re-read when starting DMA of the next frame. Obviously something here isn't totally correct. I'll review the TX queue handling and see if I can figure out why this is failing. I'll then re-revert this patch out and use the holding descriptor again. Notes: svn path=/head/; revision=250355
* Re-work how transmit buffer limits are enforced - partly to fix the PR,Adrian Chadd2013-05-071-15/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | but partly to just tidy up things. The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out. Now, the problem! * Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set. The solution(s): * De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool. Whilst I'm here: * Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane. This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse. Tested: * AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly. PR: kern/138379 Notes: svn path=/head/; revision=250326
* The holding buffer logic needs to be used for _all_ transmission, notAdrian Chadd2013-05-041-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | just "when the queue is busy." After talking with the MAC team, it turns out that the linked list implementation sometimes will not accept a TxDP update and will instead re-read the link pointer. So even if the hardware has finished transmitting a chain and has hit EOL/VEOL, it may still re-read the link pointer to begin transmitting again. So, always set ATH_BUF_BUSY on the last buffer in the chain (to mark the last descriptor as the holding descriptor) and never blank the axq_link pointer. Tested: * AR5416, STA mode TODO: * much more thorough testing with the pre-11n NICs, just to verify that they behave the same way. * test TDMA on the 11n and non-11n hardware. Notes: svn path=/head/; revision=250229
* Debugging changes!Adrian Chadd2013-04-291-3/+3
| | | | | | | | | | | * That lock isn't actually held during reset - just the whole TX/RX path is paused. So, remove the assertion. * Log the TX queue status - how many hardware frames are active in the MAC and whether the queue is active. Notes: svn path=/head/; revision=250041
* Conditionally compile this only if ATH_DEBUG is defined.Adrian Chadd2013-04-261-0/+4
| | | | Notes: svn path=/head/; revision=249958
* Dump the entire TXQ descriptor contents during a reset, rather than onlyAdrian Chadd2013-04-261-0/+29
| | | | | | | completed descriptors. Notes: svn path=/head/; revision=249957
* Initialise the chainmask fields regardless of whether 11n supportAdrian Chadd2013-04-191-8/+8
| | | | | | | | | | | | is compiled in or not. This fixes issues with people running -HEAD but who build modules without doing a "make buildkernel KERNCONF=XXX", thus picking up opt_*.h. The resulting module wouldn't have 11n enabled and the chainmask configuration would just be plain wrong. Notes: svn path=/head/; revision=249662
* Add a debug statement to log the currently chosen chainmask configuration.Adrian Chadd2013-04-191-0/+6
| | | | Notes: svn path=/head/; revision=249642
* .. don't know how this snuck into this commit. Sorry.Adrian Chadd2013-04-191-1/+0
| | | | | | | Fix compile build before anyone notices. Notes: svn path=/head/; revision=249641
* Print out the chainmask configuration.Adrian Chadd2013-04-191-0/+5
| | | | Notes: svn path=/head/; revision=249640
* Use uint32_t for fields that are fetched via ath_hal_getcapability().Adrian Chadd2013-04-191-1/+1
| | | | Notes: svn path=/head/; revision=249639
* Use a per-RX-queue deferred list, rather than a single deferred list forAdrian Chadd2013-04-161-1/+2
| | | | | | | | | | | | | | both queues. Since ath_rx_pkt() does multi-mbuf frame recombining based on the RX queue, this needs to occur. Tested: * AR9380 (XB112), hostap mode Notes: svn path=/head/; revision=249565
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-10 23:27:34 +0000