[ath9k-devel] [RFC/RFT 6/7] ath10k: add active htc ul pipe polling support

[Michal Kazior <michal.kazior@tieto.com>]

On 15/05/13 14:37, Kalle Valo wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> Until now we depended solely on passive or lazy
>> polling for tx completion.
>>
>> The passive was in htc rx handler. The lazy in
>> htc_send_work(). The lazy would fire only if there
>> are less than 50% resources free. However for HTT
>> tx we have 2047 resources and we never used more
>> than 512 (HTT_MAX_PENDING_TX).
>>
>> It is a good idea to have a timer that polls for
>> tx completions "just in case". This could help if
>> mac80211 is waiting for tx status and there's no
>> tx/rx happening.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> I haven't tested your patches yet, but I'm a bit concerned about the
> timer. Timers usually create problems of their own and using them wrong
> affect power consumption.
>
> I don't have time to read the patches in detail, but can you give a
> short summary how the timer works? How often is it fired? What happens
> when the data path is idle?

The timer is fired after tx path has became idle after some tx had been 
done. This should make us report tx status to mac80211 more quickly 
(rather than waiting for a beacon, or other frame on HTT rx that would 
trigger the polling).

We could probably try a different scheme - to poll every 20ms as long as 
there is any tx pending. That would be a lot better wrt reporting tx 
status quickly.

Let's just drop this patch. It's not really necessary, at least for now.


> And is it absolutely necessary to use a timer? Can't we use tx
> completions or some other existing event from firmware to accomplish the
> same?

HTT tx is done on a pipe that has interrupts disabled. We need to poll 
for tx completions. We poll them in 2 cases:

  a) when we receive a frame on HTT rx (it's a different pipe, with 
interrupts)

  b) we submit a new HTC frame (so HTT tx request counts) and tx pipe 
resources are drained below 50% (which never happens, because we have 
512 msdu_ids limit, and there are 2047 tx resources on the HTT tx pipe)

The (b) case is solved in patch #7, although it could be done 
differently (by increasing msdu_ids limit to tx pipe limit which is 2047).


-- Pozdrawiam / Best regards, Michal Kazior.