K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-05T06:57:44.206769Z
K 7
svn:log
V 796
Flip back to having the TXQ lock held during the whole of ath_tx_processq().
I'll deal with correcting the locking later so LORs don't occur.
For now, this will let me write TX packet completion functions to implement
BAW tracking and aggregation, which will update per-TID state.

Having the TXQ locked in this way means that:

(a) the order of TXQ completions being processed will be correct - ie, multiple
    concurrent calls to ath_tx_processq() for the same TXQ won't mess things up;
(b) the per-TID state is correctly locked, so concurrent TX scheduling and
    TX completion isn't going to end up with subtle race conditions.

As long as completions are only ever called from ath_tx_proc(), this should
be fine - it won't race with itself. The race conditions are what I'm worried
about.

END