* Need to re-associate firmware peer when SMPS_CHANGED is set? @ 2015-09-14 4:58 Ben Greear 2015-09-14 7:41 ` Adrian Chadd 0 siblings, 1 reply; 4+ messages in thread From: Ben Greear @ 2015-09-14 4:58 UTC (permalink / raw) To: ath10k 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@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Need to re-associate firmware peer when SMPS_CHANGED is set? 2015-09-14 4:58 Need to re-associate firmware peer when SMPS_CHANGED is set? Ben Greear @ 2015-09-14 7:41 ` Adrian Chadd 2015-09-14 16:07 ` Ben Greear 0 siblings, 1 reply; 4+ messages in thread From: Adrian Chadd @ 2015-09-14 7:41 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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? -a On 13 September 2015 at 21:58, Ben Greear <greearb@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@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Need to re-associate firmware peer when SMPS_CHANGED is set? 2015-09-14 7:41 ` Adrian Chadd @ 2015-09-14 16:07 ` Ben Greear 2015-09-14 17:18 ` Adrian Chadd 0 siblings, 1 reply; 4+ messages in thread From: Ben Greear @ 2015-09-14 16:07 UTC (permalink / raw) To: Adrian Chadd; +Cc: ath10k 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@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@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Need to re-associate firmware peer when SMPS_CHANGED is set? 2015-09-14 16:07 ` Ben Greear @ 2015-09-14 17:18 ` Adrian Chadd 0 siblings, 0 replies; 4+ messages in thread From: Adrian Chadd @ 2015-09-14 17:18 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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@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@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@candelatech.com> >>> Candela Technologies Inc http://www.candelatech.com >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-09-14 17:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-14 4:58 Need to re-associate firmware peer when SMPS_CHANGED is set? Ben Greear 2015-09-14 7:41 ` Adrian Chadd 2015-09-14 16:07 ` Ben Greear 2015-09-14 17:18 ` Adrian Chadd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.