Both (ETSI) PreCAC and RCAC are going to use use the same state
machine. The state machine drives the Agile engine and not very specific
to RCAC or PreCAC, therefore let the state machine be called agile state
machine and change the names of all the associated variables accordingly.
In this preparatory change, modify names of all APIs, states and events
to make them common to Agile RCAC and Agile PreCAC
Change-Id: I83835e0295bc97e1099c0e01fc6b2fce62437872
If START request is deferred due to RESTART pending logic, in few cases
it is leading to configuring two channels to FW.
This change checks desired channel of START req deferred VDEVs and updates
the desired channel with RESTART VDEV's desired channel
Change-Id: Ic69c10c08fd4d83aafcab97a71ce906564ab51f6
CRs-Fixed: 2713931
While finding RCAC frequency, if you're current bandwidth is 165MHz
(pine 80p80MHz), add 80p80_enabled flag for Rolling CAC random
channel selection, which allows the channel selection logic to
fallback to 160MHz bandwidth and find a channel.
CRs-Fixed: 2738917
Change-Id: I70add1b2a3c3252b1bd6bf99cffc9b9727be4f56
During 6G development, CONFIG_CHAN_NUM_APIs are kept for backward
compatability. Remove CONFIG_CHAN_NUM_API macro and remove all the
references to any function defined/declared under the macro.
CRs-Fixed: 2711597
Change-Id: Iac5d57e4e0fb1fa54b0225a5cb206e8f1fe1353d
In autochannel switch feature, a user configured primary channel
is prioritized for preCAC and after preCAC completion, the channel
is used as the primary operating channel of the device.
To acheive this, the existing preCAC lists were reordered since
every entry of the list was of a fixed 80MHz bandwidth and the
channels to be prioritized were also provided as 80MHz. i.e the list
entry to be prioritized will be made as the list HEAD.
This logic was only possible because the preCAC lists were channels
of 80MHz bandwidth. After the agile 160MHz changes, the preCAC lists
were now of variable bandwidth, from 20-160MHz. Reordering a 160MHz
channel will not allow the expected 80MHz channel to run first.
To fix this issue in autochannel switch algorithm, instead of
reordering the lists,
1. Remember the user desired channels to be prioritized in
dfs structure.
2. Before picking a channel for preCAC, see if the autoswitch desired
channel is configured
3. If yes, check the preCAC state of those channels.
4. If the preCAC state is "PRECAC_REQUIRED", use this channel to run
preCAC.
CRs-Fixed: 2723206
Change-Id: Icd6d01adfae6dfa63d0733c5dae6d6494a660190
As part of vdev start response, dfs_precac_agile_start() is
called which is intended to set the agile active bit for
the VAP's pdev and start preCAC if possible and not already
running. The active bit for a dfs/pdev indicates that there
is at least one active VAP for that dfs/pdev object.
To set the "agile_precac_active" bit, the "cur_precac_dfs_index"
is used instead of the index of the "dfs" that calls the function.
"cur_precac_dfs_index" need not always indicate the "dfs" that
calls the function.
Consider a case where there are two active 5G radios (DBS_SBS),
both with preCAC enabled. For the first vdev start response of
radio A, dfs_precac_agile_start() is called which sets the agile
precac active bit for radio A and starts preCAC. Now for the
first vdev start response of radio B, dfs_precac_agile_start will
set the current preCAC index as active, which is radio A (which
was already set). The agile preCAC active bit is never set for
radio B even though it has an active VAP and agile capable.
Because of this, after radio A completes preCAC, radio B does
not get a chance to run preCAC for it's channels.
Set the agile precac active bit for the calling radio,
irrespective of which pdev is currently running preCAC, to allow
preCAC when the radio get's a chance.
CRs-Fixed: 2705681
Change-Id: Id11c910c69c85ce9ae03e7989e784a272d5cd905
Bring up a Cascade AP in HT80 mode, country DK and enable preCAC config.
During vap start, a preCAC channel is chosen by invoking
tgt_dfs_find_vht80_precac_chan_freq() and then
dfs_start_precac_timer_for_freq() is invoked to start the preCAC timer.
In dfs_start_precac_timer_for_freq(), the dfs pdev object is fetched
indexing cur_precac_dfs_index in DFS SOC object as follows:
"dfs_soc_obj->dfs_priv[dfs_soc_obj->cur_precac_dfs_index].dfs".
The cur_precac_dfs_index is initialized to 0xFF in dfs_rcac_sm_create().
This index is then over-written to the current DFS pdev index in case
of agile preCAC in dfs_prepare_agile_precac_chan() API. This API is not
invoked in case of legacy preCAC and hence cur_precac_dfs_index continues
to hold 0xFF. This leads to kernel paging request failure
and the system crashes.
Initialize 'cur_precac_dfs_index' to dfs->dfs_psoc_idx which holds
the index of the active dfs pdev.
CRs-Fixed: 2708233
Change-Id: I3aae7ea8f611d72bfe23c20cc2a34d94bba83485
When OCAC completion event with status success is given to Host, Host will
trigger a zero second precac timer so that the precac timeout callback
function is called.
For a 165MHz agile channel, FW gives OCAC completion in terms of center
frequency 1 and center frequency 2. The center frequency 2 is non-zero
only for the 165MHz channel. This center frequency 2 information from
OCAC completion event is not stored in host before the zero second timer
is triggered.
Store the center frequency 2 information from OCAC completion event in
adfs params before triggering zero second timer.
CRs-Fixed: 2709894
Change-Id: I74af82d29a3fde859c8a3e1ea13835ebf24578b8
Consider a case where the current operating channel is 36HT80 and Agile
channel is 5290. When a radar is injected on agile channel 5290, Host
aborts agile on channel 5290, changes the timer status to not running and
configures agile to the next channel 5530 and then changes the time status
again to running. But the FW might send the OCAC completion event, with
status as OCAC CANCEL for the previously configured channel 5290. Host will
now change the precac timer status as not-running even though Host has
changed the agile channel to 5530. This is an undesirable state change.
As a consequence, when a radar is injected on the agile channel 5530, Host
will add the channels to NOL but will not trigger a channel change because
according to Host, the precac timer is not running(Host will change agile
channel on radar detection only if the precac timer is running).
Whenever an OCAC completion event is received, check if the event is
received for the currently configured agile channel, else ignore the event
without processing.
CRs-Fixed: 2677927
Change-Id: I18788857bc97a8f78426185f00596079ae2cbfd5
Rolling CAC is supported for FCC and MKK domains. MKKN is a new
variant of MKK DFS domain in which RCAC is not enabled.
Enable RCAC for MKKN DFS domain in addition to FCC and MKK.
CRs-Fixed: 2701619
Change-Id: I52ff8079d5cea9977cc49faa70af29ad44ce12d3
Add change to define restart bitmap using the generalized bitmap
declaration. Also use generalized function to check if any of the
bits are set in the bitmap.
Change-Id: I2c14a43982eb6e7cb5965253633ac00b357314e1
Fix compilation errors when QCA_SUPPORT_AGILE_DFS macro is disabled
by adding the macros in certain APIs that were wrongly placed
outside the ADFS macro.
CRs-Fixed: 2689702
Change-Id: I89a4e43926625743b9f41ae142c6a45272b0c1a2
While determining the preCAC entry in which a channel falls
under, the range of the entry is calculated from the center frequency
and the hardcoded offset of +- 75 (for 160 MHz).
In certain RDPs which supports only a maximum of 80MHz, the
entries have a range of +- 40MHz from the center, but since this value
is always hardcoded to +- 75MHz, certain channels are wrongly
misinterpreted to fall in a preCAC entry even though the entries
do not have that channel.
To avoid such anamolies, use the precac entry's BW value to
determine the range of the entry instead of hardcoding it to
+- 75MHz (offset for 160MHz/165MHz).
CRs-Fixed: 2684927
Change-Id: I412cd433d50bad82e45af1d9f34bcd566381eccf
While finding the CAC status of a channel, the tree root's
subchannel count is hardcoded to 8 (subchannel count for 160MHz
channel) after the Pine ADFS changes.
In certain RDPs, the maximum bandwidth of a channel is only 80MHz
and in those cases, the preCAC tree roots are 80MHz channels. Now
while checking if a channel is CAC done, the number of CAC done
subchannels should be equal to the number of subchannels in the
corresponding tree node. But since the tree root's subchannel count
is not calculated but is hardcoded to 160MHz, it fails in these
RDPs (with 80MHz channels) and a channel is never considered CAC
done.
To avoid this issue, use the tree root's n_valid_subchs value
as the number of subchannels instead of hardcoding it to 8.
CRs-Fixed: 2684954
Change-Id: I85e5ea6e4bb71dc9b1ba951b8e227f487e3d11f6
Remove dependency of wlan_lmac_if_def headerfile from
wlan_objmgr_psoc_obj.h in component_dev
Change-Id: I5aa8f43845538e65d25c14776ec4ec9db174f0a8
CRs-Fixed: 2643301
Add change to define restart bitmap using the generalized bitmap
declaration. Also use generalized function to check if any of the
bits are set in the bitmap.
Change-Id: Ice0682ed7a59de962e9e46cf598643139c7c2313
Add debug prints for Rolling CAC feature under the DFS debug level
"WLAN_DEBUG_DFS_RCAC". Enable it by setting the following commands:
1. iwpriv athx qdf_cv_lvl 0x27000a
2. radartool -i wifix dfsdebug 0x00400000
Change the prototype of dfs_get_rcac_enable() to store 'rcac_en'
value in a bool data type.
CRs-Fixed: 2679108
Change-Id: I124f23bb92f4464ef2c49ba2d8978c3ab4e05169
Update the event handlers of the states (INIT, RUNNING, COMPLETE)
of the rolling CAC state machine with appropriate response
to various events.
INIT:
- EV_RCAC_START:
Check if RCAC is running and if not, prepare an RCAC channel.
If channel is found, update RCAC index and transition to RUNNING.
RUNNING and COMPLETE:
- EV_RCAC_STOP:
Abort existing RCAC (cancel host timer and send RCAC abort to FW).
Introduce the following APIs:
- dfs_abort_agile_rcac: To abort RCAC in HOST and FW and reset RCAC
index.
- dfs_find_subchannels_for_center_freq: Given the center frequencies,
find the subchannels.
Also modify the channel selection logic of RCAC to clear the saved
RCAC channel parameters if no channel is found and return a valid
channel only if the agile width and the new RCAC channel width match.
CRs-Fixed: 2675221
Change-Id: I6b5565c089a7a0c3584a9e86fb81ad938d24a207
As part of preCAC forest building in pine, 160MHz root nodes
were introduced to support 160 ADFS.
To support different BW root nodes in the preCAC forest,
an API (dfs_fill_max_bw_info_for_chan) was introduced to find
every cluster of channels. i.e, every unique 160, 80,
40, 20MHz channels available in the regdomain.
This API loops through different BWs for a given primary channel
and updates the maximum BW for the primary channel and it's
corresponding center frequency. The API then skips all
the primary channels within this range (primary frequency + BW)
and goes to the next primary channel that is not in the range
and start finding the maximum BW of this channel.
After all these operations, a set of center frequencies and it's
maximum BW will be found. This data will be used to build the
preCAC forest.
While looping through different channels with the same primary,
the BW value was updated only if it's greater than the existing
maximum, but the center was always updated.
Consider a case where, for primary channel 36, the current
center is 5250MHz and it's BW is 160MHz. Now, if a new channel
structure with 36 as primary and mode as 80+80MHz, the center
is updated as 5210MHz but BW is not updated, since the new BW
(80MHz) is less than the existing BW (160MHz).
Now the center is 5210MHz but the BW is 160MHz which results in
a faulty preCAC forest.
Update the center frequency only if the maximum BW value
is changed. Also, update the index of the frequency and BW
list (dfs_max_bw_info) to start from 0 instead of starting from 1. Hence,
num_precac_roots will reduce by 1 as the index is starting from 0.
Change-Id: I50503d0cd7ebe18890216952e2193e611f7f209a
CRs-Fixed: 2674087
Feature Description:
FCC/JP domains do not support PreCAC. However, we can always start
beaconing in a channel if we have completed CAC in that channel for more
than or equal to the CAC period of that channel.
If an Agile engine is available and the next channel is known, we can
start CAC in the next channel using agile, while continuing the Tx/Rx
in the current channel. And when we want to start beaconing in the
next channel after a radar detection (or after/for a user request) we can
do so without any new CAC. This allows us to jump to the new channel
without having to disrupt any ongoing data traffic. This type of
continuous CAC in the next channel while operating in the current channel
is known as Rolling CAC.
Following functionalities are implemented:
1. APIs to enable/disable Rolling CAC feature.
2. APIs to set/get user configured Rolling CAC frequency.
3. Rolling CAC timer init, deinit and timeout functions.
4. API to determine if Rolling CAC feature is supported or not.
5. API to prepare a Rolling CAC channel and start RCAC host timer.
6. API to verify if user configured RCAC frequency is valid or not.
7. API to invoke random channel selection algorithm to determine a
RCAC chan.
CRs-Fixed: 2659363
Change-Id: Idd233268530a743dee5f0d939168573f1ba10ad8
Rolling CAC is a feature that uses the agile detector to
continuously perform CAC on a channel other than the primary
operating channel.
When the primary channel is changed to this Rolling CAC channel,
CAC is not required given that there was no radar in this rolling
CAC channel for a minimum duration (1 min in general).
Introduce a state machine that holds three basic states,
1. RCAC_INIT - No channel in Agile detector.
2. RCAC_RUNNING - Channel in Agile detector for < minimum duration.
3. RCAC_COMPLETE - Channel in Agile detector for > minimum duration.
Events that will be handled by the state machine:
1. RCAC_START - Trigger RCAC configuration in Agile detector.
2. NOL_EXPIRY - Retry picking new RCAC channel if not running/complete.
3. RCAC_STOP - Reset agile detector and stop host timer.
4. RCAC_DONE - Move SM to completed state if running.
5. ADFS_RADAR - Reset Agile detector with new channel if available
for RCAC.
Each states have entry, exit and event handlers with basic
implementations.
Few state transitions are as follows:
INIT -- RCAC_START --> RUNNING
RUNNING -- RCAC_DONE --> COMPLETE
COMPLETE -- ADFS_RADAR --> INIT (new chan) -- RCAC_START --> RUNNING
RUNNING -- RCAC_START --> INIT (new chan) -- RCAC_START --> RUNNING
COMPLETE -- RCAC_START --> INIT (new chan) -- RCAC_START --> RUNNING
RUNNING -- ADFS_RADAR --> INIT (new chan) -- RCAC_START --> RUNNING
CRs-Fixed: 2659363
Change-Id: I48a459d67d14973920c5a615bcd7c9d756b05293
Agile DFS can be disabled by disabling macro QCA_SUPPORT_AGILE_DFS.
Fix compilation errors on disabling Agile DFS.
Change-Id: I144a261f5e0db37bea9a0a6b372bcf1e13205bb6
PreCAC NOL is unmarked based on the 80MHz center frequency. This is
wrong as the PreCAC tree, with the avilablity of full 160MHz Agile engine,
can have a root as high as 160MHz. This will lead to channel not picked
for PreCAC after NOL timeout.
PreCAC NOL should be unmarked based on the center frequency of
the root node's bandwidth.
CRs-Fixed: 2654993
Change-Id: Ie054d725c1b7a2fed47c9f294f3d71c4dd9e8ecb
The API to check if precac is done on a given channel is based on
the 80MHz precac tree(dfs_is_precac_done_on_ht20_40_80_chan_for_freq()).
So a separate API was needed to check if precac was done on a 80P80MHz or
160MHz channel(dfs_is_precac_done_on_ht8080_ht160_chan()).
Now that the precac tree is updated to include the 160MHz and 165MHz
channel, the API(dfs_is_precac_done_on_ht20_40_80_chan_for_freq()) can
also be updated to include the 160MHz and the 165MHz channel and
the API(dfs_is_precac_done_on_ht8080_ht160_chan()) can check only the
80P80MHz channel.
Change the API dfs_is_precac_done_on_ht20_40_80_chan_for_freq() to
dfs_is_precac_done_on_ht20_40_80_160_165_chan_for_freq() to also check the
160MHz and the 165MHz channel.
Update the API dfs_is_precac_done_on_ht8080_ht160_chan() to
dfs_is_precac_done_on_ht8080_chan() that checks precac done only on a
80P80 channel other than the restricted 80P80 channel(the 165MHz channel).
Change-Id: Id747e3a88fc3d74c40702fc250af9e1b825b4e78
CRs-Fixed: 2653172
The API dfs_is_pcac_on_weather_channel_for_freq() which checks
whether PreCAC is being done on a weather radar channel or not does not
consider the case of an input 160MHz channel.
Add a case to check if the 160MHz channel includes weather radar channels
or not.
Also take care of the 165MHz channel which will be treated as 80P80MHz
channel.
CRs-Fixed: 2651161
Change-Id: I7285c9095a184947b1c33c11d6bb3b2370b31401
FW may limit the interval and duration during which HW may
use user provided values and attempt to capture.
These values range from 1 us to roughly 16.8 sec.
Max value is 0xFFFFFF which is 16.777215 sec.
Add check to make sure that capture duration cannot exceed
capture interval.
Change-Id: If6f75c737f8ac8cda527eee60f0e67d75e3b5420
The FW has updated the wmi command wmi_vdev_adfs_ch_cfg_cmd_fixed_param so
as to configure the restricted 80p80 channel as the Agile channel.
Add support in ADFS parameter to enable the 165MHz channel as the Agile
channel.
Change-Id: I757bbd9b209118f19e51b7a95881124000f362c8
CRs-Fixed: 2642555
Rebuild the precac tree with 160MHz root channels. Add support to mark the
160MHz precac channel nodes as CAC done and NOL.
Go through the list of available channels to find the unique PreCAC Tree
roots. Find the root channels that are not part of the 160MHz channel.
Example, consider a case where a country supports only until channel 144,
then the precac tree will have two 160MHz root nodes(36HT160, 100HT160) and
one 80MHz root node(132HT80).
Add support include the 165MHz channel to the precac tree for Pine by
considering the 165MHz channel as a 80p80MHz channel with a center channel
number 146. Adjust the channel frequency offset to mark the 165MHz
channel as precac done and NOL.
When a 160MHz or the 165MHz channel encloses a nonDFS channel, mark that
nonDFS channel as precac done.
Change-Id: Ia9bb2cc5c845c4d636e35329cdf76ace2eb63c72
CRs-Fixed: 2628373
Protect access to cfr lookup table, since error handling
mechanism attempts to cleanup CFR entries in timer context,
this leads to contention between bottom-half and timer.
Change-Id: I6a414e0da883250a90451824367c12fcca33c27e
For Pine, the agile channel width needs to be 160MHz when the current
channel width is 160MHz or restricted 80+80MHz.
Change-Id: Id1339400c6e86daf9febe364de62be42c9732f14
CRs-Fixed: 2628370
For Pine chip, where true 160MHz (single detector for 160MHz)
is supported, the agile detector ID is 1 (instead of 2 for
chipsets like Hawkeye with two primary 80MHz detectors).
Assign the dfs_agile_detector_id to the proper value based on
true 160MHz capability.
Introduce a new API to get the agile_detector_id based on the
chip's capability. Use the new API to get the agile_detector_id
instead of using the existing enum.
CRs-Fixed: 2637793
Change-Id: I8033e541c09632a9e4c7be1a5067d1dbcedd0d48
