[wip] ar9300 hostap support

[Adrian Chadd]

Hi,

Here's an update against the most recent -HEAD:

http://people.freebsd.org/~adrian/ath/20130326-cabq-edma-tx-rework-5.diff

I've done some more basic interoperability with the station devices I
have hiding around here. There's been no real issues thus far.

I've committed some of the shared work (mostly to do with
cabq/multicast queue) code to -HEAD already. It may affect both the
pre-AR9380 and AR9380 series NICs. I'd appreciate it if people updated
to -HEAD anyway and tested it out.

Thanks!


Adrian

On 25 March 2013 16:13, Adrian Chadd <adrian at freebsd.org> wrote:
> Hi,
>
> I've been working on AR9380 HAL hostap support in my spare time.
>
> Here's where I'm at so far:
>
> http://people.freebsd.org/~adrian/ath/20130325-cabq-edma-txq-rework-3.diff
>
> 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
> review!)
> * 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.