On 25.09.2014 14:08, Amit Virdi wrote:
> Hello Mathias,
>
> I'm trying to connect a webcam gadget on USB3.0 interface with xHCI host when
> LPM is enabled. My xHCI host is TI's TUSB7340EVM. xHCI host stops responding
> as soon as the webcam gadget module is inserted on the device side (The
> device is also running linux)
>
> Host machine kernel version is 3.16. I have enabled quirk for LPM enable for
> my XHCI card.
>
> The detailed description and a host kernel logs can be found from bugzila:
> https://bugzilla.kernel.org/show_bug.cgi?id=85141
>
> Could you please help in rectifying this bug? Please let me know if there's
> any more information required.
>
> Thanks
> Amit Virdi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi
I'm not really sure what's going on, but there are some things that look a bit
suspicious in the log.
After setting maximum_exit_latency successfully with "evaluate context
commands" according to U1 and U2 parameters it then wants to disable link state
and set maximum_exit_latency back to 0.
This last "evaluate context command" times out, xhci driver tries to abort the
command, but also aborting the command fails.
Could you try clearing the slot_context dev_state bits, I think that those
should be set to zero in the input context
We currently in xhci_change_max_exit_latency() copy it blindly from the output
context, and there seems to be some reserved vendor bits set there as well.
A patch like this should do it:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..19c9518 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4004,6 +4004,7 @@ static int __maybe_unused
xhci_change_max_exit_latency(struct xhci_hcd *xhci,
slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx);
slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT));
slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency);
+ slot_ctx->dev_state = 0;
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
"Set up evaluate context for LPM MEL change.");
If that doesn't help, you could try easing up the busyloop that is checking
xhci state, this could help in successfully aborting the command,
A patch like this should help:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..0cc451c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -70,8 +70,8 @@ int xhci_handshake(struct xhci_hcd *xhci, void __iomem *ptr,
result &= mask;
if (result == done)
return 0;
- udelay(1);
- usec--;
+ udelay(10);
+ usec -= 10;
} while (usec > 0);
return -ETIMEDOUT;
}
Otherwise It might just be that using LPM timeout values known to work with
Intel hosts don't really work with others.
(That's why we got the Intel specific timeout u1 and u2 timeout calculation)
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
