diff options
author | adrian <adrian@FreeBSD.org> | 2012-08-12 00:37:29 +0000 |
---|---|---|
committer | adrian <adrian@FreeBSD.org> | 2012-08-12 00:37:29 +0000 |
commit | 815b21bf9d1bb80b958455f2869ac725355c8442 (patch) | |
tree | 98bcc50ffa833ff871c27c1c12b49c7fe92a15d8 /lib/libthr/thread/thr_cond.c | |
parent | 988528484fdfe3c53b0398a959c7649029588e5f (diff) | |
download | FreeBSD-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