QCA988X firmware pull-push support

[Sergey Ryazanov]

On Mon, Jan 30, 2017 at 11:13 AM, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Adrian Chadd <adrian.chadd at gmail.com> writes:
>
>> On 29 January 2017 at 17:20, Sergey Ryazanov <ryazanov.s.a at gmail.com> wrote:
>>> Yep. Looks like so.
>>
>> Which is good, because my FreeBSD ath10k port only works with 10.1 /
>> 10.2 firmware on earlier chips, and I haven't figured out the
>> intermediate software queue support that came with 10.4. :-)
>>
>> But yeah. I'll wake for Kalle to verify, but I think it's a 10.4
>> thing
>
> So there are two parts here, ieee80211_ops::wake_tx_queue() support in
> ath10k and ATH10K_FW_FEATURE_PEER_FLOW_CONTROL in firmware. We did have
> wake_tx_queue() support enabled for all hw/fw combinations but it was
> changed because some people claimed there are throughput regressions in
> certain cases. So for now we only enable wake_tx_queue() support only if
> firmware supports ATH10K_FW_FEATURE_PEER_FLOW_CONTROL:
>
>         if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
>                       ar->running_fw->fw_file.fw_features))
>                 ar->ops->wake_tx_queue = NULL;
>
> I remember that there were some improvements with wake_tx_queue() even
> if firmware didn't support ATH10K_FW_FEATURE_PEER_FLOW_CONTROL.

Yes, Rajkumar Manoharan made some fix for wake_tx_queue (). I think
that I could test this fix with QCA988x in the couple of weeks. May be
we could return to total intermediate queues support.

> I'm
> starting to wonder should we have a module parameter to force use of
> wake_tx_queue()?

Maybe. This could be useful at stage of final testing, if the last fix
for wake_tx_queue() really solves the performance issues. Before we
returning to total support of intermediate queues.

> And IIRC ATH10K_FW_FEATURE_PEER_FLOW_CONTROL was supported in some of
> 10.4 releases, but not all of them.

Yep, only few of 10.4 firmware have support of tx pull-push mode.

-- 
Sergey