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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
