| Message ID | 1461232154-7420-1-git-send-email-yoshihiro.shimoda.uh@renesas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
Yoshihiro Shimoda <yoshihiro.shimoda.uh@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 ? > So, this patch modifies the xhci_rcar_init_quirk() in xhci-rcar.h > to exit the probe function immediately. > > Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers) > Cc: <stable@vger.kernel.org> # v3.17+ > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> > --- > drivers/usb/host/xhci-rcar.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/host/xhci-rcar.h b/drivers/usb/host/xhci-rcar.h > index 2941a25..2afed68 100644 > --- a/drivers/usb/host/xhci-rcar.h > +++ b/drivers/usb/host/xhci-rcar.h > @@ -24,7 +24,11 @@ static inline void xhci_rcar_start(struct usb_hcd *hcd) > > static inline int xhci_rcar_init_quirk(struct usb_hcd *hcd) > { > - return 0; > + /* > + * To avoid wait and timeout in xhci_reset() if CONFIG_XHCI_RCAR is > + * disabled, this function fails. > + */ > + return -ENODEV; > } > #endif > #endif /* _XHCI_RCAR_H */ > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Felipe, > From: Felipe Balbi > Sent: Thursday, April 21, 2016 7:05 PM > > Yoshihiro Shimoda <yoshihiro.shimoda.uh@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; 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. Should I revise the commit log in detail? Best regards, Yoshihiro Shimoda
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> writes: > Hi Felipe, > >> From: Felipe Balbi >> Sent: Thursday, April 21, 2016 7:05 PM >> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@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 ? > 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. > 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.
Hi Felipe, > From: Felipe Balbi > Sent: Thursday, April 21, 2016 7:19 PM > > Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> writes: > > > Hi Felipe, > > > >> From: Felipe Balbi > >> Sent: Thursday, April 21, 2016 7:05 PM > >> > >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@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
On Thu, Apr 21, 2016 at 12:27 PM, Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> wrote: >> > [ 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. The main clock crystal on Salvator-X is half of the expected value. But despite the correct value being in the DTS, there's some timer code that doesn't take this into account. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, Geert Uytterhoeven <geert@linux-m68k.org> writes: > On Thu, Apr 21, 2016 at 12:27 PM, Yoshihiro Shimoda > <yoshihiro.shimoda.uh@renesas.com> wrote: >>> > [ 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. > > The main clock crystal on Salvator-X is half of the expected value. But > despite the correct value being in the DTS, there's some timer code that > doesn't take this into account. cool, thanks for the note. One problem down.
Hi, > From: linux-renesas-soc-owner@vger.kernel.org [mailto:linux-renesas-soc-owner@vger.kernel.org] On Behalf Of Yoshihiro > Shimoda > Sent: Thursday, April 21, 2016 7:28 PM > > Hi Felipe, > > > From: Felipe Balbi > > Sent: Thursday, April 21, 2016 7:19 PM > > > > Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> writes: > > > > > Hi Felipe, > > > > > >> From: Felipe Balbi > > >> Sent: Thursday, April 21, 2016 7:05 PM > > >> > > >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@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. According to the HW team of R-Car SoCs, the firmware of R-Car USB 3.0 host controller will control the reset. So, if the xhci-rcar driver doesn't do firmware downloading, the reset of USB3.0 host controller doesn't work correctly. The HW team intends to describe this specification on next datasheet revision. (In other words, the current datasheet doesn't mention exactly about this.) So, I will revise the commit log and submit such a patch later. Best regards, Yoshihiro Shimoda > Best regards, > Yoshihiro Shimoda > > > -- > > balbi
Hi, Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> writes: >> > > 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. > > According to the HW team of R-Car SoCs, the firmware of R-Car USB 3.0 host controller > will control the reset. So, if the xhci-rcar driver doesn't do firmware downloading, > the reset of USB3.0 host controller doesn't work correctly. > The HW team intends to describe this specification on next datasheet revision. > (In other words, the current datasheet doesn't mention exactly about this.) that explains it, thanks :-) > So, I will revise the commit log and submit such a patch later. great, thanks
Hi Shimoda-san, On Thu, Apr 21, 2016 at 2:57 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Apr 21, 2016 at 12:27 PM, Yoshihiro Shimoda > <yoshihiro.shimoda.uh@renesas.com> wrote: >>> > [ 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. > > The main clock crystal on Salvator-X is half of the expected value. But > despite the correct value being in the DTS, there's some timer code that > doesn't take this into account. It's fixed by upgrading to bootloader v270: -Architected cp15 timer(s) running at 16.66MHz (virt). +Architected cp15 timer(s) running at 8.33MHz (virt). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert-san, > From: Geert Uytterhoeven > Sent: Monday, April 25, 2016 11:57 PM > > Hi Shimoda-san, > > On Thu, Apr 21, 2016 at 2:57 PM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > On Thu, Apr 21, 2016 at 12:27 PM, Yoshihiro Shimoda > > <yoshihiro.shimoda.uh@renesas.com> wrote: > >>> > [ 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. > > > > The main clock crystal on Salvator-X is half of the expected value. But > > despite the correct value being in the DTS, there's some timer code that > > doesn't take this into account. > > It's fixed by upgrading to bootloader v270: > > -Architected cp15 timer(s) running at 16.66MHz (virt). > +Architected cp15 timer(s) running at 8.33MHz (virt). Thank you for the comment! Yes, the timer works correct on my environment. echo do > /dev/kmsg; sleep 60; echo done > /dev/kmsg [ 169.784474] do [ 229.791962] done However, the xhci timeout is still about 20 seconds. So, I investigated this issue more. Then, it seemed that readl() in xhci_handshake() is large delay (about 10 seconds) when the xhci driver didn't do firmware downloading. Best regards, Yoshihiro Shimoda > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
diff --git a/drivers/usb/host/xhci-rcar.h b/drivers/usb/host/xhci-rcar.h index 2941a25..2afed68 100644 --- a/drivers/usb/host/xhci-rcar.h +++ b/drivers/usb/host/xhci-rcar.h @@ -24,7 +24,11 @@ static inline void xhci_rcar_start(struct usb_hcd *hcd) static inline int xhci_rcar_init_quirk(struct usb_hcd *hcd) { - return 0; + /* + * To avoid wait and timeout in xhci_reset() if CONFIG_XHCI_RCAR is + * disabled, this function fails. + */ + return -ENODEV; } #endif #endif /* _XHCI_RCAR_H */
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. So, this patch modifies the xhci_rcar_init_quirk() in xhci-rcar.h to exit the probe function immediately. Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers) Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> --- drivers/usb/host/xhci-rcar.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)