Begin fleshing out some software TX queue handling structs along with some
placeholders for software retransmit and aggregation code.

Create a per-tid structure to store queued frames in (and include
a placeholder to store frames currently in the AMPDU-TX block-ack window.)

Introduce a per ath_txq (hardware TXQ) list which contains the ath_node
entries which currently have packets ready to TX. This way the software
TX scheduler can just walk the list of nodes which have indicated they
have packets ready to schedule.

(Something similar should be done per-TID so the per-node code won't have
to iterate each TID to see if the queue is empty; but that can be done
much later.)
More software TX queue preparation changes

* move the TX queue out from the hardware txq and to the softc for now
* begin fleshing out the very basic software tx queue functions
Begin separating out the "setup descriptor", "setup descriptor list"
and "handoff" from the actual TX path.

Packets going onto a software TX queue will need to be setup as per
normal but won't be added to the hardware TX queue until later.

Details:

* ath_tx_start() is now ath_tx_normal_setup() - it sets up the packet,
  configures the first descriptor but doesn't add it to the TX queue
  via ath_tx_handoff();
* ath_tx_handoff() now doesn't call ath_tx_chaindesclist() to chain
  together descriptors as required by the MAC;

* a new ath_tx_start() now:

  + determines the destination TX queue;
  + calls ath_tx_normal_setup() to do the packet and descriptor setup;
  + calls ath_tx_chaindesclist() to chain the descriptors together
    for the MAC;
  + calls ath_tx_handoff() to dispatch to the hardware.

The packets going onto the mcast software TXQ (which is implemented
just like a hardware TXQ, but with no hardware dispatch :) already do
this but the decision not to dispatch them directly is done in
ath_tx_handoff() which is something that needs to be uncoupled a bit better.

Whilst I'm here (and having to do development on an 80x50 VGA console,
due to needing to interpret kernel panics) undo some of my brain damaged
non-style(9) commits.
Add missing flag set.
Break out ath_hx_handoff() into hardware and software varieties.
The only software path at the moment is the mcastq which is then
added to the CAB queue (HW) before the beacon is transmitted.
Flesh out some more software TX queue operators.

There's still a few more operators (queue software packet to hardware,
requeue packet (from hardware) back onto the software queue, free
software queue packets that aren't on the hardware, and mark queued packets
as having no parent queue) to implement.

It's unclear yet whether packets which are queued but whose parent node
is going away should cause the TXCB callback to occur if needed.
Some further digging shows that net80211 already takes care of refcounting
the TX node references for me, so in theory (!) I shouldn't seen a node free
until all pending TX packets have completed.

For now, leave the functions in there which I was going to write to do this
(primarily so I can have some checks before I do free the state!)

Whilst I'm here, add a TID reference. Between this and the bf_node
reference, enough information should (eventually) be available now for
a completed packet (success, failure, filtered) to be matched back to
its source node/TID queue.
Flesh out some more software TX queue code

ath_buf's now have both a destination tid and a destination txq.
(I may end up also storing a destination AC, just to be complete.)

The destination TXQ is pre-calculated at TID TXQ add time
as that won't change. It's then added to the pre-determined hardware TXQ
when the packet is ready to be scheduled.

The routine to calculate the ath_node txq length is dirty.
I shall fix soon.

Packets should now be schedulable via a call to ath_tx_swq() and sit
in the per-node queue until ath_txq_sched() is called. Packets then
will be removed from the software queue and added to the relevant
hardware queue.

Next is writing a completion handler which looks a lot like what
ath_tx_processq() does, but knows about the ath_node/tid involved.
Eventually this is where the software aggregation retries will live.

The TX packet scheduler isn't fair. It isn't pretending to be for now.
* add a per-node queue depth counter
* correctly lock access to sc->sc_txnodeq
* fix an incorrect txq reference
Since there's currently no TX processing/completion task (ie, TX is
direct-dispatch), just do swq->hwq dispatch from ath_start().
Make the qdepth add/sub atomic, but the qdepth check isn't yet atomic.
I'll leave it like that for now until I better understand what, if any,
locking is done with ath_node / ieee80211_node.

Flip on the software TX queue dispatch.
Clarify the dirty locking that I'm currently doing at the moment.

This isn't crashing (primarily because the ath_node is mostly behind the
ATH lock rather than a per-node lock.)
Default module values for testing.
Add code to flush the software queues whenever the interface is
reset.

* Add functionality to flush all software-queued packets for a TID.
* Add a function to drain all software queued packets for the given
  node
* Add a function that drains all software queued packets for the
  given interface - so, all nodes for all vaps.

This is needed because now that packets are on the sw q as well as hw q,
an interface reset, channel change, etc can result in software queued
packets whose rate control bits now don't match what the channel is setup
for.

For example, during scan, the interface is in a non-ht40 mode and any
ht/40 packets queued to it will end up annoying the baseband.

ath_vap_delete() also deleted all entries from the hw and sw txq's;
it's possible we could get away with only flushing entries for the given
vap's sw tx queues. Maybe I'll do that later.

Note: I've discovered no node locking is done, so the rate control code
is likely still racy. Blah.

Finally, I'm not sure if the ieee80211 common lock should be held when
iterating like this over the nodes. It doesn't seem so - it isn't held
at the moment.

I'm still concerned about subtle race conditions with the TX path and
other things such as scan and interface reset. I'll do some further
digging later as it seems that breaking out the TX path into said
software queue has made some racy stuff a little more .. obvious.
* don't worry about logging the lack of comlock for now; I'll dig deeper
  soon
* Don't hold the txq lock whilst freeing buffers; mirror what's done
  elsewhere when manipulating the txq.
Add new mutexes - one protecting the sc txqueue slist and one for ath_node

Since ath_node now contains useful data that will be accessed concurrently,
protect it with a mutex.

Migrate the sc->sc_txnodeq out of ATH_LOCK and behind its own lock.

Since the rate control logic uses state in ath_node (ie, "stuff" attached
after it), add some mutexes to the rate control calls.

It's likely the locking isn't completely correct yet.
Fix another LOR.
Fix another LOR, this time with the IEEE80211_NODE_LOCK() (node table lock.)

free_pkts() would eventually free the last node reference, causing the
node to be removed from the node table. This required the node table lock
to be held.
Expose the default ampdu TX methods for use by ath(4).

The (current) aim is to leverage the existing per-TID AMPDU TX handling
(negotiation, BAR/BAW tracking and handling, etc) and to simply handle
the packet TX, BA response handling and retransmission in the ath(4)
driver.

The timeout call also should be turned into a callback so the ath(4)
code can trap it and remove the TID queue pause.
Temporary hack - this way I can store the ieee80211_debug #define in
opt_ah.h . This shouldn't be merged back into -HEAD.