summaryrefslogtreecommitdiffstats
path: root/lib/libthr/thread/thr_cond.c
diff options
context:
space:
mode:
authoradrian <adrian@FreeBSD.org>2012-08-12 00:37:29 +0000
committeradrian <adrian@FreeBSD.org>2012-08-12 00:37:29 +0000
commit815b21bf9d1bb80b958455f2869ac725355c8442 (patch)
tree98bcc50ffa833ff871c27c1c12b49c7fe92a15d8 /lib/libthr/thread/thr_cond.c
parent988528484fdfe3c53b0398a959c7649029588e5f (diff)
downloadFreeBSD-src-815b21bf9d1bb80b958455f2869ac725355c8442.zip
FreeBSD-src-815b21bf9d1bb80b958455f2869ac725355c8442.tar.gz
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.
Diffstat (limited to 'lib/libthr/thread/thr_cond.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud