On Wed, 2014-04-09 at 15:20 +0300, Arik Nemtsov wrote:
> >>
> >> # calibrator wlan0 plt power_mode on
> >> [ 93.107215] wlcore: power up
> >> [ 93.688714] wlcore: firmware booted in PLT mode PLT_ON (PLT 6.3.10.0.133)
> >> # [ 139.232802] YY: wl1271_tx_allocate
> >> [ 144.241849] wlcore: ERROR Tx stuck (in FW) for 5000 ms. Starting recovery
> >
> > Okay, you have a starting point. :)
> >
> > Now try to look from where this is being called and so on. I don't
> > think we should be calling wl1271_tx_allocate() in PLT mode either. Try
> > tracing back until you find where this is coming from.
>
> Actually we've seen this bug before. At the time it was caused by FW
> requests for dummy packets during PLT mode, which forced us to issue
> Tx..
Ah, interesting, I hadn't heard about it. Would it send it even if the
event was masked out? Masking it out (if it's not already) for PLT would
probably be the right thing to do.
> It was fixed in the FW, but I'm not sure this was ever upstreamed
> (customer specific fix, etc). Anyway it's pretty safe to disable the
> Tx watchdog during PLT - try something like this:
>
> void wl12xx_rearm_tx_watchdog_locked(struct wl1271 *wl)
> {
> if (wl->plt)
> return;
Maybe this could be blocked even earlier, like here:
diff --git a/drivers/net/wireless/ti/wlcore/event.c b/drivers/net/wireless/ti/wlcore/event.c
index 1f9a360..c44d3c0 100644
--- a/drivers/net/wireless/ti/wlcore/event.c
+++ b/drivers/net/wireless/ti/wlcore/event.c
@@ -158,6 +158,9 @@ EXPORT_SYMBOL_GPL(wlcore_event_channel_switch);
void wlcore_event_dummy_packet(struct wl1271 *wl)
{
+ if (wl->plt)
+ return;
+
wl1271_debug(DEBUG_EVENT, "DUMMY_PACKET_ID_EVENT_ID");
wl1271_tx_dummy_packet(wl);
}
--
Luca.
--
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
