summaryrefslogtreecommitdiffstats
path: root/sys/dev/ath
Commit message (Collapse)AuthorAgeFilesLines
* Flesh out some initial EDMA TX FIFO fill, complete and refill routines.adrian2012-08-201-6/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note: This is totally sub-optimal and a work in progress. * Support filling an empty FIFO TXQ with frames from the ath_buf queue in the ath_txq list. However, since there's (currently) no clean, easy way to separate the frames that are in the FIFO versus just waiting, the code waits for the FIFO to be totally empty before it attempts to queue more. This is highly sub-optimal but is enough to get the ball rolling. * A _lot_ of the code assumes that the TX status is filled out in the struct ath_buf bf_status field. So for now, memcpy() the completion over. * None of the TX drain / reset routines will attempt to complete completed frames before draining, so it can't be used for 802.11n TX aggregation. (This won't work anyway, as the aggregation TX descriptor API hasn't yet been converted; and that'll happen in some future commits.) * Fix an issue where the FIFO counter wasn't being incremented, leading to the queue logic just plain not working. * HAL_EIO means "descriptor wasn't valid", versus "not finished, don't continue." So don't stop processing descriptors when HAL_EIO is hit. * Don't service frame completion from the beacon queue. It isn't currently fully setup like a real queue and the first attempt at accessing the queue lock will panic the kernel. Tested: * AR9380, STA mode This commit is brought to you by said AR9380 in STA mode.
* Advance the descriptor pointer by sc->sc_tx_desclen bytes, rather thanadrian2012-08-201-12/+11
| | | | | | | | | | | | | | sizeof(struct ath_desc). This isn't correct for EDMA TX descriptors. This popped up during iperf tests. Ping tests never created frames that had enough segments to overflow into a second descriptor. However, an iperf TCP test would do that after a few seconds; the second descriptor would almost always certainly have garbage. Tested: * AR9380, STA mode * AR9280, STA mode (802.11n TX, legacy TX)
* Make sure all of the buffers are printed, rather than (n-1).adrian2012-08-201-4/+2
|
* Extend the TX descriptor debug printing to be properly aware ofadrian2012-08-192-4/+83
| | | | | | | | | | | | | | | | | EDMA code. * create a new TX EDMA descriptor struct to represent TX EDMA descriptors when doing debugging; * implement an EDMA printing function which: + hardcodes the TX map size to 4 for now; + correctly prints out the number of segments - there's one descriptor for up to 4 buffers (segments), not one for each segment; + print out 4 DS buffer and len pointers; + print out the correct number of DWORDs in the TX descriptor. TODO: * Remove all of the hard-coded stuff. Ew.
* When assembling the descriptor list, make sure that the "first" descriptoradrian2012-08-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | is marked correctly. The existing logic assumed that the first descriptor is i == 0, which doesn't hold for EDMA TX. In this instance, the first time filltxdesc() is called can be up to i == 3. So for a two-buffer descriptor: * firstSeg is set to 0; * lastSeg is set to 1; * the ath_hal_filltxdesc() code will treat it as the last segment in a descriptor chain and blank some of the descriptor fields, causing the TX to stop. When firstSeg is set to 1 (regardless of lastSeg), it overrides the lastSeg setting. Thus, ath_hal_filltxdesc() won't blank out these fields. Tested: AR9380, STA mode. With this, association is successful.
* Fix buildkib2012-08-151-2/+2
|
* Extend the non-aggregate TX descriptor chain routine to be aware of:adrian2012-08-151-9/+49
| | | | | | | | | | | | | | | | | | | | | | | * the descriptor ID, and * the multi-buffer support that the EDMA chips support. This is required for successful MAC transmission of multi-descriptor frames. The MAC simply hangs if there are NULL buffers + 0 length pointers, but the descriptor did have TxMore set. This won't be done for the 11n aggregate path, as that will be modified to use the newer API (ie, ath_hal_filltxdesc() and then set first|middle| last_aggr), which will deprecate some of the current code. TODO: * Populate the numTxMaps field in the HAL, then make sure that's fetched by the driver. Then I can undo that hack. Tested: * AR9380, AP mode, TX'ing non-aggregate 802.11n frames; * AR9280, STA/AP mode, doing aggregate and non-aggregate traffic.
* Bump up the rate control table size to incorporate 3 stream entries.adrian2012-08-151-3/+3
|
* Remove this comment, it's no longer relevant.adrian2012-08-151-1/+0
|
* Extend the duration calculations to work with three and four streamadrian2012-08-151-12/+19
| | | | rates.
* Add a missing comma.adrian2012-08-151-1/+1
| | | | Pointy hat to: me, for not doing a 'clean' build first.
* Add 3 stream rates to the sample rate control module.adrian2012-08-151-1/+47
|
* Extend the sample mask from 32 bits to 64 bits.adrian2012-08-152-19/+23
| | | | | | | | This is required to support > MCS15 as more than 32 bit rate entries are suddenly available. This is quite messy - instead of doing typecasts at each mask operation, this should be migrated to use a macro and have that do the typecast.
* Implement a sequential descriptor ID value and stuff it in the ath_buf.adrian2012-08-152-0/+10
| | | | | This will be used by the EDMA TX code to assign descriptor IDs in order to provide some debugging.
* Dump out the TX FIFO depth.adrian2012-08-141-2/+3
|
* Break out the TX completion code into a separate function, so it can beadrian2012-08-142-35/+67
| | | | | | | | | re-used by the upcoming EDMA TX completion code. Make ath_stoptxdma() public, again so the EDMA TX code can use it. Don't check for the TXQ bitmap in the ISR when doing EDMA work as it doesn't apply for EDMA.
* Add an assertion to check that the given TXQ is _not_ locked.adrian2012-08-141-1/+4
|
* Revert the ath_tx_draintxq() method, and instead teach it the minimumadrian2012-08-126-30/+26
| | | | | | | | | necessary to "do" EDMA. It was just using the TX completion status for logging information about the descriptor completion. Since with EDMA we don't know this without checking the TX completion FIFO, we can't provide this information. So don't.
* Break out ath_draintxq() into a method and un-methodize ath_tx_processq().adrian2012-08-126-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that I understand what's going on with this, I've realised that it's going to be quite difficult to implement a processq method in the EDMA case. Because there's a separate TX status FIFO, I can't just run processq() on each EDMA TXQ to see what's finished. i have to actually run the TX status queue and handle individual TXQs. So: * unmethodize ath_tx_processq(); * leave ath_tx_draintxq() as a method, as it only uses the completion status for debugging rather than actively completing the frames (ie, all frames here are failed); * Methodize ath_draintxq(). The EDMA ath_draintxq() will have to take care of running the TX completion FIFO before (potentially) freeing frames in the queue. The only two places where ath_tx_draintxq() (on a single TXQ) are used: * ath_draintxq(); and * the CABQ handling in the beacon setup code - it drains the CABQ before populating the CABQ with frames for a new beacon (when doing multi-VAP operation.) So it's quite possible that once I methodize the CABQ and beacon handling, I can just drop ath_tx_draintxq() in its entirety. Finally, it's also quite possible that I can remove ath_tx_draintxq() in the future and just "teach" it to not check the status when doing EDMA.
* Extend the beacon code slightly to support AP mode beaconing for theadrian2012-08-113-8/+52
| | | | | | | | | | | | | | | | | | | EDMA HAL hardware. * The EDMA HAL code assumes the nexttbtt and intval values are in TU/8 units, rather than TU. For now, just "hack" around that here, at least until I code up something to translate it in the HAL. * Setup some different TXQ flags for EDMA hardware. * The EDMA HAL doesn't support setting the first rate series via ath_hal_setuptxdesc() - instead, a call to ath_hal_set11nratescenario() is always required. So for now, just do an 11n rate series setup for EDMA beacon frames. This allows my AR9380 to successfully transmit beacon frames. However, CABQ TX and all normal data frame TX and TX completion is still not functional and will require some more significant code churn to make work.
* Add the AR9380 HAL to the TX descriptor debugging, in order to dump alladrian2012-08-111-1/+2
| | | | of the descriptor contents.
* Add the AR9300 HAL ID in to the 11n check routine.adrian2012-08-111-1/+2
| | | | | | | I was having TX hang issues, which I root caused to having the legacy ath_hal_setupxtxdesc() called, rather than the 11n rate scenario setup code. This meant that rate control information wasn't being put into frames, causing the MAC to stall/hang.
* Begin fleshing out the TX FIFO support.adrian2012-08-112-1/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add ATH_TXQ_FIRST() for easy tasting of what's on the list; * Add an "axq_fifo_depth" for easy tracking of how deep the current FIFO is; * Flesh out the handoff (mcast, hw) functions; * Begin fleshing out a TX ISR proc, which tastes the TX status FIFO. The legacy hardware stuffs the TX completion at the end of the final frame descriptor (or final sub-frame when doing aggregate.) So it's feasible to do a per-TXQ drain and process, as the needed info is right there. For EDMA hardware, there's a separate TX completion FIFO. So the TX process routine needs to read the single FIFO and then process the frames in each hardware queue. This makes it difficult to do a per-queue process, as you'll end up with frames in the TX completion FIFO for a different TXQ to the one you've passed to ath_tx_draintxq() or ath_tx_processq(). Testing: I've tested the TX queue and TX completion code in hostap mode on an AR9380. Beacon frames successfully transmit and the completion routine is called. Occasional data frames end up in TXQ 1 and are also successfully completed. However, this requires some changes to the beacon code path as: * The AR9380 beacon configuration API is now in TU/8, rather than TU; * The AR9380 TX API requires the rate control is setup using a call to setup11nratescenario, rather than having the try0 series setup (rate/tries for the first series); so the beacon won't go out. I'll follow this up with commits to the beacon code.
* Commit device IDs for the (eventually upcoming) AR9380 HAL.adrian2012-08-071-0/+9
| | | | Obtained from: Qualcomm Atheros, Linux ath9k
* Correct re-initialise the link pointer to be the final descriptor inadrian2012-08-071-1/+1
| | | | | | | | the last buffer. This fixes traffic stalls that were occuring with stuck beacon events. PR: kern/170433
* Remove unnecessary debugging printf()s.adrian2012-08-062-8/+0
|
* Migrate the 802.11n ath_hal_chaintxdesc() API to use a buffer/segmentadrian2012-08-055-10/+25
| | | | | | | | | | | array, similar to what filltxdesc() uses. This removes the last reference to ds_data in the TX path outside of debugging statements. These need to be adjusted/fixed. Tested: * AR9280 STA/AP with iperf TCP traffic
* Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.adrian2012-08-0513-19/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing API only exposes 'seglen' (the current buffer (segment) length) with the data buffer pointer set in 'ds_data'. This is fine for the legacy DMA engine but it won't work for the EDMA engines. The EDMA engine has a significantly different TX descriptor layout. * The legacy DMA engine had a ds_data pointer at the same offset in the descriptor for both TX and RX buffers; * The EDMA engine has no ds_data for RX - the data is DMAed after the descriptor; * The EDMA engine has support for 4 TX buffer/segment pairs in the TX DMA descriptor; * The EDMA TX completion is in a different FIFO, and the driver will 'link' the status completion entry to a QCU by a "QCU ID". I don't know why it's just not filled in by the hardware, alas. So given that, here are the changes: * Instead of directly fondling 'ds_data' in ath_desc, change the ath_hal_filltxdesc() to take an array of buffer pointers as well as segment len pointers; * The EDMA TX completion status wants a descriptor and queue id. This (for now) uses bf_state.bfs_txq and will extract the hardware QCU ID from that. * .. and this is ugly and wasteful; it should change to just store the QCU in the bf_state and save 3/7 bytes in the process. Now, the weird crap: * The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than taking a function argument. I've tidied that up. * The multicast queue frames get put on a software TXQ and then that is appended to the hardware CABQ when appropriate. So for now, make sure that bf_state->bfs_txq points at the CABQ when adding frames to the multicast queue. * .. but the multicast queue TX path for now doesn't use the software queue and instead (a) directly sets up the descriptor contents at that point; (b) the frames on the vap->avp_mcastq are then just appended wholesale to the CABQ. So for now, I don't have to worry about making the multicast path work with aggregation or the per-TID software queue. Phew. What's left to do: * I need to modify the 11n ath_hal_chaintxdesc() API to do the same. I'll do that in a subsequent commit. * Remove bf_state.bfs_txq entirely and store the QCU as appropriate. * .. then do the runtime "is this going on the right HWQ?" checks using that, rather than comparing pointer values. Tested on: * AR9280 STA/AP * AR5416 STA/AP
* Fix an issue that crept in with the previous descriptor tidyup.adrian2012-08-021-2/+5
| | | | | | | | | | | | | | When forming aggregates, the last descriptor was now not being correctly setup - instead, the "setuplasttxdesc" call was being handed the first descriptor in the last subframe, rather than the last descriptor in the last subframe. This showed up as "bad series0 hwrate" messages, as the final descriptor just didn't have any of the rate control information squirreled away. Tested: * AR9280 STA -> 11n AP, iperf TCP
* Fix a case of "mis-located braces".adrian2012-08-011-2/+2
| | | | PR: kern/170302
* Allow 802.11n hardware to support multi-rate retry when RTS/CTS isadrian2012-07-314-7/+24
| | | | | | | | | | | | | | | | enabled. The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have all the bits needed to support MRR + RTS/CTS. The AR5416 and later support a packet duration and RTS/CTS flags per rate scenario, so we should support it. Tested: * AR9280, STA PR: kern/170302
* Shuffle the call to ath_hal_setuplasttxdesc() to _after_ the rate controladrian2012-07-312-31/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | code is called and remove it from ath_buf_set_rate(). For the legacy (non-11n API) TX routines, ath_hal_filltxdesc() takes care of setting up the intermediary and final descriptors right, complete with copying the rate control info into the final descriptor so the rate modules can grab it. The 11n version doesn't do this - ath_hal_chaintxdesc() doesn't copy the rate control bits over, nor does it clear isaggr/moreaggr/ pad delimiters. So the call to setuplasttxdesc() is needed here. So: * legacy NICs - never call the 11n rate control stuff, so filltxdesc copies the rate control info right; * 11n NICs transmitting legacy or 11n non-aggregate frames - ath_hal_set11nratescenario() is called to setup rate control and then ath_hal_filltxdesc() chains them together - so the rate control info is right; * 11n aggregate frames - set11nratescenario() is called, then ath_hal_chaintxdesc() is called to chain a list of aggregate and subframes together. This requires a call to ath_hal_setuplasttxdesc() to complete things. Tested: * AR9280 in station mode TODO: * I really should make sure that the descriptor contents get blanked out correctly or garbage left over from aggregate frames may show up in non-aggregate frames, leading to badness.
* Push the rate control and descriptor chaining into the descriptor "set"adrian2012-07-311-61/+52
| | | | | | | | | | | | | | | | | | | | | | | functions, for both legacy and 802.11n. This will simplify supporting the EDMA chipsets as these two descriptor setup functions can just be overridden in their entirety, hiding all of the subtle differences in setting things up. It's not a permanent solution, as eventually the AR5416 HAL should grow similar versions of the 11n descriptor functions and then those can be used. TODO: * Push the "clr11naggr" call into the legacy setds, just to ensure that retried frames don't end up with the aggregate bits set inappropriately; * Remove the "setlasttxdesc" call from the 11n TX path and push it into setds_11n. * Ensure that setds_11n will work correctly for non-aggregate frames; * .. and then when it does, just unconditionally call "setds_11n" for 11n NICs and "setds" for non-11n NICs.
* Migrate some more TX side setup routines to be methods.adrian2012-07-316-18/+86
|
* Break out the hardware handoff and TX DMA restart code into methods.adrian2012-07-313-4/+70
| | | | | | | | These (and a few others) will differ based on the underlying DMA implementation. For the EDMA NICs, simply stub them out in a fashion which will let me focus on implementing the necessary descriptor API changes.
* Placeholder ioctl for an upcoming rate control statistics API change.adrian2012-07-311-0/+1
|
* Shuffle the rate control call to be consistent with non-aggregate TX.adrian2012-07-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | The correct ordering for non-aggregate TX is: * call ath_hal_setuptxdesc() to setup the first TX descriptor complete with the first TX rate/try count; * call ath_hal_setupxtxdesc() to setup the multi-rate retry; * .. or for 802.11n NICs, call ath_hal_set11nratescenario() for MRR and 802.11n flags; * then call ath_hal_filltxdesc() to setup intermediary descriptors in a multi-descriptor single frame. The call to ath_hal_filltxdesc() routines seem to correctly (consistently?) handle the intermediary descriptor flags, including copying the rate control information to the final descriptor in the frame. That's used by the rate control module rather than the hardware. Tested: * Only on AR9280 STA mode, however it should work on other chips in both STA and AP mode.
* Fix breakage introduced in r238824 - correctly calculate the descriptoradrian2012-07-291-1/+7
| | | | | | | | | | | | wrapping. The previous code was only wrapping descriptor "block" boundaries rather than individual descriptors. It sounds equivalent but it isn't. r238824 changed the descriptor allocation to enforce that an individual descriptor doesn't wrap a 4KiB boundary rather than the whole block of descriptors. Eg, for TX descriptors, they're allocated in blocks of 10 descriptors for each ath_buf (for scatter/gather DMA.)
* Flesh out the multi-rate retry capability.adrian2012-07-286-1/+7
| | | | | | | | The existing method for testing for MRR is to call the "SetupXTXDesc" HAL method and see if it returns AH_TRUE or AH_FALSE. This capability explicitly lists what number of multi-rate attempts are possible. "1" means "one rate attempt supported".
* Commit missing #define from a previous check-in.adrian2012-07-281-0/+2
| | | | The AR9300 and later have an 8-deep TX FIFO for each hardware queue.
* Flesh out the initial TX FIFO storage for each hardware TX queue.adrian2012-07-282-0/+51
|
* Add a missing call to ath_txdma_teardown().adrian2012-07-281-0/+1
|
* Tidy up the TX status fields a little and add a couple new flags.adrian2012-07-271-9/+14
| | | | | | | | * shuffle things around so things fall on natural padding boundaries; * add a couple of new flags to specify LDPC and whether to switch to the low power RX chain configuration after this TX has completed. Obtained from: Qualcomm Atheros
* Add STBC TX support for AR5416 HAL chips.adrian2012-07-271-0/+1
| | | | | | | | | | | | | Specifically, however: * AR9280 and later support 1-stream STBC RX; * AR9280 and AR9287 support 1-stream STBC TX. The STBC support isn't announced (yet) via net80211 and it isn't at all chosen by the rate control code, so there's no real consumer of this yet. Obtained from: Qualcomm Atheros
* Add a STBC TX flag.adrian2012-07-271-0/+1
| | | | Obtained from: Qualcomm Atheros
* Add some comments about what the two fields mean.adrian2012-07-271-2/+2
|
* Introduce a couple more fields in the rate scenario setup as part ofadrian2012-07-272-0/+4
| | | | | | | | | | (future) TPC support in the AR9300 HAL. This is effectively a no-op for the moment as (a) TPC isn't really supported, (b) the AR9300 HAL isn't yet public, and (c) the existing HAL code doesn't use these fields. Obtained from: Qualcomm Atheros
* Bring this API in line with what the reference driver and Linux ath9kadrian2012-07-274-7/+5
| | | | | | was doing. Obtained from: Qualcomm Atheros, Linux ath9k
* Allocate a descriptor ring for EDMA TX completion status.adrian2012-07-272-3/+20
| | | | Configure the hardware with said ring physical address and size.
* Modify ath_descdma_cleanup() to handle ath_descdma instances with noadrian2012-07-271-18/+23
| | | | | | | | buffers. ath_descdma is now being used for things other than the classical combination of ath_buf + ath_desc allocations. In this particular case, don't try to free and blank out the ath_buf list if it's not passed in.
OpenPOWER on IntegriCloud