K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2012-11-10T22:37:06.808765Z
K 7
svn:log
V 1099
Correct some rather weird and broken behaviour observed when doing
actual traffic with an AR9380/AR9382/AR9485.

The sample rate control stats would show impossibly large numbers for
"successful packets transmitted."  The number was a tad under 2^^64-1.
So after a bit of digging, I found that the sample rate control code
was making 'tries' turn into a negative number.. and this was because
ts_longretry was too small.

The hardware returns "ts_longretry" at the current rate selection,
not overall for that TX descriptor.  So if you setup four TX rate
scenarios and the second one works, ts_longretry is only set for
the number of attempts at that second rate scenario.  The FreeBSD HAL
code does the correction in ath_hal_proctxdesc() - however, this isn't
possible with EDMA.

EDMA TX completion is done separate from the original TX descriptor.
So the real solution is to split out "find ts_rate and ts_longretry"
from "complete TX descriptor".  Until that's done, put a hack in
the EDMA TX path that uses the rate scenario information in the ath_buf.

Tested: AR9380, AR9382, AR9485 STA mode

END