With the current implementation dfs->dfs_soc_obj was initialized in
function dfs_agile_soc_obj_init under the macro QCA_SUPPORT_AGILE_DFS
and ATH_SUPPORT_ZERO_CAC_DFS both of which are disabled for the low
memory profiles. Remove the initialization from here and unconditionally
initialize it in wlan_dfs_pdev_obj_create_notification.
Change-Id: I207ed4e7d5cb42100e5bf1cbf55cdd9de13f35b8
The radar found action on a agile channel is a WIN specific action. It was
combined with the current channel radar detection making the function huge
and difficult to read.
Separate the WIN specific agile radar action and define in it as WIN
specific.
Change-Id: I79ed61ae80a2870dff9775b9435069c50584ca83
CRs-fixed: 2738015
In case of a current channel being a 5GHz DFS channel, a channel change
may be triggered by a radar detection. The next channel is automatically
selected by a random channel selection algorithm in this case. However,
if the current channel is a 6GHz channel and we need to switch to a 5GHz
channel then 5GHz channel should be provided a user or another channel
selection algorithm. At the time, when the device is starting its
operation on a 6GHz channel , the next 5GHz channel that a user
(or another another channel selection algorithm) is going to select
is unknown. Therefore, the probability that the next channel selected
by a user (or another channel selection algorithm) will match the RCAC
channel returned by random channel selection, is very low. Therefore,
do not select a random channel for RCAC if the current operating channel
is a 6G channel for now.
Change-Id: I9aef64cea1d442fc31b2314da08baba7769650f2 has the following
change :
The macro WLAN_IS_CHAN_MODE_x(_c) checked if mode is 'x' as well as if
the channel was a 5G channel. However with wideband changes this macro
will return true if mode is 'x' for both 5G and 6G channels. Hence adding
a separate 5G check for functions where the channel must be a 5G channel.
With WLAN_IS_CHAN_MODE_x(_c) now a 6G channel will pass
the checks in dfs_is_precac_done which would cause regression. Hence a
5G check has been added to prevent this.
Change-Id: Iee5e965f0bc99565cb5ea77d88998d5530f24153
For the 16M low memory profile a few feature macros were disabled which
led to unavailability of a few APIs.
Add empty definitions for these APIs when the corresponding feature
macros are disabled.
Change-Id: I1f7790196ae8383eac40f5869992fd06ede3e5dc
Following is the list of changes :-
1. Add an API dfs_agile_precac_cleanup to reset all dfs variables
while going from running to init state.
2. Add a parameter is_chan_found to dfs_prepare_agile_precac_chan and
make it true if a channel is available for PrCAC/RCAC.
3. Post event done to Agile SM when firmware returns ocac complete for
a particular agile channel.
4. Post event done if preCAC timer expires from driver for a particular
agile channel.
5. Remove the zero second timer mechanism of starting of Agile PreCAC,
instead regulate it completely using the Agile SM.
6. Add API dfs_is_agile_cac_enabled which checks if either PreCAC/RCAC
is enabled. Events are not posted to the Agile SM if none of these
are enabled.
7. Add API dfs_abort_agile_precac used to send abort to F/W for that
specific DFS index.
8. Add API dfs_init_agile_start_evt_handler to handle the start event in
init state of Agile SM. This checks if a channel is available for
PreCAC/RCAC.
9. In init and running state of the SM handle events for both PreCAC and
RCAC, while complete state is for RCAC alone.
10. Following is the algorithm implemented in the Agile SM :
The Agile SM is per psoc, create it when the psoc is created.
|
On receiving the VAP start resp, send a start event to the SM in
init state. In the start event handler check if a PreCAC/RCAC channel
is available and if found configure the agile channel params and send
a WMI to F/W.
|
A OCAC complete is received on completion of CAC by F/W or the host
timer might expire. In either case mark the channel as CAC done.
Check if interCAC was running and the channel is the des chan, if so
a primary channel change is automatically triggered.
|
In the event of mode switch/scan start/VAP down/primary channel change
while PreCAC is running a stop event is received. Clear all dfs
structures and go to init state.
|
On receiving a radar in the Agile channel, go to the init state and
set event as start. Radar in primary channel is taken care of by
ensuing VAP down up.
|
When no other channels are pending PreCAC, clean all dfs structures
and remain in the init state. PreCAC uses only init and running
states of the SM.
Change-Id: I231c79d381c7c3e192bea8ebff1ee6b5dc4a3cfa
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
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
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 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
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
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
While excluding the current operating channel for preCAC, the
entire tree is skipped if the current operating channel is selected
by the algorithm. In case of a tree node with two 40MHz nodes, if the
selected channel is the current operating channel but the other 40MHz
channel is still pCAC required, that channel should be selected.
To achieve this, move the logic, of excluding the current operating
channels, inside the tree traversal algorithm.
CRs-Fixed: 2621410
Change-Id: Ib8ea3dea168d27ea98a0bf2a9ea1eb57872b285f
Issue:
Bring up the AP on channel 100 HE80 in ETSI domain and enable preCAC config
(option preCACEn 1). The AP begins CAC on channel 100 and does preCAC
on the channel 58 (the first HE80 channel in the preCAC list). The default
preCACtimeout is 6 min. Inject radar on channel 100 using bangradar.
AP does a VDEV RESTART to a new random channel (say 36) and aborts
preCAC on channel 58. After VDEV RESTART on new random channel (say 36),
AP chooses a new random channel to do preCAC and marks channel 58 as
preCAC done. Channel 58 can be marked preCAC done only after 6 min
of CAC completion. However, within 6 min, if primary channel detects
radar, channel 58 incorrectly marked as preCAC done.
When primary channel 100 is marked as NOL, "dfs_agile_precac_freq_mhz"
(the variable that holds the value of the last agile frequency)
which was assigned 5290MHZ (chan 58) is not cleared.
"dfs_agile_precac_freq_mhz" continues to hold the preCAC channel freq
5290. After VDEV RESTART to new random channel (36), preCAC is initated
again invoking dfs_start_agile_precac_timer() using a zero second
timer. As "dfs_agile_precac_freq_mhz" is not 0,
dfs_mark_precac_done_for_freq() marks channel 5290 (58) as preCAC done.
Solution:
To solve the issue mentioned above, reset "dfs_mark_precac_done_for_freq"
to 0 on radar detect so that preCAC done channel is not marked
incorrectly.
Change-Id: If6dae4b3527f060d5512d82ebd437ea1b6db1425
CRs-Fixed: 2631779
Address the compilation issues when the DFS feature Auto channel
switch support is disabled(WLAN_DFS_PRECAC_AUTO_CHAN_SUPPORT=0).
Change-Id: I6eda4bf133552e145a49a60aea50a0ce29a11373
CRs-Fixed: 2608450
Supported dynamic HW mode switches:
DBS (full band 5G and 2G) <-> DBS_SBS (low band 5G, high band 5G and 2G)
Description of the changes:
1. NOL conversion:
a. Introduce a temporary NOL list copy structure in DFS psoc obj.
b. When mode switch is triggered:
i. Stop the NOL timers and clear the data, to avoid processing NOL
expiry during mode switch.
ii. Allocate the psoc NOL copy for the target num_radios.
iii. Store the NOL data of each radio to the target pdev ID
(pdev ID after mode switch) in the psoc NOL copy,
using a unified mux/demux API.
c. After mode switch is completed:
i. Resume NOL by re-initializing the list from the temporary psoc
copy.
ii. Free the psoc copy after mode switch is complete.
iii. Note: changes are made to support pause and resume of NOL,
increasing NOL timeout by a few milliseconds.
2. PreCAC list conversion:
a. When mode switch is triggered:
i. Stop the existing preCAC timer and send ADFS abort command to FW.
b. When mode switch is completed:
i. Unify/separate the preCAC list if the target mode is DBS/DBS_SBS
respectively, using a single API.
ii. Start ADFS again.
3. Radar detection lock:
a. While detecting radar, acquire a lock to avoid handling user triggered
mode_switch during this process. Release the lock once radar
processing is completed and CSA start is triggered.
4. Radar detection/CAC completion defer during mode switch:
a. While detecting radar or CAC completion, check if mode switch is
in progress. If yes, wait for mode switch to complete before
handling the events.
b. Note: Precedence is Radar over CAC, i.e., if CAC processing is waiting
and radar is received, CAC completion is no longer handled.
CRs-Fixed: 2535058
Change-Id: I55e03dae9da994c21b1aafe7b7686f5299221a40
While configuring the precac timeout as part of starting the agile
engine, the timeout value sent to FW and HOST timer were both equal,
resulting in two separate timeout.
1. Zero second timeout due to OCAC complete event from FW.
2. preCAC timer timeout.
Because of these timeouts, same channel is marked as OCAC complete
twice. To avoid this, increase the HOST timer timeout value by
2 seconds.
Change-Id: I9b649b5c783df962df2b8410691ee00d1abb4a9d
CRs-Fixed: 2556726
Introduce a phyerror sample analogous to the phyerrors given by FW and
store itin the text file. Read the text file and Inject this phyerror to
the DFS algorithm.
Change-Id: Iff33b6554911e4f3e8101cb81df5c500cd96f041
CRs-Fixed: 2484584
The IEEE channel numbers in the 6GHz band overlap with the IEEE channel
numbers in 2.4GHz, 4.9GHz (e.g. Channel number 1) and 5GHz
(e.g. Channel number 149). Currently many APIs in Agile DFS (ADFS),
have channel number as a parameter. This leads to the channel number
collision. To overcome this, new APIs with channel center frequency
(in units of megahertz or MHz) as a parameter are created, as
channel center frequency is unique for 2.4 GHz, 4.9 GHz, 5GHz,
and 6GHz channels.
Each new API performs the same function as its old counterpart.
For example dfs_find_cac_status_for_chan() and
dfs_find_cac_status_for_chan_for_freq() perform the same operation. The
difference in the latter, is that the channel center frequency is given
as an input parameter instead of IEEE channel number, and the function
body is modified to suit channel center frequency.
The new channel frequency based APIs are placed under the macro
"CONFIG_CHAN_FREQ_API" and the existing channel number based APIs are
placed under the macro "CONFIG_CHAN_NUM_API". The APIs under the macro
CONFIG_CHAN_NUM_API will be removed, when when all the references to
the APIs are removed.
CRs-Fixed: 2526360
Change-Id: Icff94f518af3621b039f059f1409106a5639ed8b
As part of the ETSI preCAC feature, every 20MHz channel that is CACed
and not in NOL is maintained in a list which is then checked during every
channel switch for CAC reuse (avoiding CAC).
With the introduction of preCAC list (Binary Search Forest) for
20, 40 and 80MHz channels which also includes the current channel CAC
information, the ETSI preCAC list has become redundant.
Remove all APIs and changes that support the redundant ETSI preCAC list.
Change-Id: I76656807bc117af1f6909160ade86ae13d390f1a
CRs-Fixed: 2484864
