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

[Ben Greear]

On 05/15/2014 12:24 AM, Michal Kazior wrote:
> 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.

Ok, I've hacked my firmware to deal with it already..will drop this
series, and will investigate the suggestion below as well.

Thanks,
Ben


> 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?
>
>
> Michał
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com