Need to re-associate firmware peer when SMPS_CHANGED is set?

[Adrian Chadd]

grr, yes, I should try twisting some arms (lovingly) again.

The 2040 logic can have the same problem - if you initialise the
hardware to 20MHz mode you have to modify the rate table /and/ any
frames that are currently queued up. If there's hardware frames then
you either abort, or you just have the driver transition through
"don't queue new frames, complete existing frames, switch 40->20,
recalc rate control tables, recalc rate control for software queued
frames, start again."

I still have not done that in FreeBSD, but I helped some people back
at QCA figure all of that nonsense out. I don't ever know if it made
it into ath9k either :(

(God I'd like a working toolchain for this firmware source already...)



-adrian


On 14 September 2015 at 09:07, Ben Greear <greearb at candelatech.com> wrote:
> On 09/14/2015 12:41 AM, Adrian Chadd wrote:
>>
>> Hm! Well, iirc what we did in the rate control code for 11n chips was
>> just to limit the transmit rate control selection to MCS0-7 even
>> though we were in 2- or 3- stream modes.
>>
>> What else is it causing to change?
>
>
> If rate-ctrl is currently in VHT with MCS 9, and we set the NSS
> to 1, then it can no longer use MCS 9.  Something should proactively
> kick the rate-ctrl logic when this happens.
>
> The 10.1 rate-ctrl logic is all sorts of broken, especially with regard
> to configuring this sort of change on the fly.  I'm fixing that in
> CT firmware.  10.1 actually tries to reconfig everything properly
> when SMPS changes, but it will fail to do so because it doesn't know
> how to fetch the rate-ctrl object from the host's memory cache.
>
> I've added an API for driver to request that firmware fetch the rate-ctrl
> object...so calling that, then waiting 1ms, then calling the reassoc() logic
> likely will work at least most of the time.  I didn't want to have to add
> the same fetch + sleep hack for SMPS since the reassoc already does that.
>
> Either way, I can hack the driver accordingly....I'll be testing out my
> changes today.
>
> Hopefully the newer ath10k upstream firmware do this all better, but
> since I don't have source, I've no real idea of that.
>
> Thanks,
> Ben
>
>
>>
>>
>> -a
>>
>>
>> On 13 September 2015 at 21:58, Ben Greear <greearb at candelatech.com> wrote:
>>>
>>> While digging in 10.1 firmware, I notice that setting WMI_PEER_SMPS_STATE
>>> can cause
>>> the chainmask to change.  And, that in turn can change all sorts of
>>> things
>>> related to
>>> available rates and such.
>>>
>>> Maybe we should do a re-assoc when we notice SMPS_CHANGED, similar to how
>>> it
>>> is done for NSS_CHANGED?
>>>
>>> Thanks,
>>> Ben
>>>
>>> --
>>> Ben Greear <greearb at candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k