Re: [PATCH 1/3] ath10k: Add debugging for tx-credits usage.

[Ben Greear <greearb@candelatech.com>]

On 03/26/2014 12:18 AM, Michal Kazior wrote:
> On 25 March 2014 16:14, Ben Greear <greearb@candelatech.com> wrote:
>> On 03/25/2014 12:27 AM, Michal Kazior wrote:
>>>
>>> On 24 March 2014 17:50, Ben Greear <greearb@candelatech.com> wrote:
>>>>
>>>> On 03/24/2014 04:21 AM, Michal Kazior wrote:
>>>>>
>>>>> On 24 March 2014 12:12, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>>>
>>>>
>>>>>>> -     status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb);
>>>>>>> +     status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb, __LINE__);
>>>>>>
>>>>>>
>>>>>> Using line numbers in debug messages is very cumbersome. Some people
>>>>>> cherry pick patches, have their own changes and whatnot which will make
>>>>>> it more difficult to read the debug logs. Isn't there any better way to
>>>>>> do this?
>>>>>
>>>>>
>>>>> I would prefer to explicitly wait for tx credit replenishment in
>>>>> ath10k_wmi_cmd_send() after a command is sent instead of all these
>>>>> prints. This way you can get a full call trace if it times out.
>>>>
>>>>
>>>> Would that be a performance problem (by effectively allowing only a
>>>> single
>>>> item to be sent to the firmware at any given time?)
>>>
>>>
>>> The only thing that may suffer here is wmi mgmt tx but I wouldn't
>>> consider that performance critical.
>>
>>
>> In that case, why use credits at all?
>
> Excellent question.
>
> Firmware provides 2 HTC tx credits for WMI. I guess this is on
> purpose. I imagine WMI mgmt tx can hang (i.e. not replenish tx
> credits). In that case the remaining tx credit could be used to try
> recovering, e.g. down/stop vdev (I think it should drop all pending tx
> and thus free the stuck HTC tx credit).
>
> It might be a good idea to keep this recovery strategy in mind when
> implementing the "wait for tx replenishment" wmi tx blocking.

Seems to me we should just fix the firmware to respond quickly..and if we know exactly which
command is not being answered (quickly) in the firmware, it might be easier to debug
it.

That said, while debugging I think I have seen cases where one message would
be consumed for a long time, and then suddenly it frees up again.

So, I'm not sure what to do.  Maybe could improve firmware to return an id
so we know exactly which of the messages was processed, and then the driver
could do the work of figuring out what commands are outstanding by just keeping
a copy in RAM....

Thanks,
Ben

>
>
> Michał
>


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