[RFTv2 4/5] ath10k: wait for mgmt tx when flushing too

Michal Kazior michal.kazior at tieto.com
Thu May 15 00:24:31 PDT 2014

On 13 May 2014 22:09, Ben Greear <greearb at candelatech.com> wrote:
> On 04/09/2014 03:48 AM, Michal Kazior wrote:
>> The 10.1 firmware uses WMI to Tx management frames
>> but ath10k_flush() didn't care. This could lead to
>> some frames not being sent.
>> Although there are no Tx completions for WMI
>> mangement frames it's still better to at least
>> wait for ath10k queue to be drained.
> This and others in this series do not appear to be in Kalle's
> tree yet.  Are these to be dropped, or are they still pending?

Consider it dropped for now, please. This needs firmware changes to be
dealt with properly.

In the meantime if you want to hasten tx queue ps expiration you can
try to set `ap_detect_out_of_sync_sleeping_sta_time_secs` vdev param
to 1 second (default is 10 set in firmware if I'm not mistaken). I
haven't tested it but this should in theory shorten tx credit
starvation duration and avoid cascade of wmi timeouts (wmi timeout=3
seconds, max mgmt tx pending=2 x 1 second each=2s worst case) as well
as should prevent tx flushing from failing (timeout=5). This will not
prevent from beacon SWBA overruns because tx starvation is still
possible although it should be faster to recover.

I wonder if it's reasonable to set this vdev param explicitly in
upstream driver. We should probably consider longest beacon interval
in effect when calculation the value to set. Thoughts, anyone?


More information about the ath10k mailing list