[PATCH] wcn36xx: Fix software-driven scan

[Bryan O'Donoghue]

On 24/08/2020 08:51, Loic Poulain wrote:
> Hi Bryan,
> 
> On Mon, 24 Aug 2020 at 03:45, Bryan O'Donoghue
> <bryan.odonoghue at linaro.org> wrote:
>>
>> On 17/08/2020 17:01, Loic Poulain wrote:
>>> For software-driven scan, rely on mac80211 software scan instead
>>> of internal driver implementation. The internal implementation
>>> cause connection trouble since it keep the antenna busy during
>>> the entire scan duration, moreover it's only a passive scanning
>>> (no probe request). Therefore, let mac80211 manages sw scan.
>>>
>>> Note: we fallback to software scan if firmware does not report
>>> scan offload support or if we need to scan the 5Ghz band (currently
>>> not supported by the offload scan...).
>>>
>>> Signed-off-by: Loic Poulain <loic.poulain at linaro.org>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>
>>
>> OK.
>>
>> TL;DR included diff fixes the performance issue.
>>
>> I've poked about with the old scan, and this new scan and I've managed
>> to find to find where the new scan is killing performance.
>>
>> Please see below.
>>
>> @@ -792,6 +792,7 @@ int wcn36xx_smd_finish_scan(struct wcn36xx *wcn,
>>    {
>>           struct wcn36xx_vif *vif_priv = wcn36xx_vif_to_priv(vif);
>>           struct wcn36xx_hal_finish_scan_req_msg msg_body;
>> +       u8 oper_channel;
>>           int ret;
>>
>>           mutex_lock(&wcn->hal_mutex);
>> @@ -802,7 +803,9 @@ int wcn36xx_smd_finish_scan(struct wcn36xx *wcn,
>>                   /* Notify BSSID with null data packet */
>>                   msg_body.notify = 1;
>>                   msg_body.frame_type = 2;
>> -               msg_body.oper_channel = channel;
>> +               oper_channel = WCN36XX_HW_CHANNEL(wcn);
>> +               if (oper_channel != channel)
>> +                       msg_body.oper_channel = channel;
> 
> Is this condition ever satisfied? I mean, finish_scan is normally always
> called with operating-channel as channel parameter.

I had a debug statement and never saw it run, so I think no is probably 
the answer to that.

Basically though the msg_body.oper_channel needs to be left at zero. 
Whatever the firmware does with non-zero is not correct @ 80Mhz/5ghz


>> 2. Performance is as expected
>>      I see throughput oscillate between 30 mbit and 100 mbit
>>      - Android runs a scan every 15 seconds
> 
> With scanning app in the foreground, right?
> While connected to an AP, Android 'should' only background scan if
> RSSI becomes too low (for roaming).

Foreground scanning yes, I'm forcing a constant interleaving.