summaryrefslogtreecommitdiffstats
path: root/sys/dev/ath/ath_hal
Commit message (Collapse)AuthorAgeFilesLines
* Commit device IDs for the (eventually upcoming) AR9380 HAL.adrian2012-08-071-0/+9
| | | | Obtained from: Qualcomm Atheros, Linux ath9k
* Migrate the 802.11n ath_hal_chaintxdesc() API to use a buffer/segmentadrian2012-08-053-4/+11
| | | | | | | | | | | 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-059-9/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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.
* 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-271-0/+2
| | | | | | | | | | (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-273-6/+4
| | | | | | was doing. Obtained from: Qualcomm Atheros, Linux ath9k
* Add a new HAL method - the AR93xx and later NICs have a separateadrian2012-07-241-0/+3
| | | | | TX descriptor ring for TX status completion. This API call will pass the allocated buffer details to the HAL.
* Break out the TX descriptor link field into HAL methods.adrian2012-07-1910-0/+114
| | | | | | | | | | | | | | | | The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy chips: * The RX DMA descriptors don't have a ds_link field; * The TX DMA descriptors have a ds_link field however at a different offset. This is a reimplementation based on what the reference driver and ath9k does. A subsequent commit will enable it in the TX and beacon paths. Obtained from: Linux ath9k, Qualcomm Atheros
* Commit missing flags for the high/low priority (HP/LP) RX queues.adrian2012-07-101-1/+4
| | | | Noticed by: everyone
* Reorder these so they match the capability enum order.adrian2012-07-101-14/+14
|
* Add some AR9300 HAL descriptor definition changes.adrian2012-07-091-10/+16
| | | | | | | | | * Add a couple of RX errors; * Add the spectral scan PHY error code; * extend the RX flags to be a 16 bit field, rather than an 8 bit field; * Add a new RX flag. Obtained from: Qualcomm Atheros
* Introduce the EDMA related HAL capabilities.adrian2012-07-092-3/+37
| | | | | | Whilst here, fix a typo in a previous commit. Obtained from: Qualcomm Atheros
* Extend the RX HAL API to include the RX queue identifier.adrian2012-07-097-14/+26
| | | | | | | | | | The AR93xx and later chips support two RX FIFO queues - a high and low priority queue. For legacy chips, just assume the queues are high priority. This is inspired by the reference driver but is a reimplementation of the API and code.
* Extend the debugging flags to include some AR9300 HAL related options.adrian2012-07-091-0/+5
| | | | Obtained from: Qualcomm Atheros
* .. And fix another typo. Grr.adrian2012-07-021-1/+1
|
* Fix another typo.adrian2012-07-021-1/+1
|
* Fix typo.adrian2012-07-021-1/+1
|
* Bring over some further HAL capabilities from the Atheros HAL, as welladrian2012-07-021-2/+23
| | | | | | | | | as an EDMA check function. For the AR9003 and later NICs, different TX/RX DMA and descriptor handling code will be conditional on the EDMA check. Obtained from: Qualcomm Atheros
* Add in some further changes from the AR9300 HAL:adrian2012-07-011-1/+13
| | | | | | | | | | * Add a new ANI variable, for AR9003 and later chips; * The AR9003 and later series chips support two RX queues now, so start down the road of supporting that; * Add some new TX queue types - uAPSD is possible on earlier chips, but PAPRD is relevant to AR9003 and later. Obtained from: Qualcomm Atheros, Linux ath9k
* Migrate the MAC/BB hang structures out from ar5416_misc.h into the HAL.adrian2012-07-012-30/+40
| | | | | The ar9300 HAL also uses these types, so it makes no sense to duplicate them.
* Bring over capabilities for the AR9300 and later HAL.adrian2012-07-011-2/+23
|
* Fix the HAL debugging to only use one bit to mark a message as unmaskable.adrian2012-07-011-1/+1
| | | | Whilst I'm here, remove the duplication of the #define.
* Fix a subtle corner case surrounding the handling of OFDM restart alongadrian2012-06-271-3/+17
| | | | | | | | | | | | | | with AMPDU aggregate delimiters. If there's an OFDM restart during an aggregate, the hardware ACKs the previous frame, but communicates the RXed frame to the hardware as having had CRC delimiter error + OFDM_RESTART phy error. The frame however didn't have a CRC error and since the hardware ACKed the aggregate to the sender, it thinks the frame was received. Since I have no idea how often this occurs in the real world, add a debug statement so trigger whenever this occurs. I'd appreciate an email if someone finds this particular situation is triggered.
* Bring over some new typedefs as part of the AR9300 HAL import.adrian2012-06-271-0/+24
|
* Remove duplicate entries.adrian2012-06-271-33/+0
|
* Bring over the initial 802.11n bluetooth coexistence support code.adrian2012-06-268-12/+856
| | | | | | | | | | | | The Linux ath9k btcoex code is based off of this code. Note this doesn't actually implement functional btcoex; there's some driver glue and a whole lot of verification that is required. On the other hand, I do have the AR9285+BT and AR9287+BT NICs which this code supports.. Obtained from: Qualcomm Atheros, Linux ath9k
* On second thought, let's just set both CRC and PHY errors together onadrian2012-06-241-3/+6
| | | | | | frames that have it and let the upper layer sort it out. PR: kern/169362
* Sometimes the AR5416 sends back radar PHY errors with both the PHY erroradrian2012-06-241-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | and the CRC error bits set. The radar payload is correct. When this happens, the stack doesn't see them PHY error frames and isn't interpreted as a PHY error. So, no radar detection and no radiotap PHY error handling. Now, this may introduce some weird issues if the MAC sends up some other combination of CRC error + PHY error frames; this commit would break that and mark them as PHY errors instead of CRC errors. I may tinker with this a little more to pass radar/early radar/spectral frames up as PHY errors if the CRC bit is set, to restore the previous behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC error rather than PHY error.) Tested on: AR5416, over the air, to a USRP N200 which is generating a large number of a variety of radar pulses. TODO: Test on AR9130, AR9160, AR9280 (and maybe radar pulses on 2GHz on AR9285/AR9287.) PR: kern/169362
* AR9287 tidyups:adrian2012-06-172-80/+82
| | | | | | | | | * Add an OS_A_REG_WRITE() routine - analog writes require a 100usec delay on AR9280 and later, so create a method to do it. * Use it for the AR9287 analog writes. * Re-indent and style(9) the code.
* Add an disabled workaround for the AR9285SE.adrian2012-06-171-0/+19
| | | | | | | | This just requires a little HAL change (add a new config parameter) and some glue in if_ath_pci.c, however I'm leaving this up for someone else to do. Obtained from: Qualcomm Atheros
* Bring over the AR9285 specific PCIe suspend/resume/ASPM workarounds.adrian2012-06-171-2/+55
| | | | Obtained from: Qualcomm Atheros, Linux ath9k
* Shuffle some more fields in ath_buf so it's not too big.adrian2012-06-161-0/+1
| | | | | | This shaves off 20 bytes - from 288 bytes to 268 bytes. However, it's still too big.
* Add the AR9280 workarounds for PCIe suspend/resume.adrian2012-05-261-2/+52
| | | | | | | | | | | These aren't strictly needed at the moment as we're not doing APSM and forcing the NIC in and out of network sleep. But, they don't hurt. Tested: * AR9280 (mini-PCIe) Obtained from: Qualcomm Atheros, Linux ath9k
* Add some AR5416/AR5418 WAR's for power-on and suspend/resume:adrian2012-05-251-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Now that ah_configPCIE is called for both power on and suspend/resume, make sure the right bit(s) are cleared and set when suspending and resuming. Specifically: + force disable/enable the PCIe PHY upon suspend/resume; + reprogram the PCIe WAR register when resuming and upon power-on. * Add a recipe which powers down any PCIe PHY hardware inside the AR5416 (which is the PCI variant) to save on power. I have (currently) no way to test exactly how much power is saved, if any. Tested on: * AR5416 cardbus - although unfortunately pccard/cbb/cardbus currently detaches the NIC upon suspend, I don't think it's a proper test case. * AR5418 PCIe attached to expresscard - since we're not doing PCIe APSM, it's also not likely a full/good test case. In both instances I went through a handful of suspend/resume cycles and ensured that the STA vap reassociated correctly. TODO: * Setup a laptop to simply sit in a suspend/resume loop, making sure that the NIC always correctly comes back; * Start doing suspend/resume tests with actual traffic going on in the background, as I bet this process is all quite racy at the present; * Test adhoc/hostap mode, just to be completely sure it's working correctly; * See if I can jury rig an external power source to an AR5416 to test out whether ah_disablePCIE() works. Obtained from: Qualcomm Atheros
* * According to the reference code, AR_WA_D3_L1_DISBABLE is bit 14.adrian2012-05-251-1/+5
| | | | | | | * Add some other WAR bits (very usefully described too) in preparation for porting over some suspend/resume fixes from ath9k/Atheros. Obtained from: Qualcomm Atheros
* oops - ath_hal_disablepcie is actually destined for another purpose,adrian2012-05-259-20/+29
| | | | | | | not to disable the PCIe PHY in prepration for reset. Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
* Prepare for improved (read: pcie) suspend/resume support.adrian2012-05-254-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Flesh out the pcie disable method for 11n chips, as they were defaulting to the AR5212 (empty) PCIe disable method. * Add accessor macros for the HAL PCIe enable/disable calls. * Call disable on ath_suspend() * Call enable on ath_resume() NOTE: * This has nothing to do with the NIC sleep/run state - the NIC still will stay in network-run state rather than supporting network-sleep state. This is preparation work for supporting correct suspend/resume WARs for the 11n PCIe NICs. TODO: * It may be feasible at this point to keep the chip powered down during initial probe/attach and only power it up upon the first configure/reset pass. This however would require correct (for values of "correct") tracking of the NIC power configuration state from the driver and that just isn't attempted at the moment. Tested: * AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).
* Add some empty DFS methods for AR5210/AR5211 for now, if DFS is enabledadrian2012-05-096-0/+32
| | | | | | | but these don't exist, the code panics. I should really just add or use a DFS HAL capability before doing this, so the methods wouldn't be needed..
* Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t,adrian2012-05-0114-15/+81
| | | | | | | to return whether it was successful. Add placeholder (blank) methods for previous chips, for both it and the 11n extension channel busy call.
* After thinking about this a bit more, let's not keep statistics per-channeladrian2012-04-285-9/+10
| | | | | | | | | | | | | | | in the HAL. That's very memory hungry (32k just for channel statistics) which would be better served by keeping a summary in the ANI state. Or, later, keep a survey history in net80211. So: * Migrate the ah_chansurvey array to be a single entry, for the current channel. * Change the ioctl interface and ANI code to just reference that. * Clear the ah_chansurvey array during channel reset, both in the AR5212 and AR5416 reset path.
* Although not strictly needed, quieten a compiler warning by a user.adrian2012-04-281-1/+1
|
* Extend the ANI code to implement basic channel survey support.adrian2012-04-283-36/+73
| | | | | | | | | | | | | | | | | | | | | | | | * Always call ar5416GetListenTime() * Modify ar5416GetListenTime() to: + don't update the ANI state if there isn't any ANI state; + don't update the channel survey state if there's no active channel - just to be paranoid + copy the channel survey results into the current sample slot based on the current channel; then increment the sample counter and sample history counter. * Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE, rather than a set of percentages. The ANI code wasn't using the percentages anyway. TODO: * Create a new function which fetches the survey results periodically * .. then modify the ANI code to use the pre-fetched values rather than fetching them again * Roll the 11n ext busy function from ar5416_misc.c to update all the counters, then do the result calculation * .. then, modify the MIB counter routine to correctly fetch a snapshot - freeze the counters, fetch the values, then reset the counters.
* Fetch the channel survey code from the HAL.adrian2012-04-282-0/+9
| | | | | This information is currently not being populated by any of the HAL modules.
* Extend the HAL channel survey statistics:adrian2012-04-281-0/+4
| | | | | * include ext_chan_busy; * include ofdm/cck phy error counts, which aren't yet implemented.
* Add an AR5416 PCU DMA stop method, as a check for the AR9130 is needed.adrian2012-04-283-0/+36
| | | | | | | | | | | | The reference driver has a 3ms delay for the AR9130 but I'm not as yet sure why. From what I can gather, it's likely waiting for some FIFO flush to occur. At some point in the future it may be worthwhile adding a WMAC FIFO flush here, but that'd require some side-call through to the SoC DDR flush routines. Obtained from: Atheros
OpenPOWER on IntegriCloud