[PATCH] ath10k: Fix survey information reporting

[YanBo]

On Fri, Jun 5, 2015 at 2:20 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 06/05/2015 02:00 PM, YanBo wrote:
>> On Fri, Jun 5, 2015 at 1:18 PM, Ben Greear <greearb at candelatech.com> wrote:
>>> I think the wrapping might be even more weird that previously suspected.  Here is output from my
>>> system.
>>>
>>> It looks to me that when cycle count overflows, it right-shifts all of these
>>> counters one bit.  Clever, I guess, but surely a pain in the ass to deal with!
>>>
>>>
>>> while true; do cat /debug/ieee80211/wiphy0/ath10k/fw_stats|head -10|tail -4; date; echo;sleep 1; done
>>> ....
>>>                 TX frame count  131810463
>>>                 RX frame count 2326362883
>>>                 RX clear count 2542947851
>>>                    Cycle count 4180338939
>>> Fri Jun  5 13:13:48 PDT 2015
>>>
>>>                 TX frame count  134407497
>>>                 RX frame count 2374518035
>>>                 RX clear count 2595337341
>>>                    Cycle count 4269010333
>>> Fri Jun  5 13:13:49 PDT 2015
>>>
>>>                 TX frame count   69523007
>>>                 RX frame count 1229973316
>>>                 RX clear count 1344131636
>>>                    Cycle count 2210412416
>>> Fri Jun  5 13:13:50 PDT 2015
>>>
>>>                 TX frame count   72305753
>>>                 RX frame count 1280184579
>>>                 RX clear count 1398937635
>>>                    Cycle count 2299234941
>>> Fri Jun  5 13:13:51 PDT 2015
>>>
>>>                 TX frame count   75050021
>>>                 RX frame count 1330205664
>>>                 RX clear count 1453548082
>>>                    Cycle count 2387901854
>>> Fri Jun  5 13:13:52 PDT 2015
>>>
>>>
>> The scan count is 32 bits hence, it will wrap rapidly with 24 seconds
>> cycle, the new WMI interface will
>> supply these count in 64 bits to avoid such issue.
>
> That is not the problem... you can just sample often to resolve that.
>
> The problem is that the other 3 are divided by 2 at time when the main
> cycle-counter counter wraps.  So as far as I can tell, you cannot
> actually calculate precise totals from old and new values for the tx/rx/rx-clear
> counters if cycle-counter has wrapped since you last read stats.
>
> Only way I can see to deal with it is to sample often enough that I can
> afford to throw away samples where cycle-count wraps.  With this implemented,
> I see ath10k 'activity' calculation the same as ath9k.
>
> This wrap logic is coming out of the hardware registers as far as I
> can tell, so I'm not sure that just firmware changes can really resolve
> this fully.
>
> If all they are doing is implementing faster polling in the firmware
> itself, that seems like a waste of effort and precious instruction RAM.
>
Exactly that the FW used to fixed this issue, as it is a HW
limitation, they is no
better way to correct it without faster polling

Thanks
BR /Yanbo