[PATCH v3 1/2] ath10k: handle cycle counter wraparound

[Michal Kazior]

On 22 May 2015 at 13:36, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> When QCA988X cycle counter HW register wraps
>> around it resets to 0x7fffffff instead of 0. All
>> other cycle counter related registers are divided
>> by 2 so they never wraparound themselves. QCA61X4
>> has a uniform CC and it wraparounds in a regular
>> fashion though.
>>
>> Worst case wraparound time is approx 24 seconds
>> (2**31 / 88MHz). Since scan channel visit times
>> are max 5 seconds (offchannel case) it is
>> guaranteed there's been at most 1 wraparound and
>> it is possible to compute survey data.
>>
>> This fixes some occasional incorrect survey data
>> on QCA988X as some channels (depending on how/when
>> scan/offchannel requests were requested) would
>> have approx 24 sec active time which wasn't
>> actually the case.
>>
>> This should help make hostapd ACS more reliable.
>>
>> Reported-by: Srinivasa Duvvuri <sduvvuri at chromium.org>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
> [...]
>
>> +void ath10k_core_get_cc_delta(struct ath10k *ar,
>> +                           u32 *cc_delta, u32 *rcc_delta,
>> +                           u32 cc, u32 rcc,
>> +                           u32 cc_prev, u32 rcc_prev)
>> +{
>> +     if (ar->hw_params.has_shifted_cc_wraparound && cc < cc_prev) {
>> +             cc_prev -= 0x7fffffff;
>> +             rcc *= 2;
>> +     }
>> +
>> +     *cc_delta = cc - cc_prev;
>> +     *rcc_delta = rcc - rcc_prev;
>> +}
>
> Why do you have this function in core.c? Why not in wmi.c?

I don't consider this a part of WMI protocol per se. It's a logic
which happens to be used with values delivered via WMI but is chip
specific otherwise. For what it's worth we could be reading CC
registers, e.g. directly via MMIO.


Michał