In uCode, BT state machine need to receive open envlope
command before perform calibration; followed by close envlope
command to move to next stage.
Since Linux has two separated uCode, one for init and the second
one for runtime; we use open envlope commands for init uCode to
indicate we are ready to perform calibration operation.
But for runtime uCode, we are not doing any init calibration,
so we issue open/close envlope commands to force uCode move to
"BT COEX ON" state.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
We're now ready to start using multiple contexts.
We do this by keeping track of the valid interface
types per context (exclusive [ibss] and normal)
and checking which context is "free" when a new
interface is added.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
It is necessary that the PAN context always
use the same beacon interval as the BSS
context unless it is in dual-station mode,
ie. the PAN context is a station as well,
so implement that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The PAN context requires also getting
RXON timing when we send an unassociated
RXON in some cases.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Sometimes we need to send RXON timing even
when we don't have a virtual interface yet,
so pass the context and allow passing one
without a virtual interface pointer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
In order for the microcode to be able to handle
multiple interfaces, we need to give it the PAN
parameters that state how to allocate the time
between the two interfaces. Do this, and update
it wherever necessary.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Newer AGN microcode requires know the beacon
before starting the AP so that it can start
beaconing right away. Implement that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The PAN functionality requires us to send the
timing including a valid DTIM period to the
microcode before associating, so request this
data from mac80211 and send it to the device.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Frames for different contexts need to be put
on different queues, and multicast after DTIM
frames have a special queue yet which also
depends on the context, so put all this into
the context.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since we have the beacon context now, we no
longer need to rely on iw_mode but can check
the beacon context interface's type. However,
that check must be in the work item instead
due to locking constraints (mutex must be
held when dereferencing beacon_ctx pointer).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Detect whether or not the ucode is PAN
capable and adjust the valid contexts
accordingly. To be able to do this, add
the PAN context to the array as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Define the new host commands and notifications
REPLY_WIPAN_PARAMS
REPLY_WIPAN_RXON
REPLY_WIPAN_RXON_TIMING
REPLY_WIPAN_RXON_ASSOC
REPLY_WIPAN_QOS_PARAM
REPLY_WIPAN_WEPKEY
REPLY_WIPAN_P2P_CHANNEL_SWITCH
REPLY_WIPAN_NOA_NOTIFICATION
and their corresponding structures along with the PAN
station flag, the PAN AP sta ID and new dev types for
the second context.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Only one context can be beaconing at a time,
but we need to track which one. Introduce a
new variable priv->beacon_ctx to do that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
A lot of HT configuration semantically belongs into
the context, even if right now it will never be
different between contexts. Move it so we're better
prepared for future changes in mac80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Sometimes we only pass around station
pointers but need to find the context
they belong to, so store it in there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since the default context is initialised to zero,
and the default flags are zero, no more code is
needed to initialise them right now, but another
context can have different default flags.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
HW crypto needs to be aware of the context, and there
are different command IDs for the WEP keys per context,
so move the key tracking variables and command IDs into
the context structure.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Each context needs to use a different AP sta
ID, so we need to move that into the context
struct instead of hardcoding it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The dwell time should at least fit into all
context's beacon intervals.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
iwlwifi occasionally needs to find the virtual
interface pointer to give it to mac80211, but right
now it only keeps one. Move it into the context so
that we can keep one pointer each.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
In status processing we'll need to find the context
for a given frame, so add a context pointer to the
TX info for each frame.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since mac80211 doesn't currently enable/disable
QoS per interface, we can't yet do it properly,
but we can already prepare for it and move the
QoS data and command ID into the context struct.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Some commands will have different command IDs
for different contexts, so we need to store
those IDs in the context structure and use
them instead of hardcoding the commands.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The microcode tracks stations per context, so
the driver needs to do that as well for adding,
deleting and restoring them, especially in the
implicit removal case when we send an RXON.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The broadcast station ID is per context, so
add a variable for the ID in the context and
use it everywhere we previously hardcoded it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
PAN capable microcode has a different
queue assignment (not just more queues
for PAN) due to the way multicast is
handled for AP mode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
PAN ucode will require a different queue assignment,
in particular queue 9 instead of 4 should be used for
commands.
This is required because the ucode will stop/start
queues 4 and 8 depending on the PAN state, since
queue 8 will be used for PAN multicast (after DTIM).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
In order to support multiple interfaces, we must move
a lot of data into per-context structures so we can
use the contexts the device offers. To start with,
this makes a lot of code context-aware, more changes
will move more things into the context structure.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Encounter compiler error when iwlwifi debugging support is
disabled, fix it.
This compiler error was introduced by the previous WiFi/BT coexist patchset.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When aggregation is stopped again for some reason
before the queue we selected has drained, we will
currently leak the TX queue and keep it enabled
for aggregation. Normally this doesn't happen, so
the problem is rarely seen.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add the debugfs file to show current bluetooth traffic load
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update bt status upon receive scan complete notification
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move bt coex functions to iwl-agn-lib.c, so those functions
can be shared by multiple wifi/bt combo devices
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Current BT traffic load should based on the following conditions:
1. BT On/Off status
2. Channel announcement enable/disable
3. Curren traffic load report from uCode
Need to modify rate scale to down-grade from MIMO to SISO if detected
high BT traffic load. Also need to make sure not using chain "B" with high
BT traffic or if it is in "full concurrency" mode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add bt_ch_announce module parameter to enable/disable BT channel
announcement mode; default is "enable"
Based on the bt channel announcement module parameter to configure the
bt_config host command.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add additional bt coex related parameters and initialize at init
time.
Thoese parameters will be used in later implementations.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
1. Based on uart message from uCode, re-configure BT kill ack mask
messages from uCode
2. send REPLY_BT_COEX_SCO command to uCode based on the uart frame
received from uCode
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use .cfg to configure the default bt priority boost value;
the default bt priority boost is 0xf0
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding configurable parameter in .cfg for the initial Bluetooth traffic
load; set it to IWL_BT_COEX_TRAFFIC_LOAD_NONE for now, but can be change
for debugging or other reason.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In current implementation, stuck queue timer is fixed to 1 second. Add
debugfs file to modify the timer to enhance the flexibility:
Set the monitor_period as following:
0: disable stuck queue force reset function
1 - 60000: monitor period (1 - 60 second)
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Generate log when receive tx reply with bt_kill count > 0 and
in advance bt coex mode
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
bt config command need to send before the init calibration command,
driver need to let uCode know that calibrations are being performed now
in order to assure antenna is not being taken to BT use during radio/dsp
reads/writes
Also, bt_coex_priorty_table command need to be send right after the
bt_config_command during init sequence. Followed by bt coex envelope
command to initialize and prepare uCode bt state machine
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding the bluetooth full concurrency support for WiFi/BT combo devices.
Driver should configure uCode to operate in "full concurrency" mode (via
LUT) if both conditions are met:
- Antenna Coupling is more than 35dB
- WiFi Channel Inhibition Request is hornored by BT Core
Currently, there is no antenna coupling information provided by uCode;
use module parameter to specified the antenna coupling in dB.
When in "full concurrency" mode, driver need to download different LUT
to uCode while sending bt configuration command; also, driver need to
configure the device operate in 1x1 while in full concurrency mode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When bluetooth indicated high load, we should use
only antenna A in 2.4 GHz for management frames.
Add this condition to iwl_toggle_tx_ant() to make
sure it'll always be met. Note that scanning has
a separate way of forcing the antenna, because we
should scan on antenna A only regardless of BT
traffic load.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Disable plcp error checking for 6000g2b devices, with wifi/bt coex;
this got trigger too often, disable for now until finding better
trigger point.
Also extend the firmware reload timer much longer for BT coex to make sure
there are will be no mistake to reload firmware too fast and too often.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The BT SCO needs to be re-applied to the device,
while the traffic load just needs to be correct
in software.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
IBSS doesn't allow for coexistence, so it
should be disabled.
Additionally, disable reacting to the BT
profile notification when in IBSS mode,
it likely won't be sent by the device to
start with though.
Also, in IBSS mode, BT coexistence isn't as fully-featured
and we must use a single antenna only. So instead of
peppering the code with new checks, simply pretend
we are in high BT traffic load, which has the needed
effect of disabling antenna B use.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we turn off the device, reset BT
data so that we don't have outdated
information when we come up again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Depending on the amount of bluetooth traffic,
using the shared antenna (antenna B) will have
adverse impact on both bluetooth and wireless
traffic. Add controls to improve the situation
by making rate scaling depend on the BT load.
When there's high bluetooth traffic load, there's
little point in trying to aggregate as BT traffic
would disrupt the aggregated frames all the time,
so simply don't start sessions then.
When BT traffic returns to lower levels, the rate
scaling will come here again automatically when
wifi traffic is high enough, and then it will be
able to successfully enable aggregation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When advanced bt coex enabled, uCode will send bt status
notification to driver, here add support for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wey-Yi Guy