Date: Mon, 25 Mar 2013 16:13:19 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: [wip] ar9300 hostap support Message-ID: <CAJ-Vmo=4QRuYeG8LmEfntTB2W5OyfsnVDCz5cJ__zWYbXkme3w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=4QRuYeG8LmEfntTB2W5OyfsnVDCz5cJ__zWYbXkme3w>