summaryrefslogtreecommitdiffstats
path: root/sys/contrib/dev
Commit message (Collapse)AuthorAgeFilesLines
* MFC r303322,303326,303327,303345,303413,303416,303418,303557sbruno2016-08-017-45527/+122225
| | | | | | | Update iwm(4) and iwmfw(4) to current in order to stabilize and improve functionality. Approved by: re (gjb)
* [ath] implement TX queue configuration extensions for the AR9380 HAL.adrian2016-06-201-13/+33
| | | | | | | | | | | | Among other things, this introduces the idea of DBA-gated queues that aren't the CABQ. The TDMA support requires this. Tested: * AR9580 (hostap mode) * AR9380 (sta mode) Approved by: re (gjb)
* [ath_hal] modify the xmit code to use temporary variables for setting ↵adrian2016-06-081-38/+23
| | | | | | | | | qmisc/dmisc. This is in preparation for some other TDMA fixes which will hopefully end with having working TDMA. But, it does avoid lots of read/modify/writes in the txq setup path.
* [ath_hal] add a _S so FSP (frame scheduling policy) can be set/read via ↵adrian2016-06-081-0/+1
| | | | SM/MS macros.
* [ath_hal] correctly initialise the CAB queue default valueadrian2016-06-081-5/+23
| | | | | | | * Allow readyTime to just be programmed in directly * The beacon interval and all of the beacon timing sysctl's are in TU, not TSF. So, we were doing the wrong math on the CAB programming in the first place.
* [ath_hal] initialise ah_beaconInterval when the AP/IBSS/TDMA beacon is setup.adrian2016-06-082-2/+3
|
* [ath_hal] add AR9462 (jupiter) RX gain / XLNA programming.adrian2016-06-053-0/+60
| | | | | | | | | | | | | | This seems to make 5G work better. It doesn't fix powersave handling though, that still sees the PHY get stuck during initial calibration and everything goes pear shaped. I'll look into that later. Tested: * QCAFN222 NIC, STA mode, 5GHz Obtained from: Linux ath9k
* [ath_hal] Add Jupiter 2.1 (AR9462 mac 640.3) support.adrian2016-06-051-3/+32
| | | | | | | | | | | | | | | Turns out I wasn't even initialising or programming a lot of stuff for the AR9462 2.1 chip. Oops. This mostly gets it working. powersave scan results in some pretty hilarious NFcal hangs and I don't see beacons reliably. There are still some xlna gain tables missing that ath9k has; I'll follow up with some fixes and then see if the QCAFN222 NIC I have tests this path. Tested: * QCAFN222 NIC, STA mode, 2GHz and 5GHz
* [ath_hal] teach the reset path(s) about Jupiter 2.1.adrian2016-06-051-3/+4
| | | | | This was just .. not programming in things, and thus large chunks of the radio wouldn't work. Notably, 5GHz didn't work.
* [ath_hal] convert the MCI code over to work on Jupiter 2.1.adrian2016-06-051-7/+7
| | | | | (Note: jupiter 1.0 was emulation / test silicon, and was never released in production. So, yes, AR_SREV_JUPITER() would really be fine.)
* [ath_hal] Make the AR9462 2.0 initvals from ath9k compile.adrian2016-06-051-19/+20
| | | | | The (upcoming) semi-working AR9462 2.1 support uses the 2.0 initvals where appropriate, and those need to at least compile under freebsd.
* [ath_hal] add STOMP_AUDIO for AR9462/QCA9565.adrian2016-06-041-0/+6
| | | | Obtained from: Linux ath9k
* [ath_hal] add azimuth timestamp payload marking for AR9380 and later chips.adrian2016-06-011-0/+1
|
* [ath_hal] implement shared PA handling checks, based on ath9k.adrian2016-06-011-8/+16
| | | | | | | | | | | | | | These are apparently conditional on there being a shared PA/LNA, which at least on AR9462/QCA9535 devices I have isn't a thing. I'm .. not yet sure which devices it /is/ a thing, so I'll come back to that. Tested: * QCA9565 STA + bluetooth Obtained from: Linux ath9k
* [ath_hal] add MCI bits from ath9k for QCA9565adrian2016-06-011-21/+106
| | | | | | | | | | | | | | | | | | | | | * Add extra debugging - the weights debugging is really useful to ensure things are programmed into the wlan coexistence table. The weights are what traffic priority each of the various modes get (tx, tx-high-priority, rx-beacon, etc) if they're all zero, things work very poorly. * Add in coex init routines from ath9k for AR9462 and QCA9565 1ANT and 2ANT. This control things like beacon stomping, ACK handling, antennas, PA/LNA shared, etc. * Some ancillary bits. TODO: * There's some conditional stuff around MCI_ANT_ARCH_PA_LNA_SHARED() in ath9k which doesn't always enable force-on LNA. That'll have to be examined and merged in as appropriate. Obtained from: linux ath9k
* [ath_hal] add support for QCA9565 for configuring the bluetooth antenna LNA ↵adrian2016-06-011-3/+34
| | | | | | | | | | | | | diversity. Notably, this also sets AR_BTCOEX_WL_LNADIV to FORCE_ON, so LNA diversity is always enabled and under control of the wifi chip. Tested: * QCA9565, STA + bluetooth mode Obtained from: Linux ath9k
* [ath_hal] Allow the BT antenna diversity option to be enabled for QCA9565.adrian2016-06-011-2/+4
| | | | Obtained from: Linux ath9k
* [ath_hal] add QCA9565 bluteooth antenna control.adrian2016-06-011-2/+30
| | | | | | | | | | | | This configures the LNA antenna diversity control, which should be on if wlan owns the LNA for bluetooth coexistence. Otherwise, make sure it's off. I think this is eventually intended to allow 1-antenna bluetooth + wifi setups for QCA9565, but I'm not sure where that's actually configured in ath9k. Obtained from: Linux ath9k
* [ath_hal] add extra debugging for MCI interrupts.adrian2016-06-011-0/+2
|
* [ath_hal] rename the MCI state info routine.adrian2016-05-311-1/+10
| | | | It's not /really/ "get state".
* [ath_hal] add QCA9565 and MCI related registers.adrian2016-05-311-0/+29
| | | | | | This is required for upcoming MCI fixes. Obtained from: Linux ath9k
* [ath_hal] migrate the bluetooth definitions out from ah.h / ↵adrian2016-05-311-357/+0
| | | | | | | | | | | 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] ensure the right methods / options get overridden for MCI bluetooth coexadrian2016-05-311-5/+5
| | | | | | | | | | | | | | | It turns out that the srev checks can't be done in the early attach in ar9300_freebsd.c, because the poweron and srev check hasn't yet happened. So: * Re-add the MCI overrides in attach * Add QCA9565 (Aphrodite) check for the LNA diversity stuff. Tested: * QCA9565, STA mode + bluetooth
* Merge ACPICA 20160527.jkim2016-05-2713-59/+112
| | | | Relnotes: yes
* Revert AccessWidth/BitOffset support for AcpiHwWrite() and AcpiHwRead() forjkim2016-04-301-195/+30
| | | | | | | | | | | | | | | now. The following upstream commits are reverted from hwregs.c: https://github.com/acpica/acpica/commit/96ece05 https://github.com/acpica/acpica/commit/3d8583a https://github.com/acpica/acpica/commit/48eea5e https://github.com/acpica/acpica/commit/0a212c3 https://github.com/acpica/acpica/commit/41f6aef https://github.com/acpica/acpica/commit/26434b9 https://github.com/acpica/acpica/commit/c23034a https://github.com/acpica/acpica/commit/c49a751 Note this commit will be reverted when the upstream fixes the code properly.
* Fix build without ACPI_DEBUG.jkim2016-04-271-0/+1
|
* Merge ACPICA 20160422.jkim2016-04-27334-12777/+19023
|\
* | [rtwn] add rtwn firmware.adrian2015-12-313-0/+738
| | | | | | | | Submitted by: kevlo
* | Add initial ar9300 HAL support for the spectral scan mode.adrian2015-12-023-9/+29
| |
* | Adjust a comment; we now support these embedded boards!adrian2015-12-011-1/+1
| |
* | Fix the buildngie2015-11-301-0/+2
| | | | | | | | | | | | ichan is only used if AH_DEBUG_ALQ if defined Pointyhat to: adrian
* | fix ht/40 configuration for ar9331 (hornet).adrian2015-11-301-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | add missing initvals.adrian2015-11-291-0/+1420
| | | | | | | | Sorry y'all.
* | Add initial support for the QCA953x SoC (honeybee) wifi.adrian2015-11-298-41/+260
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a 2x2 2GHz 802.11n part. It works enough at the moment to bring up, scan and associate. I haven't started using this as a day to day AP. The specifics: * add honeybee initvals * add in changes; a mix from the QCA HAL and ath9k; * fix a bug in AR_SREV_AR9580_10_OR_LATER(), which is only used for one capability check and we don't even implement it - so it's a big no-op. Shady things: * ath9k has the "platform data" define the 25/40MHz clock. This HAL .. doesn't. Honeybee gets hard-coded to 25MHz which it likely shouldn't be. I'll have to go and identify/fix those. Tested: * Qualcomm Atheros AP143 reference design board. Obtained from: Qualcomm Atheros; Linux ath9k
* | u32 -> uint32_t.adrian2015-11-291-3/+3
| |
* | [ath_hal] add AR9461 (jupiter) 2.1 support.adrian2015-11-294-9/+1583
| | | | | | | | Obtained from: Linux ath9k
* | ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.adrian2015-11-094-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now the only way to force a cold reset is: * The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold. Trouble is, cold resets take quite a bit longer than warm resets. However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc. The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future. This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later. It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.
* | Flip on fast frames support for AR5416 and AR9300 series NICs.adrian2015-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was off because the net80211 aggregation code was using the same state pointers for both fast frames and ampdu tx support which led to some pretty unfortunate panic-y behaviour. Now that net80211 doesn't panic, let's flip this back on. It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates of fast frames; that'll come next. It's a pre-requisite to supporting AMSDU + AMPDU anyway, which actually speeds things up quite considerably (think packing lots of little ACK frames into a single AMSDU.) Tested: * QCA955x SoC, AP mode * AR5416, STA mode * AR9170, STA mode (with local fast frame patches)
* | Add an initial driver for the AR9170 series draft-11n hardware fromadrian2015-09-263-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atheros. Thanks to OpenBSD for providing a driver based on the original Atheros open source driver circa 2008. This uses the early, pre-carl9170 atheros provided firmware. It only supports 11bg at the moment. I've not tested it with 11a (and so the TX rate control logic may be slightly wrong!) so if you do have the dual-band version of this hardware please do let me know. Tested: * AR9170, TP-Link WN821N 2GHz. TODO: * Hook this up to a non-module build.
* | Fix compilation error on gcc-5.2.0 - it now warns on non-paranthen'edadrian2015-08-301-2/+2
| | | | | | | | | | | | | | | | logical negation when used in this fashion. Tested: * compile only
* | Merge ACPICA 20150818.jkim2015-08-2669-658/+1038
| |
* | Import OpenBSD's iwm WiFi driver for Intel 3160/7260/7265.rpaulo2015-08-084-0/+45566
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are still several bugs, but I've been using it for a while now. Thanks to all the testers and to Adrian for his help with this driver. This driver isn't connected to the build yet, but it will be soon. There's no MFC planned because the driver isn't very stable yet. Reviewed by: adrian Obtained from: https://github.com/rpaulo/iwm Tested by: adrian, gjb, dumbbell (others that I forgot). Relnotes: yes
* | Add a missing method - ath_hal_settsf64().adrian2015-08-051-0/+13
| | | | | | | | This is required for TDMA slave mode.
* | Add TXOP enforce support to the AR9300 HAL.adrian2015-08-051-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | This is required for (more) correct TDMA support. Without it, the code tries to calculate the required guard interval based on the current rate, and since this is an 11n NIC and people try using 11n, it calls ath_hal_computetxtime() on an 11n rate which then panics. This doesn't fix TDMA slave mode on AR9300 - it just makes it have one less bug. Reported by: Berislav Purgar <bpurgar@gmail.com>
* | Merge ACPICA 20150717.jkim2015-07-2286-1295/+2897
|\ \ | |/
* | Quieten the scorpion SoC/WMAC reset path. Stuff the non-error stuffadrian2015-07-041-3/+3
| | | | | | | | under HALDEBUG().
* | Merge ACPICA 20150619.jkim2015-06-18146-782/+1645
|\ \ | |/
* | MFV: r283965jkim2015-06-032-47/+73
| | | | | | | | | | | | - Update GUIDs for new NFIT tables. - Fix ill-formed GUID strings for NFIT tables. - Fix a possible fault when performing a UUID search.
* | Add support for the tuning cap for Hornet/AR9331 boards.adrian2015-05-231-1/+9
| | | | | | | | | | | | | | | | | | | | | | This dramatically improves RX sensitivity and behaviour on the AR9331 hardware I have, including the Carambola 2. Tested: * AR9331, Carambola 2 board Submitted by: Zilvinas Valinskas <zilvinas.valinskas@gmail.com>
* | Merge ACPICA 20150515.jkim2015-05-1854-391/+3759
|\ \ | |/
OpenPOWER on IntegriCloud