wcn36xx: RFC self-limit sw_scan to 166ms to avoid link stallsmainline-qcom64-basis-test-2015-02-04-1mainline-qcom64-basis

On wcn3620 with wpa_supplicant set to defaults, it can asks for a
10s sw_scan as often as every 40s.

During the 10s scan, the link is basically stopped for the whole
time, leading to behaviours like this on ping

...
64 bytes from 198.41.208.143: icmp_seq=242 ttl=53 time=40.8 ms
64 bytes from 198.41.208.143: icmp_seq=243 ttl=53 time=31.6 ms
64 bytes from 198.41.208.143: icmp_seq=244 ttl=53 time=32.2 ms
64 bytes from 198.41.208.143: icmp_seq=245 ttl=53 time=8968 ms
64 bytes from 198.41.208.143: icmp_seq=246 ttl=53 time=7977 ms
64 bytes from 198.41.208.143: icmp_seq=247 ttl=53 time=6977 ms
64 bytes from 198.41.208.143: icmp_seq=248 ttl=53 time=6018 ms
64 bytes from 198.41.208.143: icmp_seq=249 ttl=53 time=5018 ms
64 bytes from 198.41.208.143: icmp_seq=250 ttl=53 time=4019 ms
64 bytes from 198.41.208.143: icmp_seq=251 ttl=53 time=3019 ms
64 bytes from 198.41.208.143: icmp_seq=252 ttl=53 time=2019 ms
64 bytes from 198.41.208.143: icmp_seq=253 ttl=53 time=1019 ms
64 bytes from 198.41.208.143: icmp_seq=254 ttl=53 time=34.3 ms
64 bytes from 198.41.208.143: icmp_seq=255 ttl=53 time=30.9 ms
64 bytes from 198.41.208.143: icmp_seq=256 ttl=53 time=32.9 ms
64 bytes from 198.41.208.143: icmp_seq=257 ttl=53 time=30.8 ms
64 bytes from 198.41.208.143: icmp_seq=258 ttl=53 time=30.9 ms
64 bytes from 198.41.208.143: icmp_seq=259 ttl=53 time=33.7 ms
...

As was mentioned on the wcn36xx list, the prima driver does not
use this kind of scan behaviour, as captured here in the
wcn36xx-dissector example dumps

https://raw.githubusercontent.com/kanstrup/wcn36xx-dissector/master/examples/prima-3660-sta-connect-11g-wpa2-wmm-screen-off.txt

Instead he scans for 150ms channel by channel, with explicit
scan start and stop SMD commands for each channel.

This patch decouples the scan action of the driver from the
sw_scan start and stop ops, in this initial version of the
patch the driver now does one 166ms scan and stops / finishes
the scan action itself and waits until the sw_scan stop.

This removes the 10s blocking behaviour, while still
introducing problems with the link, they are far more
tolerable than 10s

...
64 bytes from 198.41.209.142: icmp_seq=57 ttl=54 time=31.2 ms
64 bytes from 198.41.209.142: icmp_seq=58 ttl=54 time=31.9 ms
64 bytes from 198.41.209.142: icmp_seq=59 ttl=54 time=31.2 ms
64 bytes from 198.41.209.142: icmp_seq=60 ttl=54 time=31.1 ms
64 bytes from 198.41.209.142: icmp_seq=61 ttl=54 time=37.9 ms
64 bytes from 198.41.209.142: icmp_seq=62 ttl=54 time=31.5 ms
64 bytes from 198.41.209.142: icmp_seq=63 ttl=54 time=198 ms
64 bytes from 198.41.209.142: icmp_seq=64 ttl=54 time=31.7 ms
64 bytes from 198.41.209.142: icmp_seq=65 ttl=54 time=33.0 ms
64 bytes from 198.41.209.142: icmp_seq=66 ttl=54 time=80.2 ms
64 bytes from 198.41.209.142: icmp_seq=67 ttl=54 time=159 ms
64 bytes from 198.41.209.142: icmp_seq=68 ttl=54 time=34.3 ms
64 bytes from 198.41.209.142: icmp_seq=69 ttl=54 time=32.7 ms
64 bytes from 198.41.209.142: icmp_seq=70 ttl=54 time=39.3 ms
64 bytes from 198.41.209.142: icmp_seq=71 ttl=54 time=118 ms
64 bytes from 198.41.209.142: icmp_seq=72 ttl=54 time=31.7 ms
64 bytes from 198.41.209.142: icmp_seq=73 ttl=54 time=35.5 ms
64 bytes from 198.41.209.142: icmp_seq=74 ttl=54 time=32.0 ms
64 bytes from 198.41.209.142: icmp_seq=75 ttl=54 time=33.0 ms
64 bytes from 198.41.209.142: icmp_seq=76 ttl=54 time=35.1 ms
64 bytes from 198.41.209.142: icmp_seq=77 ttl=54 time=31.8 ms
64 bytes from 198.41.209.142: icmp_seq=78 ttl=54 time=32.0 ms
64 bytes from 198.41.209.142: icmp_seq=79 ttl=54 time=31.9 ms
64 bytes from 198.41.209.142: icmp_seq=80 ttl=54 time=46.0 ms
64 bytes from 198.41.209.142: icmp_seq=81 ttl=54 time=38.3 ms
...

It takes a bit longer to associate probably because it takes
longer to find the AP beacon.

For bulk transfer, a download that was interrupted regularly and
averaged 150KBps before is able to complete at average 1.0MBps

# wget -Obbb.mp4 http://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
--1970-01-01 00:03:13--  http://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
Resolving download.blender.org (download.blender.org)... 82.94.213.221
Connecting to download.blender.org (download.blender.org)|82.94.213.221|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 64657027 (62M) [application/octet-stream]
Saving to: ‘bbb.mp4’

100%[======================================>] 64,657,027  1.02MB/s   in 61s

2015-01-24 13:50:11 (1.00 MB/s) - ‘bbb.mp4’ saved [64657027/64657027]

It seems wpa_supplicant is asking for the scans, according to dynamic
average rssi.  That makes the scan requests unpredictable, eg

[  261.144852] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[  300.940232] wcn36xx wcn36xx: wcn36xx_scan_work: ch 1
[  340.726914] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[  380.529928] wcn36xx wcn36xx: wcn36xx_scan_work: ch 1
[  420.314379] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[  460.102097] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[  499.892589] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[  809.681723] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[ 1119.474430] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[ 1429.264266] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11
[ 1739.055172] wcn36xx wcn36xx: wcn36xx_scan_work: ch 11

the channel it wants to scan is also unpredictable (this is while
associated to the only AP with the BSSID on ch11).

Any advice about if this is a legitimate way to cover the
problem, if there's a better way and if the other wcn36xx
variants also have this problem (and could use the solution)
are welcome.

Signed-off-by: Andy Green <andy.green@linaro.org>

0 files changed, 0 insertions, 0 deletions