Hi Felipe, > From: Felipe Balbi > Sent: Thursday, April 21, 2016 7:19 PM > > Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> writes: > > > Hi Felipe, > > > >> From: Felipe Balbi > >> Sent: Thursday, April 21, 2016 7:05 PM > >> > >> Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> writes: > >> > >> > If kernel configuration is CONFIG_USB_XHCI_PLATFORM=y and > >> > CONFIG_USB_XHCI_RCAR is not set, R-Car Gen2/3 will cause long wait > >> > in xhci_reset() because such SoCs need specific initialization. > >> > >> where is the delay coming from exactly ? > > > > The delay is coming from the following code: > > > > ret = xhci_handshake(&xhci->op_regs->command, > > CMD_RESET, 0, 10 * 1000 * 1000); > > if (ret) > > return ret; > > okay, and why does reset fail ?
Oops, I don't know why. So, I will investigate it. > > And, kernel log is the following: > > > > [ 1.565605] xhci-hcd ee000000.usb: xHCI Host Controller > > [ 1.570636] xhci-hcd ee000000.usb: new USB bus registered, assigned bus > > number 5 > > [ 22.270160] xhci-hcd ee000000.usb: can't setup: -110 > > [ 22.274931] xhci-hcd ee000000.usb: USB bus 5 deregistered > > [ 22.280158] xhci-hcd: probe of ee000000.usb failed with error -110 > > > > The timestamp is strange to me. But, logs of R-Car H3 (ES1.0) and > > R-Car H2 were the same. > > yeah, seems like your system timer is counting twice for each tick. Yes, I will investigate this later. > > Should I revise the commit log in detail? > > Sure, but let's first why this is the case. It's unclear, to me at > least, why reset fails. I understood it. I will investigate why reset fails first. Best regards, Yoshihiro Shimoda > -- > balbi -- 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