K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-23T23:33:38.856849Z
K 7
svn:log
V 1164
Try to make the ATH_BUF_BUSY handling work again.

* add bf_last to ath_buf, which points to the last frame in
  an aggregate, or itself for a single frame
* Set ATH_BUF_BUSY in the last frame in an aggregate - that's
  the ath_buf which the hardware may be currently tinkering
  with.
* Restore the ATH_BUF_BUSY clearing in ath_tx_processq() -
  clear the ATH_BUF_BUSY flag in the last entry on the free list
  before adding the next buffer - it's assumed the hardware has
  finished with that descriptor.

This should restore the current behaviour that ATH_BUF_BUSY
protects against, but:

* retries which use ATH_BUF_BUSY buffers need to result in the
  ath_buf being cloned, rather than reused. That buffer then
  needs to be returned to the free list.

* This code seems like it'll only work for a single TX queue.
  As in, if TXQ 0 has been handled and the last buffer is marked
  BUSY, then TXQ 1 runs - the last buffer on the free list will
  be marked as non-busy.

  ath9k and the reference code uses a more complicated
  "holding descriptor" setup which keeps the descriptor on the
  TXQ list and frees it when needed. This will be eventually
  needed!

END