I've been working on AR9380 HAL hostap support in my spare time.

Here's where I'm at so far:


Now, this is not likely what I'm going to push into -HEAD. But it's
being stable for me for now, save some odd crashes that have been
reported with TX completion on the AR9380 chips.

Now, what's going on and what I have to stage into -HEAD:

* The whole descriptor linking thing is just plain wrong for the
AR9380 chips. I have to nuke axq_link from orbit and use
ath_hal_settxdesclink(). This requires some manual fiddling of things
in a variety of places in both the pre-AR9380 chips and the AR9380
chips - it's used for CABQ assembly, for beacon programming, for
general unicast traffic programming ... eek.

* The CABQ assembly code needed to be tweaked for EDMA. Now I have to
populate the whole list of CABQ frames (with the correct link pointers
as listed above) before I can push that list into the hardware FIFO.

* I need to separate out the FIFO contents from the pending TX queue
in each hardware TXQ. Right now my EDMA TX code just pushes individual
MPDU or AMPDU frames into the FIFO and then waits until the FIFO
empties before pushing more frames in. I'm now changing it so there's
a separate "what's in the FIFO" queue, so..

* .. I can properly support the whole CABQ method of "these frames are
in the FIFO", because the CABQ support requires pushing multiple
frames (linked with the link pointer) into a single FIFO entry, .. and

* .. if I want to support restarting that queue during a stuck beacon
or other recoverable reset, I need to know where my FIFO frame
boundaries are.

Now, ath9k does it a bit differently - it has a split queue setup, but
the FIFO queue is a list of queues. I don't yet want to refactor
everything that way, so I'm just marking the start/end of each frame
list with ath_buf flags (ATH_BUF_FIFOPTR for the beginning and
ATH_BUF_FIFOEND for the last buffer in a list) and then making sure I
handle those right.

Now, this seems to work - in both encrypted (CCMP/TKIP) and open mode.
I'm not getting the high throughput I expect though - it looks like
I'm transmitting far too many single frames at the moment, rather than
being (more) aggressive at aggregation. I'll worry about that later.
This includes testing with stations in sleep mode (ie, traffic going
into the CABQ.)

Now, what's left?

* I have to finish converting over the axq_link references to
ath_hal_settxdesclink(), and kill axq_link as a concept.
* I need to figure out why we're seeing that panic with the AR9380 TX
completion FIFO saying that something is free on Q1 when the Q1 FIFO
is empty.
* I need to mark intermediary buffers in a buffer list with
ATH_BUF_BUSY, so they go onto the holdingbf queue. Otherwise the DMA
engine may hang (and this is a problem in ath9k too! Go go gadget code
* Lots, lots more testing.

I'd really like to figure out why the aggregation isn't as aggressive
as it could be. I'll dig into that later. I should be seeing ~
250-280mbit TCP throughput on 3x3 HT40; but now I'm seeing ~150mbit
(ie, what I see with 2x2 HT/40.) That's obviously wrong. I'm seeing
very reliable MCS23 transmission and reception so it isn't that. It
seems to be something odd with how aggregates are being formed and
said aggregation logic seeming to transmit more single frames than
aggregate frames. Sigh.

Anyway. If you want to test it out, the patch above applies cleanly to
-HEAD and you _do_ need to update to the latest git HAL or encryption
just plain won't work.
freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to