| Message ID | 1414147307-4584-3-git-send-email-yoshihiro.shimoda.uh@renesas.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 37f7c1b0c1ed9465b2e2609ba57bba8a874ddd3c |
| Headers | show |
On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> wrote: > Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 > driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: > > phy phy-e6590100.usb-phy.3: phy init failed --> -16 > xhci-hcd: probe of ee000000.usb failed with error -16 > > If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind > the USB3.0 driver as the following: > > echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind > echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind > echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind > > Note that there will be pinctrl-related error messages if both > internal PCI and USB3.0 are enabled but they should be just ignored: > > sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb > sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22 > ata1: SATA link down (SStatus 0 SControl 300) > sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2 on device sh-pfc > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> > --- > arch/arm/boot/dts/r8a7790-lager.dts | 6 ++++++ > 1 file changed, 6 insertions(+) Hi Shimoda-san, Thanks for your patch. I'm fine with this patch as a first step, but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? Is the current order just based on device init order? In my mind the expected behavior would be to always use USB 3.0 if it happens to be available in the hardware, specified in the DTS, enabled by the kernel configuration and firmware is loadable. Or does some case exist where it is better to use USB 2.0? I suspect no. So I wonder if you have any plans how to make USB 3.0 enabled by default on Lager? Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus-san, (2014/10/29 15:53), Magnus Damm wrote: > On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda > <yoshihiro.shimoda.uh@renesas.com> wrote: >> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 >> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: >> >> phy phy-e6590100.usb-phy.3: phy init failed --> -16 >> xhci-hcd: probe of ee000000.usb failed with error -16 >> >> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind >> the USB3.0 driver as the following: >> >> echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind >> echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind >> echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind >> >> Note that there will be pinctrl-related error messages if both >> internal PCI and USB3.0 are enabled but they should be just ignored: >> >> sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb >> sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22 >> ata1: SATA link down (SStatus 0 SControl 300) >> sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2 on device sh-pfc >> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> >> --- >> arch/arm/boot/dts/r8a7790-lager.dts | 6 ++++++ >> 1 file changed, 6 insertions(+) > > Hi Shimoda-san, > > Thanks for your patch. I'm fine with this patch as a first step, but > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? I investigated this reason today, and I found the reason is request_firmware(). I checked the following environments: Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled The results are: - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware. - In "Case 2" and "Case 3", xHCI is probed first. > Is the current order just based on device init order? In my mind the > expected behavior would be to always use USB 3.0 if it happens to be > available in the hardware, specified in the DTS, enabled by the kernel > configuration and firmware is loadable. Or does some case exist where > it is better to use USB 2.0? I suspect no. I agree with you. > So I wonder if you have any plans how to make USB 3.0 enabled by > default on Lager? It depends on a kernel config. I'm not sure of the shmobile_defconfig strategy. But, in my opinion, one of a solution is kernel modules (this means the "Case 2".) Best regards, Yoshihiro Shimoda > Thanks, > > / magnus > -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote: > Hi Magnus-san, > > (2014/10/29 15:53), Magnus Damm wrote: > > On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda > > <yoshihiro.shimoda.uh@renesas.com> wrote: > >> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 > >> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: > >> > >> phy phy-e6590100.usb-phy.3: phy init failed --> -16 > >> xhci-hcd: probe of ee000000.usb failed with error -16 > >> > >> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind > >> the USB3.0 driver as the following: > >> > >> echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind > >> echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind > >> echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind > >> > >> Note that there will be pinctrl-related error messages if both > >> internal PCI and USB3.0 are enabled but they should be just ignored: > >> > >> sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb > >> sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22 > >> ata1: SATA link down (SStatus 0 SControl 300) > >> sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2 on device sh-pfc > >> > >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> > >> --- > >> arch/arm/boot/dts/r8a7790-lager.dts | 6 ++++++ > >> 1 file changed, 6 insertions(+) > > > > Hi Shimoda-san, > > > > Thanks for your patch. I'm fine with this patch as a first step, but > > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? > > I investigated this reason today, and I found the reason is > request_firmware(). I checked the following environments: > > Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI > and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are > enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled > > The results are: - In "Case 1", EHCI and OHCI are probed first because > xHCI didn't find the firmware. - In "Case 2" and "Case 3", xHCI is > probed first. > > > Is the current order just based on device init order? In my mind the > > expected behavior would be to always use USB 3.0 if it happens to be > > available in the hardware, specified in the DTS, enabled by the kernel > > configuration and firmware is loadable. Or does some case exist where > > it is better to use USB 2.0? I suspect no. > > I agree with you. > > > So I wonder if you have any plans how to make USB 3.0 enabled by > > default on Lager? > > It depends on a kernel config. I'm not sure of the shmobile_defconfig > strategy. But, in my opinion, one of a solution is kernel modules (this > means the "Case 2".) It sounds like we should enable CONFIG_EXTRA_FIRMWARE in shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Simon-san, > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote: > > Hi Magnus-san, > > > > (2014/10/29 15:53), Magnus Damm wrote: < snip > > > > > > > Hi Shimoda-san, > > > > > > Thanks for your patch. I'm fine with this patch as a first step, but > > > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? > > > > I investigated this reason today, and I found the reason is > > request_firmware(). I checked the following environments: > > > > Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI > > and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are > > enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled > > > > The results are: - In "Case 1", EHCI and OHCI are probed first because > > xHCI didn't find the firmware. - In "Case 2" and "Case 3", xHCI is > > probed first. > > > > > Is the current order just based on device init order? In my mind the > > > expected behavior would be to always use USB 3.0 if it happens to be > > > available in the hardware, specified in the DTS, enabled by the > > > kernel configuration and firmware is loadable. Or does some case > > > exist where it is better to use USB 2.0? I suspect no. > > > > I agree with you. > > > > > So I wonder if you have any plans how to make USB 3.0 enabled by > > > default on Lager? > > > > It depends on a kernel config. I'm not sure of the shmobile_defconfig > > strategy. But, in my opinion, one of a solution is kernel modules > > (this means the "Case 2".) > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in shmobile_defconfig. I wonder what if any fallout we can foresee > occurring if we do that. According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory now. So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't exist in the linux.git. === from firmware/README.AddingFirmware ===================================== This directory is _NOT_ for adding arbitrary new firmware images. The place to add those is the separate linux-firmware repository: git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git ============================================================================== Best regards, Yoshihiro Shimoda -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote: > Hi Simon-san, > > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote: > > > Hi Magnus-san, > > > > > > (2014/10/29 15:53), Magnus Damm wrote: > < snip > > > > > > > > > Hi Shimoda-san, > > > > > > > > Thanks for your patch. I'm fine with this patch as a first step, but > > > > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? > > > > > > I investigated this reason today, and I found the reason is > > > request_firmware(). I checked the following environments: > > > > > > Case 1: xHCI and EHCI and OHCI are enabled "=y" > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m" > > > Case 3: xHCI and EHCI and OHCI are enabled "=y", > > > and CONFIG_EXTRA_FIRMWARE is enabled > > > > > > The results are: > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware. > > > - In "Case 2" and "Case 3", xHCI is probed first. > > > > > > > Is the current order just based on device init order? In my mind the > > > > expected behavior would be to always use USB 3.0 if it happens to be > > > > available in the hardware, specified in the DTS, enabled by the > > > > kernel configuration and firmware is loadable. Or does some case > > > > exist where it is better to use USB 2.0? I suspect no. > > > > > > I agree with you. > > > > > > > So I wonder if you have any plans how to make USB 3.0 enabled by > > > > default on Lager? > > > > > > It depends on a kernel config. I'm not sure of the shmobile_defconfig > > > strategy. But, in my opinion, one of a solution is kernel modules > > > (this means the "Case 2".) > > > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in shmobile_defconfig. I wonder what if any fallout we can foresee > > occurring if we do that. > > According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory now. > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't exist in the linux.git. > > === from firmware/README.AddingFirmware ===================================== > This directory is _NOT_ for adding arbitrary new firmware images. The > place to add those is the separate linux-firmware repository: > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > ============================================================================== Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point of view after all. Is the problem in case 1 that the firmware can't be found because userspace does exist yet and thus can't be loaded from there? -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Simon-san, > On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote: > > Hi Simon-san, > > > > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote: > > > > Hi Magnus-san, > > > > > > > > (2014/10/29 15:53), Magnus Damm wrote: > > < snip > > > > > > > > > > > Hi Shimoda-san, > > > > > > > > > > Thanks for your patch. I'm fine with this patch as a first step, > > > > > but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? > > > > > > > > I investigated this reason today, and I found the reason is > > > > request_firmware(). I checked the following environments: > > > > > > > > Case 1: xHCI and EHCI and OHCI are enabled "=y" > > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m" > > > > Case 3: xHCI and EHCI and OHCI are enabled "=y", > > > > and CONFIG_EXTRA_FIRMWARE is enabled > > > > > > > > The results are: > > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware. > > > > - In "Case 2" and "Case 3", xHCI is probed first. > > > > > > > > > Is the current order just based on device init order? In my mind > > > > > the expected behavior would be to always use USB 3.0 if it > > > > > happens to be available in the hardware, specified in the DTS, > > > > > enabled by the kernel configuration and firmware is loadable. Or > > > > > does some case exist where it is better to use USB 2.0? I suspect no. > > > > > > > > I agree with you. > > > > > > > > > So I wonder if you have any plans how to make USB 3.0 enabled by > > > > > default on Lager? > > > > > > > > It depends on a kernel config. I'm not sure of the > > > > shmobile_defconfig strategy. But, in my opinion, one of a > > > > solution is kernel modules (this means the "Case 2".) > > > > > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in > > > shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that. > > > > According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory > now. > > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't > exist in the linux.git. > > > > === from firmware/README.AddingFirmware > > ===================================== > > This directory is _NOT_ for adding arbitrary new firmware images. The > > place to add those is the separate linux-firmware repository: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware. > > git > > ====================================================================== > > ======== > > Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point of view after all. > > Is the problem in case 1 that the firmware can't be found because userspace does exist yet and thus can't be loaded from > there? That's correct. If EXTRA_FIRMWARE is not set, the following error happens: xhci-hcd ee000000.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed with error -2 xhci-hcd ee000000.usb: can't setup: -2 xhci-hcd ee000000.usb: USB bus 1 deregistered xhci-hcd: probe of ee000000.usb failed with error -2 Best regards, Yoshihiro Shimoda -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 31, 2014 at 01:22:22PM +0000, yoshihiro shimoda wrote: > Hi Simon-san, > > > On Fri, Oct 31, 2014 at 02:06:14AM +0000, yoshihiro shimoda wrote: > > > Hi Simon-san, > > > > > > > On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote: > > > > > Hi Magnus-san, > > > > > > > > > > (2014/10/29 15:53), Magnus Damm wrote: > > > < snip > > > > > > > > > > > > > Hi Shimoda-san, > > > > > > > > > > > > Thanks for your patch. I'm fine with this patch as a first step, > > > > > > but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? > > > > > > > > > > I investigated this reason today, and I found the reason is > > > > > request_firmware(). I checked the following environments: > > > > > > > > > > Case 1: xHCI and EHCI and OHCI are enabled "=y" > > > > > Case 2: xHCI and EHCI and OHCI are loadable modules "=m" > > > > > Case 3: xHCI and EHCI and OHCI are enabled "=y", > > > > > and CONFIG_EXTRA_FIRMWARE is enabled > > > > > > > > > > The results are: > > > > > - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware. > > > > > - In "Case 2" and "Case 3", xHCI is probed first. > > > > > > > > > > > Is the current order just based on device init order? In my mind > > > > > > the expected behavior would be to always use USB 3.0 if it > > > > > > happens to be available in the hardware, specified in the DTS, > > > > > > enabled by the kernel configuration and firmware is loadable. Or > > > > > > does some case exist where it is better to use USB 2.0? I suspect no. > > > > > > > > > > I agree with you. > > > > > > > > > > > So I wonder if you have any plans how to make USB 3.0 enabled by > > > > > > default on Lager? > > > > > > > > > > It depends on a kernel config. I'm not sure of the > > > > > shmobile_defconfig strategy. But, in my opinion, one of a > > > > > solution is kernel modules (this means the "Case 2".) > > > > > > > > It sounds like we should enable CONFIG_EXTRA_FIRMWARE in > > > > shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that. > > > > > > According to the firmware/README.AddingFirmware, we are unable to add a new firmware image to the firmware directory > > now. > > > So, if we enable CONFIG_EXTRA_FIRMWARE with the xHCI firmware, we will not build kernel because the xHCI firmware doesn't > > exist in the linux.git. > > > > > > === from firmware/README.AddingFirmware > > > ===================================== > > > This directory is _NOT_ for adding arbitrary new firmware images. The > > > place to add those is the separate linux-firmware repository: > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware. > > > git > > > ====================================================================== > > > ======== > > > > Thanks. It seems that EXTRA_FIRMWARE is not an option from a mainline point of view after all. > > > > Is the problem in case 1 that the firmware can't be found because userspace does exist yet and thus can't be loaded from > > there? > > That's correct. > If EXTRA_FIRMWARE is not set, the following error happens: > > xhci-hcd ee000000.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed with error -2 > xhci-hcd ee000000.usb: can't setup: -2 > xhci-hcd ee000000.usb: USB bus 1 deregistered > xhci-hcd: probe of ee000000.usb failed with error -2 At the risk of adding noise to this discussion: It seems like case 2 with a fallback to case 3 is the way to go. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts index 2115de2..b48173b 100644 --- a/arch/arm/boot/dts/r8a7790-lager.dts +++ b/arch/arm/boot/dts/r8a7790-lager.dts @@ -419,6 +419,12 @@ pinctrl-names = "default"; }; +&xhci { + status = "okay"; + pinctrl-0 = <&usb2_pins>; + pinctrl-names = "default"; +}; + &pci2 { status = "okay"; pinctrl-0 = <&usb2_pins>;
Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: phy phy-e6590100.usb-phy.3: phy init failed --> -16 xhci-hcd: probe of ee000000.usb failed with error -16 If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind the USB3.0 driver as the following: echo 0000:02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind echo 0000:02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind echo ee000000.usb > /sys/bus/platform/drivers/xhci-hcd/bind Note that there will be pinctrl-related error messages if both internal PCI and USB3.0 are enabled but they should be just ignored: sh-pfc e6060000.pfc: pin GP_5_22 already requested by ee0d0000.pci; cannot claim for ee000000.usb sh-pfc e6060000.pfc: pin-182 (ee000000.usb) status -22 ata1: SATA link down (SStatus 0 SControl 300) sh-pfc e6060000.pfc: could not request pin 182 (GP_5_22) from group usb2 on device sh-pfc Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> --- arch/arm/boot/dts/r8a7790-lager.dts | 6 ++++++ 1 file changed, 6 insertions(+)