summaryrefslogtreecommitdiffstats
path: root/sys/dev/ath
Commit message (Collapse)AuthorAgeFilesLines
* Partial merge of the SPDX changeseadler2018-03-1463-16/+142
| | | | | | | These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg
* MFC r327231,r327232:eadler2018-03-051-3/+2
| | | | | | | | | kernel: Fix several typos and minor errors lib: Fix several typos and minor errors - duplicate words - typos - references to old versions of FreeBSD
* MFC r303891, r303892:pfg2016-09-082-4/+4
| | | | | | | | sys: replace comma with semicolon when pertinent. Uses of commas instead of a semicolons can easily go undetected. The comma can serve as a statement separator but this shouldn't be abused when statements are meant to be standalone.
* [ath] obey the short-GI vap config flag when transmitting.adrian2016-07-071-2/+5
| | | | | | | | | | This makes 'ifconfig wlanX -shortgi' work correctly. Tested: * AR9380, STA mode Approved by: re (gjb)
* [ath] fix comments!adrian2016-06-231-2/+2
| | | | | | | | | | | I keep asking myself "what do these fields mean" and so now I've clarified it for myself. Tested: * Reading the comments, going "a-ha!" a couple times. Approved by: re (gjb)
* [ath] fix TX throughput for EDMA chips by pushing more into the TX FIFO.adrian2016-06-211-20/+70
| | | | | | | | | | | | | | | | | | | | | | | | It turns out that getting decent performance requires stacking the TX FIFO a little more aggressively. * Ensure that when we complete a frame, we attempt to push a new frame into the FIFO so TX is kept as active as it needs to be * Be more aggressive about batching non-aggregate frames into a single TX FIFO slot. This "fixes" TDMA performance (since we only get one TX FIFO slot ungated per DMA beacon alert) but it does this by pushing a whole lot of work into the TX FIFO slot. I'm not /entirely/ pleased by this solution, but it does fix a whole bunch of corner case issues in the transmit side and fix TDMA whilst I'm at it. I'll go revisit transmit packet scheduling in ath(4) post 11. Tested: * AR9380, STA mode * AR9580, hostap mode * AR9380, TDMA client mode Approved by: re (hrs)
* [ath] fix EDMA TX buffer flags for use when retransmitting frames.adrian2016-06-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This started showing up when doing lots of aggregate traffic. For TDMA it's always no-ACK traffic and I didn't notice this, and I didn't notice it when doing 11abg traffic as it didn't fail enough in a bad way to trigger this. This showed up as the fifo depth being < 0. Eg: Jun 19 09:23:07 gertrude kernel: ath0: ath_tx_edma_push_staging_list: queued 2 packets; depth=2, fifo depth=1 Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe000385f068, start=1, end=1 Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now 0 (1) Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe0003866fe8, start=0, end=1 Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now -1 (0) So, clear the flags before adding them to a TX queue, so if they're re-added for the retransmit path it'll clear whatever they were and not double-account the FIFOEND flag. Oops. Tested: * AR9380, STA mode, 11n iperf testing (~130mbit) Approved by: re (delphij)
* [ath] add support for batching frames to the general TX queues.adrian2016-06-191-51/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out the frame scheduling policies (eg DBA_GATED) operate on a single TX FIFO entry. ASAP scheduling is fine; those frames always go out. DBA-gated sets the TX queue ready when the DBA timer fires, which triggers a beacon transmit. Normally this is used for content-after-beacon queue (CABQ) work, which needs to burst out immediately after a beacon. (eg broadcast, multicast, etc frames.) This is a general policy that you can use for any queue, and Sam's TDMA code uses it. When DBA_GATED is used and something like say, an 11e TX burst window, it only operates on a single TX FIFO entry. If you have a single frame per TX FIFO entry and say, a 2.5ms long burst window (eg TDMA!) then it'll only burst a single frame every 2.5ms. If there's no gating (eg ASAP) then the burst window is fine, and multiple TX FIFO slots get used. The CABQ code does pack in a list of frames (ie, the whole cabq) but up until this commit, the normal TX queues didn't. It showed up when I started to debug TDMA on the AR9380 and later. This commit doesn't fix the TDMA case - that's still broken here, because all I'm doing here is allowing 'some' frames to be bursting, but I'm certainly not filling the whole TX FIFO slot entry with frames. Doing that 'properly' kind of requires me to take into account how long packets should take to transmit and say, doing 1.5 or something times that per TX FIFO slot, as if you partially transmit a slot, when it's next gated it'll just finish that TX FIFO slot, then not advance to the next one. Now, I /also/ think queuing a new packet restarts DMA, but you have to push new frames into the TX FIFO. I need to experiment some more with this because if it's really the case, I will be able to do TDMA support without the egregious hacks I have in my local tree. Sam's TDMA code for previous chips would just kick the TXE bit to push along DMA again, but we can't do that for EDMA chips - we /have/ to push a new frame into the TX FIFO to restart DMA. Ugh. Tested: * AR9380, STA mode * AR9380, hostap mode * AR9580, hostap mode Approved by: re (gjb)
* [ath] don't debug RX EDMA descriptors that are not yet complete.adrian2016-06-171-2/+2
| | | | Approved by: re@ (gjb)
* [ath] add a placeholder event for debuggin EDMA TX FIFO push events.adrian2016-06-091-0/+8
| | | | | | | Some later code I'll commit pushes lists of frames into the EDMA TX FIFO, rather than a single frame at a time. The CABQ code already pushes frame lists, but it turns out we should actually be doing it in general or performance tanks. :(
* [ath] report node queue overflows.adrian2016-06-091-0/+3
| | | | I need to also update athstats to report this too.
* [ath] remove now unused parameters.adrian2016-06-041-4/+0
| | | | | These will move to being part of the driver btcoex stuff I'm working on, since the HAL doesn't know what to do with them.
* [ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.adrian2016-06-041-0/+4
| | | | It just stomps all; which is enough for some testing.
* [ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods.adrian2016-06-041-2/+1
|
* [ath] correctly shift the QCA9565 LNA config into the mci config variable.adrian2016-06-021-2/+6
| | | | | | Tested: * QCA9565, STA + BT mode
* Fix kernel build. Improper definition location of a variable.gnn2016-06-021-1/+2
|
* [ath] commit initial bluetooth coexistence support for the MCI NICs.adrian2016-06-027-63/+811
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the initial framework to call into the MCI HAL routines and drive the basic state engine. The MCI bluetooth coex model uses a command channel between wlan and bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things. This means the wlan and bluetooth chip exchange a lot more information and signaling, even at the per-packet level. The NICs in question can share the input LNA and output PA on the die, so they absolutely can't stomp on each other in a silly fashion. It also allows for the bluetooth side to signal when profiles come and go, so the driver can take appropriate control. There's also the possibility of dynamic bluetooth/wlan duty cycle control which I haven't yet really played with. It configures things up with a static "wlan wins everything" coexistence, configures up the available 2GHz channel map for bluetooth, sets a static duty cycle for bluetooth/wifi traffic priority and drives the basics needed to keep the MCI HAL code happy. It doesn't do any actual coexistence except to default to "wlan wins everything", which at least demonstrates that things do indeed work. Bluetooth inquiry frames still trump wifi (including beacons), so that demonstrates things really do indeed seem to work. Tested: * AR9462 (WB222), STA mode + bt * QCA9565 (WB335), STA mode + bt TODO: * .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard. * It doesn't do the initial BT side calibration, which requires a WLAN chip reset. I'll fix up the reset path a bit more first before I enable that. * The 1-ant and 2-ant configuration bits aren't being set correctly in if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit. * It's not enabled by default for WB222/WB225 even though I believe it now can be - I'll chase that up in a subsequent commit. Obtained from: Qualcomm Atheros, Linux ath9k
* [ath_hal] add extra MCI definitions used by the later chips (QCA9565/Aphrodite).adrian2016-06-011-0/+21
| | | | Obtained from: Linux ath9k
* [ath_hal] rename the MCI state info routine.adrian2016-05-311-1/+1
| | | | It's not /really/ "get state".
* [ath_hal] add support for setting the azimuth timestamp in the outgoing TX ↵adrian2016-05-311-0/+6
| | | | | | payload. FYI: This is an unsupported/deprecated feature of the 11n hardware.
* [ath_hal] reserve a HAL_TXDESC_ bit for azimuth TX timestamp requests.adrian2016-05-311-1/+2
|
* [ath_hal] migrate the bluetooth definitions out from ah.h / ↵adrian2016-05-311-131/+1
| | | | | | | | | | | ar9300_freebsd_inc.h. The eventual MCI driver side of things needs the MCI bits to live in the HAL API so we can get to them. Tested: * QCA9565, STA mode + bluetooth
* [ath_hal] add bluetooth coexistence definitions for both legacy and MCI.adrian2016-05-311-0/+503
| | | | | | | | The legacy bits are just from ah.h; the MCI bits are from the ar9300 HAL "freebsd" extras. A subsequent commit will include ah_btcoex.h into ah.h and remove the older defintions.
* [ath] add BTCOEX debug section; modify DPRINTF() to take a no-arg format string.adrian2016-05-311-2/+3
| | | | | | Tested: * QCA9565, STA mode
* [ath] add WB335 btcoex for initial testing.adrian2016-05-281-0/+64
| | | | | | | | | | | | | | | | This is like the WB222 coexistence (ie, "MCI", a message bus inside the chip), and it's currently a cut/paste so I can start using it to flesh out the differences with WB222. It doesn't completely /do/ bluetooth coexistence, because it turns out I need to add some contigmalloc'ed buffers to the btcoex path for this type of hardware. I'm putting this work in the "people would like to see functioning-ish btcoex before FreeBSD-11" bucket because I see this as "broken". Tested: * QCA9535 (WB335) NIC, BT + 2GHz STA
* [ath] convert recent changes over to HAL format.adrian2016-05-201-5/+6
| | | | | | | | | This is needed to compile the ath tools, that includes this code to run in userland. Tested: * Carambola 2, AR9331, STA mode
* ath: refactor/split getchannels() method.avos2016-05-192-211/+272
| | | | | | | | | | | Split getchannels() method in ath_hal/ah_regdomain.c into a subset of functions for better readability. Note: due to different internal structure, it cannot use ieee80211_add_channel*() (however, some parts are done in a similar manner). Differential Revision: https://reviews.freebsd.org/D6139
* dev/ath: minor spelling fixes in comments.pfg2016-05-0226-43/+43
| | | | | | No functional change. Reviewed by: adrian
* [ath] initialise do_ldpc to 0.adrian2016-04-291-0/+1
| | | | | | | | | | | | | | | I .. can't believe I missed this. This showed up because the AP was TX'ing LDPC to an iwm(4) chipset, which didn't advertise LDPC and doesn't /accept/ LDPC. Amusingly, all the two other FreeBSD 11n parts I had tested with (AR9380, Intel 7260) and I completely forgot to test on ye olde hardware. That'll teach me. Tested: * AR9580 (AP) - Intel 7260 (STA), AR9380 (STA), Intel 6205 (STA)
* [ath] Add LDPC transmit support.adrian2016-04-291-0/+33
| | | | | | | | | | | | | | | LDPC adds better transmit reliability if both ends support it. You in theory can do both STBC and LDPC at the same time. If I see issues I'll disable it. * Only enable it if both ends of a connection negotiate it. * Disable it if any rate is non-11n. * Count both LDPC TX and STBC TX. Tested: * AR9380, STA mode
* [ath] turn the BA hardware bug back into a printf().adrian2016-04-291-1/+1
| | | | | I saw this happen a couple of times and all I saw was a dump of the transmit descriptors. Log the message for now so I can see whta happened.
* [ath] Add counters for STBC TX and LDPC TX.adrian2016-04-292-1/+9
| | | | | This is a big no-op until the TX path changes to enable LDPC TX are added.
* [ath] add LDPC capability support and LDPC RX support.adrian2016-04-262-0/+18
| | | | | | | | | | | | | | | This enables LDPC receive support for the AR9300 chips that support it. It'll announce LDPC support via net80211. Tested: * AR9380, STA mode * AR9331, (to verify the HAL didn't attach it to a chip which doesn't support LDPC.) TODO: * Add in net80211 machinery to make this configurable at runtime.
* [ath] obey the STBC flag setting in iv_flags_htadrian2016-04-261-4/+9
| | | | | | | | Add support for the FHT_STBC_TX flag in iv_flags_ht, so it'll now obey the per-vap ifconfig stbctx flag. This means that we can do STBC TX on one vap and not another VAP. (As well as STBC RX on said vap; that changes the HTCAP announcement.)
* net80211: replace internal LE_READ_*/LE_WRITE_* macro with systemavos2016-04-204-19/+10
| | | | | | | | | | | | | | | | | le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D6030
* Cleanup unnecessary semicolons from the kernel.pfg2016-04-102-2/+1
| | | | Found with devel/coccinelle.
* [ath] Only process beacon frames for the IBSS/BSSID if appropriate.adrian2016-04-091-64/+81
| | | | | | | | | | | | | | | | | | * Don't use arbitrary frames for the average RX RSSI - only frames from the current BSSID * Don't log / do the syncbeacon logic for another BSSID and definitely don't do the syncbeacon call if we miss beacons outside of STA mode. * Don't do the IBSS merge bits if the current node plainly won't ever match our current BSS (ie, the IBSS doesn't have to match, but all the same bits that we check in ieee80211_ibss_merge() have to match.) Tested: * ath(4), AR9380, IBSS mode, surrounded by a lot of IBSS 11ac networks. Sponsored by: Eva Automation, Inc.
* [net80211] migrate the time_* macros to ieee80211_* namespace.adrian2016-03-301-1/+1
| | | | | | | It turns out that these will clash very annoyingly with the linux macros in the linuxkpi layer, so let the wookie^Wlinux win. The only user that I can find is ath(4), so fix it there too.
* Remove taskqueue_enqueue_fast().jhb2016-03-011-1/+1
| | | | | | | | | | taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compat shim to go. Submitted by: Howard Su <howard0su@gmail.com> Reviewed by: sephe Differential Revision: https://reviews.freebsd.org/D5131
* Fix up the ath(4) device names for QCA chipsets.adrian2016-02-292-31/+28
| | | | Submitted by: Tobias Kortkamp <t@tobik.me>
* [ath] remove the inline version of the register access macros.adrian2016-01-032-16/+13
| | | | | | | | | | These are going to be much more efficient on low end embedded systems but unfortunately they make it .. less convenient to implement correct bus barriers and debugging. They also didn't implement the register serialisation workaround required for Owl (AR5416.) So, just remove them for now. Later on I'll just inline the routines from ah_osdep.c.
* ... and that would've never worked. Sorry!adrian2016-01-021-8/+3
| | | | (Note: everything I tested on locally has ATH_DEBUG / AH_DEBUG set.)
* [ath] add explicit bus barriers.adrian2016-01-022-2/+33
| | | | | | | | | | | | | | | | | | | The ath hal and driver code all assume the world is an x86 or the bus layer does an explicit bus flush after each operation (eg netbsd.) However, we don't do that. So, to be "correct" on platforms like sparc64, mips and ppc (and maybe ARM, I am not sure), just do explicit barriers after each operation. Now, this does slow things down a tad on embedded platforms but I'd rather things be "correct" versus "fast." At some later point if someone wishes it to be fast then we should add the barrier calls to the HAL and driver. Tested: * carambola 2 (AR9331.)
* fix ht/40 configuration for ar9331 (hornet).adrian2015-11-302-6/+6
| | | | | | | | | | | | | | | | The synth programming here requires the real centre frequency, which for HT20 channels is the normal channel, but HT40 is /not/ the primary channel. Everything else was using 'freq', which is the correct centre frequency, but the hornet config was using 'ichan' to do the lookup which was also the primary channel. So, modify the HAL call that does the mapping to take a frequency in MHz and return the channel number. Tested: * Carambola 2, AR9331, tested both HT/20 and HT/40 operation.
* [ath_hal] use the correct revision information for QCA953x.adrian2015-11-282-4/+2
| | | | | | | | | This probe/attaches correctly in my local branch and now displays a useful message: ath0: <Qualcomm Atheros QCA953x> at mem 0x18100000-0x1811ffff irq 0 on nexus0 ... ath0: AR9530 mac 1280.0 RF5110 phy 0.0
* * Add device string for QCA955x (scorpion);adrian2015-11-282-0/+7
| | | | * Add device ID and device string for QCA953x (honeybee).
* wrap in ATH_DEBUG.adrian2015-11-281-2/+2
| | | | Thanks sparc64 build!
* [ath] conditionally print out the rate series information if ATH_DEBUG_XMIT ↵adrian2015-11-271-3/+4
| | | | is set.
* [ath] listen to all beacons in IBSS and software beacon miss.adrian2015-11-251-3/+7
| | | | | | | | | | | | | | | | I added MYBEACON support a while ago to listen to beacons that are only for your configured BSSID. For AR9380 and later NICs this results in a lot less chip wakeups in station mode as it then only shows you beacons that are destined to you. However in IBSS mode you really do want to hear all beacons so you can do IBSS merges. Oops. So only use MYBEACON for STA + not-scanning, and just use BEACON for the other modes it used to use BEACON for. This doesn't completely fix IBSS merges though - there are still some conditions to chase down and fix.
* [ath] migrate ioctl and busdma memory operations out into separate source files.adrian2015-11-249-507/+836
| | | | | | | This should be a big no-op pass; and reduces the size of if_ath.c. I'm hopefully soon going to take a whack at the USB support for ath(4) and this'll require some reuse of the busdma memory code.
OpenPOWER on IntegriCloud