d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c4bab9e7ae
freebsd-dev/sys/dev/ath/if_ath_tx_edma.c

867 lines
22 KiB
C
Raw Normal View History

Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
/*-
* Copyright (c) 2012 Adrian Chadd <adrian@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
* redistribution must be conditioned upon including a substantially
* similar Disclaimer requirement for further binary redistribution.
*
* NO WARRANTY
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGES.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
/*
* Driver for the Atheros Wireless LAN controller.
*
* This software is derived from work of Atsushi Onoe; his contribution
* is greatly appreciated.
*/
#include "opt_inet.h"
#include "opt_ath.h"
/*
* This is needed for register operations which are performed
* by the driver - eg, calls to ath_hal_gettsf32().
*
* It's also required for any AH_DEBUG checks in here, eg the
* module dependencies.
*/
#include "opt_ah.h"
#include "opt_wlan.h"
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/sysctl.h>
#include <sys/mbuf.h>
#include <sys/malloc.h>
#include <sys/lock.h>
#include <sys/mutex.h>
#include <sys/kernel.h>
#include <sys/socket.h>
#include <sys/sockio.h>
#include <sys/errno.h>
#include <sys/callout.h>
#include <sys/bus.h>
#include <sys/endian.h>
#include <sys/kthread.h>
#include <sys/taskqueue.h>
#include <sys/priv.h>
#include <sys/module.h>
#include <sys/ktr.h>
#include <sys/smp.h> /* for mp_ncpus */
#include <machine/bus.h>
#include <net/if.h>
#include <net/if_dl.h>
#include <net/if_media.h>
#include <net/if_types.h>
#include <net/if_arp.h>
#include <net/ethernet.h>
#include <net/if_llc.h>
#include <net80211/ieee80211_var.h>
#include <net80211/ieee80211_regdomain.h>
#ifdef IEEE80211_SUPPORT_SUPERG
#include <net80211/ieee80211_superg.h>
#endif
#ifdef IEEE80211_SUPPORT_TDMA
#include <net80211/ieee80211_tdma.h>
#endif
#include <net/bpf.h>
#ifdef INET
#include <netinet/in.h>
#include <netinet/if_ether.h>
#endif
#include <dev/ath/if_athvar.h>
#include <dev/ath/ath_hal/ah_devid.h> /* XXX for softled */
#include <dev/ath/ath_hal/ah_diagcodes.h>
#include <dev/ath/if_ath_debug.h>
#include <dev/ath/if_ath_misc.h>
#include <dev/ath/if_ath_tsf.h>
#include <dev/ath/if_ath_tx.h>
#include <dev/ath/if_ath_sysctl.h>
#include <dev/ath/if_ath_led.h>
#include <dev/ath/if_ath_keycache.h>
#include <dev/ath/if_ath_rx.h>
#include <dev/ath/if_ath_beacon.h>
#include <dev/ath/if_athdfs.h>
#ifdef ATH_TX99_DIAG
#include <dev/ath/ath_tx99/ath_tx99.h>
#endif
#include <dev/ath/if_ath_tx_edma.h>
Add some hooks into the driver to attach, detach and record EDMA descriptor events. This is primarily for the TX EDMA and TX EDMA completion. I haven't yet tied it into the EDMA RX path or the legacy TX/RX path. Things that I don't quite like: * Make the pointer type 'void' in ath_softc and have if_ath_alq*() return a malloc'ed buffer. That would remove the need to include if_ath_alq.h in if_athvar.h. * The sysctl setup needs to be cleaned up.
2012-11-08 18:11:31 +00:00
#ifdef ATH_DEBUG_ALQ
#include <dev/ath/if_ath_alq.h>
#endif
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
/*
* some general macros
Allocate a descriptor ring for EDMA TX completion status. Configure the hardware with said ring physical address and size.
2012-07-27 10:41:54 +00:00
*/
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
#define INCR(_l, _sz) (_l) ++; (_l) &= ((_sz) - 1)
#define DECR(_l, _sz) (_l) --; (_l) &= ((_sz) - 1)
Allocate a descriptor ring for EDMA TX completion status. Configure the hardware with said ring physical address and size.
2012-07-27 10:41:54 +00:00
/*
* XXX doesn't belong here, and should be tunable
*/
#define ATH_TXSTATUS_RING_SIZE 512
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
MALLOC_DECLARE(M_ATHDEV);
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
static void ath_edma_tx_processq(struct ath_softc *sc, int dosched);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/*
* Push some frames into the TX FIFO if we have space.
*/
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
static void
ath_edma_tx_fifo_fill(struct ath_softc *sc, struct ath_txq *txq)
{
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
struct ath_buf *bf, *bf_last;
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
int i = 0;
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK_ASSERT(txq);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
DPRINTF(sc, ATH_DEBUG_TX_PROC, "%s: Q%d: called\n",
__func__,
txq->axq_qnum);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
TAILQ_FOREACH(bf, &txq->axq_q, bf_list) {
if (txq->axq_fifo_depth >= HAL_TXFIFO_DEPTH)
break;
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/*
* We have space in the FIFO - so let's push a frame
* into it.
*/
/*
* Remove it from the normal list
*/
ATH_TXQ_REMOVE(txq, bf, bf_list);
/*
* XXX for now, we only dequeue a frame at a time, so
* that's only one buffer. Later on when we just
* push this staging _list_ into the queue, we'll
* set bf_last to the end pointer in the list.
*/
bf_last = bf;
DPRINTF(sc, ATH_DEBUG_TX_PROC,
"%s: Q%d: depth=%d; pushing %p->%p\n",
__func__,
txq->axq_qnum,
txq->axq_fifo_depth,
bf,
bf_last);
/*
* Append it to the FIFO staging list
*/
ATH_TXQ_INSERT_TAIL(&txq->fifo, bf, bf_list);
/*
* Set fifo start / fifo end flags appropriately
*
*/
bf->bf_flags |= ATH_BUF_FIFOPTR;
bf_last->bf_flags |= ATH_BUF_FIFOEND;
/*
* Push _into_ the FIFO.
*/
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
ath_hal_puttxbuf(sc->sc_ah, txq->axq_qnum, bf->bf_daddr);
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
#ifdef ATH_DEBUG
if (sc->sc_debug & ATH_DEBUG_XMIT_DESC)
ath_printtxbuf(sc, bf, txq->axq_qnum, i, 0);
Add some hooks into the driver to attach, detach and record EDMA descriptor events. This is primarily for the TX EDMA and TX EDMA completion. I haven't yet tied it into the EDMA RX path or the legacy TX/RX path. Things that I don't quite like: * Make the pointer type 'void' in ath_softc and have if_ath_alq*() return a malloc'ed buffer. That would remove the need to include if_ath_alq.h in if_athvar.h. * The sysctl setup needs to be cleaned up.
2012-11-08 18:11:31 +00:00
#endif/* ATH_DEBUG */
#ifdef ATH_DEBUG_ALQ
if (if_ath_alq_checkdebug(&sc->sc_alq, ATH_ALQ_EDMA_TXDESC))
* Remove a duplicate TX ALQ post routine! * For CABQ traffic, I -can- chain them together using the next pointer and just push that particular chain head to the CABQ. However, this doesn't magically make EDMA TX CABQ work - I have to do some further hoop jumping.
2012-11-16 19:58:15 +00:00
ath_tx_alq_post(sc, bf);
Add some hooks into the driver to attach, detach and record EDMA descriptor events. This is primarily for the TX EDMA and TX EDMA completion. I haven't yet tied it into the EDMA RX path or the legacy TX/RX path. Things that I don't quite like: * Make the pointer type 'void' in ath_softc and have if_ath_alq*() return a malloc'ed buffer. That would remove the need to include if_ath_alq.h in if_athvar.h. * The sysctl setup needs to be cleaned up.
2012-11-08 18:11:31 +00:00
#endif /* ATH_DEBUG_ALQ */
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
txq->axq_fifo_depth++;
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
i++;
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
}
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
if (i > 0)
ath_hal_txstart(sc->sc_ah, txq->axq_qnum);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
}
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
/*
* Re-initialise the DMA FIFO with the current contents of
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
* said TXQ.
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
*
* This should only be called as part of the chip reset path, as it
* assumes the FIFO is currently empty.
*/
static void
ath_edma_dma_restart(struct ath_softc *sc, struct ath_txq *txq)
{
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
struct ath_buf *bf;
int i = 0;
int fifostart = 1;
int old_fifo_depth;
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: Q%d: called\n",
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
__func__,
txq->axq_qnum);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK_ASSERT(txq);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/*
* Let's log if the tracked FIFO depth doesn't match
* what we actually push in.
*/
old_fifo_depth = txq->axq_fifo_depth;
txq->axq_fifo_depth = 0;
/*
* Walk the FIFO staging list, looking for "head" entries.
* Since we may have a partially completed list of frames,
* we push the first frame we see into the FIFO and re-mark
* it as the head entry. We then skip entries until we see
* FIFO end, at which point we get ready to push another
* entry into the FIFO.
*/
TAILQ_FOREACH(bf, &txq->fifo.axq_q, bf_list) {
/*
* If we're looking for FIFOEND and we haven't found
* it, skip.
*
* If we're looking for FIFOEND and we've found it,
* reset for another descriptor.
*/
#ifdef ATH_DEBUG
if (sc->sc_debug & ATH_DEBUG_XMIT_DESC)
ath_printtxbuf(sc, bf, txq->axq_qnum, i, 0);
#endif/* ATH_DEBUG */
#ifdef ATH_DEBUG_ALQ
if (if_ath_alq_checkdebug(&sc->sc_alq, ATH_ALQ_EDMA_TXDESC))
ath_tx_alq_post(sc, bf);
#endif /* ATH_DEBUG_ALQ */
if (fifostart == 0) {
if (bf->bf_flags & ATH_BUF_FIFOEND)
fifostart = 1;
continue;
}
/* Make sure we're not overflowing the FIFO! */
if (txq->axq_fifo_depth >= HAL_TXFIFO_DEPTH) {
device_printf(sc->sc_dev,
"%s: Q%d: more frames in the queue; FIFO depth=%d?!\n",
__func__,
txq->axq_qnum,
txq->axq_fifo_depth);
}
#if 0
DPRINTF(sc, ATH_DEBUG_RESET,
"%s: Q%d: depth=%d: pushing bf=%p; start=%d, end=%d\n",
__func__,
txq->axq_qnum,
txq->axq_fifo_depth,
bf,
!! (bf->bf_flags & ATH_BUF_FIFOPTR),
!! (bf->bf_flags & ATH_BUF_FIFOEND));
#endif
/*
* Set this to be the first buffer in the FIFO
* list - even if it's also the last buffer in
* a FIFO list!
*/
bf->bf_flags |= ATH_BUF_FIFOPTR;
/* Push it into the FIFO and bump the FIFO count */
ath_hal_puttxbuf(sc->sc_ah, txq->axq_qnum, bf->bf_daddr);
txq->axq_fifo_depth++;
/*
* If this isn't the last entry either, let's
* clear fifostart so we continue looking for
* said last entry.
*/
if (! (bf->bf_flags & ATH_BUF_FIFOEND))
fifostart = 0;
i++;
}
/* Only bother starting the queue if there's something in it */
if (i > 0)
ath_hal_txstart(sc->sc_ah, txq->axq_qnum);
DPRINTF(sc, ATH_DEBUG_RESET, "%s: Q%d: FIFO depth was %d, is %d\n",
__func__,
txq->axq_qnum,
old_fifo_depth,
txq->axq_fifo_depth);
/* And now, let's check! */
if (txq->axq_fifo_depth != old_fifo_depth) {
device_printf(sc->sc_dev,
"%s: Q%d: FIFO depth should be %d, is %d\n",
__func__,
txq->axq_qnum,
old_fifo_depth,
txq->axq_fifo_depth);
}
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
}
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
/*
* Hand off this frame to a hardware queue.
*
* Things are a bit hairy in the EDMA world. The TX FIFO is only
* 8 entries deep, so we need to keep track of exactly what we've
* pushed into the FIFO and what's just sitting in the TX queue,
* waiting to go out.
*
* So this is split into two halves - frames get appended to the
* TXQ; then a scheduler is called to push some frames into the
* actual TX FIFO.
*/
static void
ath_edma_xmit_handoff_hw(struct ath_softc *sc, struct ath_txq *txq,
struct ath_buf *bf)
{
Fix the locking changes due to the TXQ change drive-by. Tested: * AR9580, STA mode
2013-03-24 04:09:29 +00:00
ATH_TXQ_LOCK(txq);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
KASSERT((bf->bf_flags & ATH_BUF_BUSY) == 0,
("%s: busy status 0x%x", __func__, bf->bf_flags));
/*
* XXX TODO: write a hard-coded check to ensure that
* the queue id in the TX descriptor matches txq->axq_qnum.
*/
/* Update aggr stats */
if (bf->bf_state.bfs_aggr)
txq->axq_aggr_depth++;
/* Push and update frame stats */
ATH_TXQ_INSERT_TAIL(txq, bf, bf_list);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/* For now, set the link pointer in the last descriptor
* to be NULL.
*
* Later on, when it comes time to handling multiple descriptors
* in one FIFO push, we can link descriptors together this way.
*/
/*
* Finally, call the FIFO schedule routine to schedule some
* frames to the FIFO.
*/
ath_edma_tx_fifo_fill(sc, txq);
Fix the locking changes due to the TXQ change drive-by. Tested: * AR9580, STA mode
2013-03-24 04:09:29 +00:00
ATH_TXQ_UNLOCK(txq);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
}
/*
* Hand off this frame to a multicast software queue.
*
* Remove a duplicate TX ALQ post routine! * For CABQ traffic, I -can- chain them together using the next pointer and just push that particular chain head to the CABQ. However, this doesn't magically make EDMA TX CABQ work - I have to do some further hoop jumping.
2012-11-16 19:58:15 +00:00
* The EDMA TX CABQ will get a list of chained frames, chained
* together using the next pointer. The single head of that
* particular queue is pushed to the hardware CABQ.
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
*/
static void
ath_edma_xmit_handoff_mcast(struct ath_softc *sc, struct ath_txq *txq,
struct ath_buf *bf)
{
Convert the EDMA multicast queue code over to use the HAL method to set the descriptor link pointer, rather than directly. This is needed on AR9380 and later (ie, EDMA) NICs so the multicast queue has a chance in hell of being put together right. Tested: * AR9380, AR9580 in hostap mode, CABQ traffic (but with other patches..)
2013-03-26 04:48:58 +00:00
ATH_TX_LOCK_ASSERT(sc);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
KASSERT((bf->bf_flags & ATH_BUF_BUSY) == 0,
("%s: busy status 0x%x", __func__, bf->bf_flags));
Fix the locking changes due to the TXQ change drive-by. Tested: * AR9580, STA mode
2013-03-24 04:09:29 +00:00
ATH_TXQ_LOCK(txq);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
/*
* XXX this is mostly duplicated in ath_tx_handoff_mcast().
*/
Convert the EDMA multicast queue code over to use the HAL method to set the descriptor link pointer, rather than directly. This is needed on AR9380 and later (ie, EDMA) NICs so the multicast queue has a chance in hell of being put together right. Tested: * AR9380, AR9580 in hostap mode, CABQ traffic (but with other patches..)
2013-03-26 04:48:58 +00:00
if (ATH_TXQ_LAST(txq, axq_q_s) != NULL) {
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
struct ath_buf *bf_last = ATH_TXQ_LAST(txq, axq_q_s);
struct ieee80211_frame *wh;
/* mark previous frame */
wh = mtod(bf_last->bf_m, struct ieee80211_frame *);
wh->i_fc[1] |= IEEE80211_FC1_MORE_DATA;
/* sync descriptor to memory */
bus_dmamap_sync(sc->sc_dmat, bf_last->bf_dmamap,
BUS_DMASYNC_PREWRITE);
Fix the EDMA CABQ handling - for now, the CABQ takes a descriptor chain like the legacy chips expect.
2013-03-20 05:44:03 +00:00
/* link descriptor */
Convert the EDMA multicast queue code over to use the HAL method to set the descriptor link pointer, rather than directly. This is needed on AR9380 and later (ie, EDMA) NICs so the multicast queue has a chance in hell of being put together right. Tested: * AR9380, AR9580 in hostap mode, CABQ traffic (but with other patches..)
2013-03-26 04:48:58 +00:00
ath_hal_settxdesclink(sc->sc_ah,
bf_last->bf_lastds,
bf->bf_daddr);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
}
* Remove a duplicate TX ALQ post routine! * For CABQ traffic, I -can- chain them together using the next pointer and just push that particular chain head to the CABQ. However, this doesn't magically make EDMA TX CABQ work - I have to do some further hoop jumping.
2012-11-16 19:58:15 +00:00
#ifdef ATH_DEBUG_ALQ
if (if_ath_alq_checkdebug(&sc->sc_alq, ATH_ALQ_EDMA_TXDESC))
ath_tx_alq_post(sc, bf);
#endif /* ATH_DEBUG_ALQ */
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
ATH_TXQ_INSERT_TAIL(txq, bf, bf_list);
Fix the locking changes due to the TXQ change drive-by. Tested: * AR9580, STA mode
2013-03-24 04:09:29 +00:00
ATH_TXQ_UNLOCK(txq);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
}
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
/*
* Handoff this frame to the hardware.
*
* For the multicast queue, this will treat it as a software queue
* and append it to the list, after updating the MORE_DATA flag
* in the previous frame. The cabq processing code will ensure
* that the queue contents gets transferred over.
*
* For the hardware queues, this will queue a frame to the queue
* like before, then populate the FIFO from that. Since the
* EDMA hardware has 8 FIFO slots per TXQ, this ensures that
* frames such as management frames don't get prematurely dropped.
*
* This does imply that a similar flush-hwq-to-fifoq method will
* need to be called from the processq function, before the
* per-node software scheduler is called.
*/
static void
ath_edma_xmit_handoff(struct ath_softc *sc, struct ath_txq *txq,
struct ath_buf *bf)
{
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
DPRINTF(sc, ATH_DEBUG_XMIT_DESC,
"%s: called; bf=%p, txq=%p, qnum=%d\n",
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
__func__,
bf,
txq,
txq->axq_qnum);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
if (txq->axq_qnum == ATH_TXQ_SWQ)
ath_edma_xmit_handoff_mcast(sc, txq, bf);
else
ath_edma_xmit_handoff_hw(sc, txq, bf);
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
}
Flesh out the initial TX FIFO storage for each hardware TX queue.
2012-07-28 04:42:05 +00:00
static int
ath_edma_setup_txfifo(struct ath_softc *sc, int qnum)
{
struct ath_tx_edma_fifo *te = &sc->sc_txedma[qnum];
te->m_fifo = malloc(sizeof(struct ath_buf *) * HAL_TXFIFO_DEPTH,
M_ATHDEV,
M_NOWAIT | M_ZERO);
if (te->m_fifo == NULL) {
device_printf(sc->sc_dev, "%s: malloc failed\n",
__func__);
return (-ENOMEM);
}
/*
* Set initial "empty" state.
*/
te->m_fifo_head = te->m_fifo_tail = te->m_fifo_depth = 0;
return (0);
}
static int
ath_edma_free_txfifo(struct ath_softc *sc, int qnum)
{
struct ath_tx_edma_fifo *te = &sc->sc_txedma[qnum];
/* XXX TODO: actually deref the ath_buf entries? */
free(te->m_fifo, M_ATHDEV);
return (0);
}
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
static int
ath_edma_dma_txsetup(struct ath_softc *sc)
{
Allocate a descriptor ring for EDMA TX completion status. Configure the hardware with said ring physical address and size.
2012-07-27 10:41:54 +00:00
int error;
Flesh out the initial TX FIFO storage for each hardware TX queue.
2012-07-28 04:42:05 +00:00
int i;
Allocate a descriptor ring for EDMA TX completion status. Configure the hardware with said ring physical address and size.
2012-07-27 10:41:54 +00:00
error = ath_descdma_alloc_desc(sc, &sc->sc_txsdma,
NULL, "txcomp", sc->sc_tx_statuslen, ATH_TXSTATUS_RING_SIZE);
if (error != 0)
return (error);
ath_hal_setuptxstatusring(sc->sc_ah,
(void *) sc->sc_txsdma.dd_desc,
sc->sc_txsdma.dd_desc_paddr,
ATH_TXSTATUS_RING_SIZE);
Flesh out the initial TX FIFO storage for each hardware TX queue.
2012-07-28 04:42:05 +00:00
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
ath_edma_setup_txfifo(sc, i);
}
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
return (0);
}
static int
ath_edma_dma_txteardown(struct ath_softc *sc)
{
Flesh out the initial TX FIFO storage for each hardware TX queue.
2012-07-28 04:42:05 +00:00
int i;
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
ath_edma_free_txfifo(sc, i);
}
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
Allocate a descriptor ring for EDMA TX completion status. Configure the hardware with said ring physical address and size.
2012-07-27 10:41:54 +00:00
ath_descdma_cleanup(sc, &sc->sc_txsdma, NULL);
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
return (0);
}
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
/*
Break out ath_draintxq() into a method and un-methodize ath_tx_processq(). Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
2012-08-12 00:37:29 +00:00
* Drain all TXQs, potentially after completing the existing completed
* frames.
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
*/
Break out ath_draintxq() into a method and un-methodize ath_tx_processq(). Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
2012-08-12 00:37:29 +00:00
static void
ath_edma_tx_drain(struct ath_softc *sc, ATH_RESET_TYPE reset_type)
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
{
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
struct ifnet *ifp = sc->sc_ifp;
int i;
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
DPRINTF(sc, ATH_DEBUG_RESET, "%s: called\n", __func__);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
(void) ath_stoptxdma(sc);
/*
* If reset type is noloss, the TX FIFO needs to be serviced
* and those frames need to be handled.
*
* Otherwise, just toss everything in each TX queue.
*/
Oops, fix bogus spacing.
2012-11-08 17:46:27 +00:00
if (reset_type == ATH_RESET_NOLOSS) {
ath_edma_tx_processq(sc, 0);
} else {
for (i = 0; i < HAL_NUM_TX_QUEUES; i++) {
if (ATH_TXQ_SETUP(sc, i))
ath_tx_draintxq(sc, &sc->sc_txq[i]);
}
}
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
/* XXX dump out the TX completion FIFO contents */
/* XXX dump out the frames */
IF_LOCK(&ifp->if_snd);
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
IF_UNLOCK(&ifp->if_snd);
sc->sc_wd_timer = 0;
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
}
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
/*
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
* TX completion tasklet.
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
*/
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
static void
ath_edma_tx_proc(void *arg, int npending)
{
struct ath_softc *sc = (struct ath_softc *) arg;
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
#if 0
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
DPRINTF(sc, ATH_DEBUG_TX_PROC, "%s: called, npending=%d\n",
__func__, npending);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
#endif
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
ath_edma_tx_processq(sc, 1);
}
/*
* Process the TX status queue.
*/
static void
ath_edma_tx_processq(struct ath_softc *sc, int dosched)
{
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
struct ath_hal *ah = sc->sc_ah;
HAL_STATUS status;
struct ath_tx_status ts;
struct ath_txq *txq;
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
struct ath_buf *bf;
struct ieee80211_node *ni;
Initialise an uninitialised variable. GCC on -9 didn't pick this up; clang did. Submitted by: David Wolfskill
2012-08-21 16:44:25 +00:00
int nacked = 0;
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
int idx;
#ifdef ATH_DEBUG
/* XXX */
uint32_t txstatus[32];
#endif
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
for (idx = 0; ; idx++) {
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
bzero(&ts, sizeof(ts));
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
ATH_TXSTATUS_LOCK(sc);
Oops - conditionalise that.
2012-11-04 00:46:01 +00:00
#ifdef ATH_DEBUG
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
ath_hal_gettxrawtxdesc(ah, txstatus);
Oops - conditionalise that.
2012-11-04 00:46:01 +00:00
#endif
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
status = ath_hal_txprocdesc(ah, NULL, (void *) &ts);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
ATH_TXSTATUS_UNLOCK(sc);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
if (status == HAL_EINPROGRESS)
break;
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
#ifdef ATH_DEBUG
if (sc->sc_debug & ATH_DEBUG_TX_PROC)
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
if (ts.ts_queue_id != sc->sc_bhalq)
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
ath_printtxstatbuf(sc, NULL, txstatus, ts.ts_queue_id,
idx, (status == HAL_OK));
#endif
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
/*
* If there is an error with this descriptor, continue
* processing.
*
* XXX TBD: log some statistics?
*/
if (status == HAL_EIO) {
device_printf(sc->sc_dev, "%s: invalid TX status?\n",
__func__);
* Stop processing after HAL_EIO; this is what the reference driver does. * If we hit an empty queue condition (which I haven't yet root caused, grr.) .. make sure we release the lock before continuing.
2013-03-27 00:35:45 +00:00
break;
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
}
Add some hooks into the driver to attach, detach and record EDMA descriptor events. This is primarily for the TX EDMA and TX EDMA completion. I haven't yet tied it into the EDMA RX path or the legacy TX/RX path. Things that I don't quite like: * Make the pointer type 'void' in ath_softc and have if_ath_alq*() return a malloc'ed buffer. That would remove the need to include if_ath_alq.h in if_athvar.h. * The sysctl setup needs to be cleaned up.
2012-11-08 18:11:31 +00:00
#ifdef ATH_DEBUG_ALQ
if (if_ath_alq_checkdebug(&sc->sc_alq, ATH_ALQ_EDMA_TXSTATUS))
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_EDMA_TXSTATUS,
sc->sc_tx_statuslen,
(char *) txstatus);
#endif /* ATH_DEBUG_ALQ */
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
/*
* At this point we have a valid status descriptor.
* The QID and descriptor ID (which currently isn't set)
* is part of the status.
*
* We then assume that the descriptor in question is the
* -head- of the given QID. Eventually we should verify
* this by using the descriptor ID.
*/
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
/*
* The beacon queue is not currently a "real" queue.
* Frames aren't pushed onto it and the lock isn't setup.
* So skip it for now; the beacon handling code will
* free and alloc more beacon buffers as appropriate.
*/
if (ts.ts_queue_id == sc->sc_bhalq)
continue;
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
txq = &sc->sc_txq[ts.ts_queue_id];
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK(txq);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
bf = ATH_TXQ_FIRST(&txq->fifo);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/*
* Work around the situation where I'm seeing notifications
* for Q1 when no frames are available. That needs to be
* debugged but not by crashing _here_.
*/
if (bf == NULL) {
device_printf(sc->sc_dev, "%s: Q%d: empty?\n",
__func__,
ts.ts_queue_id);
* Stop processing after HAL_EIO; this is what the reference driver does. * If we hit an empty queue condition (which I haven't yet root caused, grr.) .. make sure we release the lock before continuing.
2013-03-27 00:35:45 +00:00
ATH_TXQ_UNLOCK(txq);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
continue;
}
DPRINTF(sc, ATH_DEBUG_TX_PROC, "%s: Q%d, bf=%p, start=%d, end=%d\n",
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
__func__,
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
ts.ts_queue_id, bf,
!! (bf->bf_flags & ATH_BUF_FIFOPTR),
!! (bf->bf_flags & ATH_BUF_FIFOEND));
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
EDMA TX tweaks: * don't poke ath_hal_txstart() if nothing was pushed into the FIFO during the refill process; * shuffle around the TX debugging output a little so it's logged at TX hardware enqueue; * Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
/* XXX TODO: actually output debugging info about this */
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
#if 0
/* XXX assert the buffer/descriptor matches the status descid */
if (ts.ts_desc_id != bf->bf_descid) {
device_printf(sc->sc_dev,
"%s: mismatched descid (qid=%d, tsdescid=%d, "
"bfdescid=%d\n",
__func__,
ts.ts_queue_id,
ts.ts_desc_id,
bf->bf_descid);
}
#endif
/* This removes the buffer and decrements the queue depth */
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
ATH_TXQ_REMOVE(&txq->fifo, bf, bf_list);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
if (bf->bf_state.bfs_aggr)
txq->axq_aggr_depth--;
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/*
* If this was the end of a FIFO set, decrement FIFO depth
*/
if (bf->bf_flags & ATH_BUF_FIFOEND)
txq->axq_fifo_depth--;
/*
* If this isn't the final buffer in a FIFO set, mark
* the buffer as busy so it goes onto the holding queue.
*/
if (! (bf->bf_flags & ATH_BUF_FIFOEND))
bf->bf_flags |= ATH_BUF_BUSY;
DPRINTF(sc, ATH_DEBUG_TX_PROC, "%s: Q%d: FIFO depth is now %d (%d)\n",
__func__,
txq->axq_qnum,
txq->axq_fifo_depth,
txq->fifo.axq_depth);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
/* XXX assert FIFO depth >= 0 */
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
/*
* Outside of the TX lock - if the buffer is end
* end buffer in this FIFO, we don't need a holding
* buffer any longer.
*/
if (bf->bf_flags & ATH_BUF_FIFOEND) {
ATH_TXBUF_LOCK(sc);
ath_txq_freeholdingbuf(sc, txq);
ATH_TXBUF_UNLOCK(sc);
}
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
/*
* First we need to make sure ts_rate is valid.
*
* Pre-EDMA chips pass the whole TX descriptor to
* the proctxdesc function which will then fill out
* ts_rate based on the ts_finaltsi (final TX index)
* in the TX descriptor. However the TX completion
* FIFO doesn't have this information. So here we
* do a separate HAL call to populate that information.
Correct some rather weird and broken behaviour observed when doing actual traffic with an AR9380/AR9382/AR9485. The sample rate control stats would show impossibly large numbers for "successful packets transmitted." The number was a tad under 2^^64-1. So after a bit of digging, I found that the sample rate control code was making 'tries' turn into a negative number.. and this was because ts_longretry was too small. The hardware returns "ts_longretry" at the current rate selection, not overall for that TX descriptor. So if you setup four TX rate scenarios and the second one works, ts_longretry is only set for the number of attempts at that second rate scenario. The FreeBSD HAL code does the correction in ath_hal_proctxdesc() - however, this isn't possible with EDMA. EDMA TX completion is done separate from the original TX descriptor. So the real solution is to split out "find ts_rate and ts_longretry" from "complete TX descriptor". Until that's done, put a hack in the EDMA TX path that uses the rate scenario information in the ath_buf. Tested: AR9380, AR9382, AR9485 STA mode
2012-11-10 22:37:06 +00:00
*
* The same problem exists with ts_longretry.
* The FreeBSD HAL corrects ts_longretry in the HAL layer;
* the AR9380 HAL currently doesn't. So until the HAL
* is imported and this can be added, we correct for it
* here.
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
*/
/* XXX TODO */
/* XXX faked for now. Ew. */
if (ts.ts_finaltsi < 4) {
ts.ts_rate =
bf->bf_state.bfs_rc[ts.ts_finaltsi].ratecode;
Correct some rather weird and broken behaviour observed when doing actual traffic with an AR9380/AR9382/AR9485. The sample rate control stats would show impossibly large numbers for "successful packets transmitted." The number was a tad under 2^^64-1. So after a bit of digging, I found that the sample rate control code was making 'tries' turn into a negative number.. and this was because ts_longretry was too small. The hardware returns "ts_longretry" at the current rate selection, not overall for that TX descriptor. So if you setup four TX rate scenarios and the second one works, ts_longretry is only set for the number of attempts at that second rate scenario. The FreeBSD HAL code does the correction in ath_hal_proctxdesc() - however, this isn't possible with EDMA. EDMA TX completion is done separate from the original TX descriptor. So the real solution is to split out "find ts_rate and ts_longretry" from "complete TX descriptor". Until that's done, put a hack in the EDMA TX path that uses the rate scenario information in the ath_buf. Tested: AR9380, AR9382, AR9485 STA mode
2012-11-10 22:37:06 +00:00
switch (ts.ts_finaltsi) {
case 3: ts.ts_longretry +=
bf->bf_state.bfs_rc[2].tries;
case 2: ts.ts_longretry +=
bf->bf_state.bfs_rc[1].tries;
case 1: ts.ts_longretry +=
bf->bf_state.bfs_rc[0].tries;
}
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
} else {
device_printf(sc->sc_dev, "%s: finaltsi=%d\n",
__func__,
ts.ts_finaltsi);
ts.ts_rate = bf->bf_state.bfs_rc[0].ratecode;
}
/*
* XXX This is terrible.
*
* Right now, some code uses the TX status that is
* passed in here, but the completion handlers in the
* software TX path also use bf_status.ds_txstat.
* Ew. That should all go away.
*
* XXX It's also possible the rate control completion
* routine is called twice.
*/
memcpy(&bf->bf_status, &ts, sizeof(ts));
ni = bf->bf_node;
/* Update RSSI */
/* XXX duplicate from ath_tx_processq */
if (ni != NULL && ts.ts_status == 0 &&
((bf->bf_state.bfs_txflags & HAL_TXDESC_NOACK) == 0)) {
nacked++;
sc->sc_stats.ast_tx_rssi = ts.ts_rssi;
ATH_RSSI_LPF(sc->sc_halstats.ns_avgtxrssi,
ts.ts_rssi);
}
/* Handle frame completion and rate control update */
ath_tx_process_buf_completion(sc, txq, &ts, bf);
/* bf is invalid at this point */
/*
* Now that there's space in the FIFO, let's push some
* more frames into it.
*/
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_LOCK(txq);
Implement the replacement EDMA FIFO code. (Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was cleared!) This code implements a whole bunch of sorely needed EDMA TX improvements along with CABQ TX support. The specifics: * When filling/refilling the FIFO, use the new TXQ staging queue for FIFO frames * Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly. For now the non-CABQ transmit path pushes one frame into the TXQ staging queue without setting up the intermediary link pointers to chain them together, so draining frames from the txq staging queue to the FIFO queue occurs AMPDU / MPDU at a time. * In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO at once. * Now that frames are in a FIFO pending queue, we can top up the FIFO after completing a single frame. This means we can keep it filled rather than waiting for it drain and _then_ adding more frames. * The EDMA restart routine now walks the FIFO queue in the TXQ rather than the pending queue and re-initialises the FIFO with that. * When restarting EDMA, we may have partially completed sending a list. So stamp the first frame that we see in a list with ATH_BUF_FIFOPTR and push _that_ into the hardware. * When completing frames, only check those on the FIFO queue. We should never ever queue frames from the pending queue direct to the hardware, so there's no point in checking. * Until I figure out what's going on, make sure if the TXSTATUS for an empty queue pops up, complain loudly and continue. This will stop the panics that people are seeing. I'll add some code later which will assist in ensuring I'm populating each descriptor with the correct queue ID. * When considering whether to queue frames to the hardware queue directly or software queue frames, make sure the depth of the FIFO is taken into account now. * When completing frames, tag them with ATH_BUF_BUSY if they're not the final frame in a FIFO list. The same holding descriptor behaviour is required when handling descriptors linked together with a link pointer as the hardware will re-read the previous descriptor to refresh the link pointer before contiuning. * .. and if we complete the FIFO list (ie, the buffer has ATH_BUF_FIFOEND set), then we don't need the holding buffer any longer. Thus, free it. Tested: * AR9380/AR9580, STA and hostap * AR9280, STA/hostap TODO: * I don't yet trust that the EDMA restart routine is totally correct in all circumstances. I'll continue to thrash this out under heavy multiple-TXQ traffic load and fix whatever pops up.
2013-03-26 20:04:45 +00:00
if (dosched)
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
ath_edma_tx_fifo_fill(sc, txq);
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues. Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons. This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here. The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing. The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly. The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things. Major: * Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock. * Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are. * Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other. * Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this. Minor: * Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down. * Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away. Tested: * AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered) TODO: * (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
2013-03-24 00:03:12 +00:00
ATH_TXQ_UNLOCK(txq);
Begin fleshing out the TX FIFO support. * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
2012-08-11 22:20:28 +00:00
}
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
sc->sc_wd_timer = 0;
Clear IFF_DRV_OACTIVE if any slots were completed. This unblocks TX EDMA under high load.
2012-11-05 09:27:47 +00:00
if (idx > 0) {
IF_LOCK(&sc->sc_ifp->if_snd);
sc->sc_ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
IF_UNLOCK(&sc->sc_ifp->if_snd);
}
Flesh out some initial EDMA TX FIFO fill, complete and refill routines. Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
2012-08-20 06:11:04 +00:00
/* Kick software scheduler */
/*
* XXX It's inefficient to do this if the FIFO queue is full,
* but there's no easy way right now to only populate
* the txq task for _one_ TXQ. This should be fixed.
*/
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed for 802.11n TX device restarting. Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
if (dosched)
Methodize the process of adding the software TX queue to the taskqueue. Move it (for now) to the TX taskqueue.
2013-02-07 02:15:25 +00:00
ath_tx_swq_kick(sc);
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
}
static void
ath_edma_attach_comp_func(struct ath_softc *sc)
{
TASK_INIT(&sc->sc_txtask, 0, ath_edma_tx_proc, sc);
}
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
void
ath_xmit_setup_edma(struct ath_softc *sc)
{
/* Fetch EDMA field and buffer sizes */
(void) ath_hal_gettxdesclen(sc->sc_ah, &sc->sc_tx_desclen);
(void) ath_hal_gettxstatuslen(sc->sc_ah, &sc->sc_tx_statuslen);
(void) ath_hal_getntxmaps(sc->sc_ah, &sc->sc_tx_nmaps);
device_printf(sc->sc_dev, "TX descriptor length: %d\n",
sc->sc_tx_desclen);
device_printf(sc->sc_dev, "TX status length: %d\n",
sc->sc_tx_statuslen);
device_printf(sc->sc_dev, "TX buffers per descriptor: %d\n",
sc->sc_tx_nmaps);
sc->sc_tx.xmit_setup = ath_edma_dma_txsetup;
sc->sc_tx.xmit_teardown = ath_edma_dma_txteardown;
Migrate some more TX side setup routines to be methods.
2012-07-31 03:09:48 +00:00
sc->sc_tx.xmit_attach_comp_func = ath_edma_attach_comp_func;
Break out the hardware handoff and TX DMA restart code into methods. These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
2012-07-31 02:28:32 +00:00
sc->sc_tx.xmit_dma_restart = ath_edma_dma_restart;
sc->sc_tx.xmit_handoff = ath_edma_xmit_handoff;
Break out ath_draintxq() into a method and un-methodize ath_tx_processq(). Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
2012-08-12 00:37:29 +00:00
sc->sc_tx.xmit_drain = ath_edma_tx_drain;
Begin separating out the TX DMA setup in preparation for TX EDMA support. * Introduce TX DMA setup/teardown methods, mirroring what's done in the RX path. Although the TX DMA descriptor is setup via ath_desc_alloc() / ath_desc_free(), there TX status descriptor ring will be allocated in this path. * Remove some of the TX EDMA capability probing from the RX path and push it into the new TX EDMA path.
2012-07-23 03:52:18 +00:00
}
Reference in New Issue Copy Permalink