diff options
author | adrian <adrian@FreeBSD.org> | 2012-08-11 22:20:28 +0000 |
---|---|---|
committer | adrian <adrian@FreeBSD.org> | 2012-08-11 22:20:28 +0000 |
commit | 95f393e2ff9381a0e1223430f7af46531ea40c57 (patch) | |
tree | 216a13fc1e386d9b22bc31eacf0d539122207e4d /sys/dev/cs | |
parent | 60e552193c6254b62636fc4532d50854f1ec0739 (diff) | |
download | FreeBSD-src-95f393e2ff9381a0e1223430f7af46531ea40c57.zip FreeBSD-src-95f393e2ff9381a0e1223430f7af46531ea40c57.tar.gz |
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.
Diffstat (limited to 'sys/dev/cs')
0 files changed, 0 insertions, 0 deletions