On 03/26/2014 12:18 AM, Michal Kazior wrote:
On 25 March 2014 16:14, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 03/25/2014 12:27 AM, Michal Kazior wrote:
On 24 March 2014 17:50, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 03/24/2014 04:21 AM, Michal Kazior wrote:
On 24 March 2014 12:12, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
