FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F11.0 2016-06-02T00:51:36Z 2016-06-02T00:51:36Z Adrian Chadd adrian@FreeBSD.org 2016-06-02T00:51:36Z urn:sha1:bcf5fc498ab9c73f64975f5b227c3be1d9e81f22 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 2015-12-02T05:36:45Z Adrian Chadd adrian@FreeBSD.org 2015-12-02T05:36:45Z urn:sha1:204c8e00deb4eeca4afd45e8eb9bb33329bde2ce 2015-11-24T03:42:58Z Adrian Chadd adrian@FreeBSD.org 2015-11-24T03:42:58Z urn:sha1:b45de1ebcd39e2170350109d199abf7abb1bbb02 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. 2015-01-03T03:35:18Z Warner Losh imp@FreeBSD.org 2015-01-03T03:35:18Z urn:sha1:4906cdc8c5d161f74ab36bb5792ac0706d182c11 CWARNFALGS.$file centrally so we don't have to have it in all the places. Remove a few warning flags that are no longer needed. Also, always use -Wno-unknown-pragma to (hopefully temporarily) work around #pragma ident in debug.h in the opensolaris code. Remove some stale warning suppression that's no longer necessary. 2013-12-28T23:12:32Z Dimitry Andric dim@FreeBSD.org 2013-12-28T23:12:32Z urn:sha1:fabb883e26b3d057ea2d7ae6a748d385ad290bc1 MFC after: 3 days 2013-06-12T14:52:57Z Adrian Chadd adrian@FreeBSD.org 2013-06-12T14:52:57Z urn:sha1:216ca2346fff3a53770769146cf8a59a3f8c7b95 The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM 2013-06-07T09:02:02Z Adrian Chadd adrian@FreeBSD.org 2013-06-07T09:02:02Z urn:sha1:b70f530bc7a43b0310cb9686a4b80a6d97577d1e for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC. The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285. The code in if_ath_btcoex.c sets up the initial hardware mapping and coexistence configuration. There's nothing special about it - it's static; it doesn't try to configure bluetooth / MAC traffic priorities or try to figure out what's actually going on. It's enough to stop basic bluetooth traffic from causing traffic stalls and diassociation from the wireless network. To use this code, you must have the above NIC. No, it won't work for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards. Then you set a kernel hint before boot or before kldload, where 'X' is the unit number of your AR9285 NIC: # kenv hint.ath.X.btcoex_profile=wb195 This will then appear in your boot messages: [100482] athX: Enabling WB195 BTCOEX This code is going to evolve pretty quickly (well, depending upon my spare time) so don't assume the btcoex API is going to stay stable. In order to use the bluetooth side, you must also load in firmware using ath3kfw and the binary firmware file (ath3k-1.fw in my case.) Tested: * AR9280, no interference * WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries were enough to cause traffic stalls and disassociations. This has stopped with the btcoex profile code. TODO: * Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence is enabled. No, I don't know why. It's likely some kind of bug to do with the AR3011 sending bluetooth coexistence signals whilst the device is asleep. Since we don't actually sleep the MAC just yet, it shouldn't be a problem. That said, to be totally correct: + ASPM should be disabled - upon attach and wakeup + The PCIe powersave HAL code should never be called Look at what the ath9k driver does for inspiration. * Add WB197 (AR9287+AR3012) support * Add support for the AR9485, which is another combo like the AR9285 * The later NICs have a different signaling mechanism between the MAC and the bluetooth device; I haven't even begun to experiment with making that HAL code work. But it should be a lot more automatic. * The hardware can do much more interesting traffic weighting with bluetooth and wifi traffic. None of this is currently used. Ideally someone would code up something to watch the bluetooth traffic GPIO (via an interrupt) and then watch it go high/low; then figure out what the bluetooth traffic is and adjust things appropriately. * If I get the time I may add in some code to at least track this stuff and expose statistics. But it's up to someone else to experiment with the bluetooth coexistence support and add the interesting stuff (like "real" detection of bulk, audio, etc bluetooth traffic patterns and change wifi parameters appropriately - eg, maximum aggregate length, transmit power, using quiet time to control TX duty cycle, etc.) 2013-05-02T07:05:34Z Adrian Chadd adrian@FreeBSD.org 2013-05-02T07:05:34Z urn:sha1:0e468be195cc5bb4bdb9b0bd6ba60843b044e810 Tested: * make universe (honest!) 2013-03-14T00:27:53Z Adrian Chadd adrian@FreeBSD.org 2013-03-14T00:27:53Z urn:sha1:cac48304a8e9804d60f592174e4676cb28a686f9 with clang. I'll work on this soon. 2013-03-12T02:54:49Z Adrian Chadd adrian@FreeBSD.org 2013-03-12T02:54:49Z urn:sha1:0200f963e7fdf05fac46a3490d5e3b031d8cb5d7 this public.