From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: "Simon Horman [Horms]" <horms@verge.net.au>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linux-USB <linux-usb@vger.kernel.org>,
SH-Linux <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0
Date: Wed, 29 Oct 2014 11:19:30 +0000 [thread overview]
Message-ID: <5450CD42.9070101@renesas.com> (raw)
In-Reply-To: <CANqRtoQTBd23z4uVK-EB7JJuJ_K0GkV6ueVfnywShqe6Dx0T5w@mail.gmail.com>
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
>
WARNING: multiple messages have this Message-ID (diff)
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: "Simon Horman [Horms]" <horms@verge.net.au>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linux-USB <linux-usb@vger.kernel.org>,
SH-Linux <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0
Date: Wed, 29 Oct 2014 20:19:30 +0900 [thread overview]
Message-ID: <5450CD42.9070101@renesas.com> (raw)
In-Reply-To: <CANqRtoQTBd23z4uVK-EB7JJuJ_K0GkV6ueVfnywShqe6Dx0T5w@mail.gmail.com>
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
>
next prev parent reply other threads:[~2014-10-29 11:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 10:41 [PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790 Yoshihiro Shimoda
2014-10-24 10:41 ` Yoshihiro Shimoda
2014-10-24 10:41 ` [PATCH v2 1/2] ARM: shmobile: r8a7790: add USB3.0 device node Yoshihiro Shimoda
2014-10-24 10:41 ` Yoshihiro Shimoda
2014-10-24 10:41 ` [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0 Yoshihiro Shimoda
2014-10-24 10:41 ` Yoshihiro Shimoda
[not found] ` <1414147307-4584-3-git-send-email-yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
2014-10-29 6:53 ` Magnus Damm
2014-10-29 6:53 ` Magnus Damm
2014-10-29 11:19 ` Yoshihiro Shimoda [this message]
2014-10-29 11:19 ` Yoshihiro Shimoda
2014-10-29 23:57 ` Simon Horman
2014-10-29 23:57 ` Simon Horman
2014-10-31 2:06 ` yoshihiro shimoda
2014-10-31 2:06 ` yoshihiro shimoda
2014-10-31 5:04 ` Simon Horman
2014-10-31 5:04 ` Simon Horman
2014-10-31 13:22 ` yoshihiro shimoda
2014-10-31 13:22 ` yoshihiro shimoda
2014-11-04 0:44 ` Simon Horman
2014-11-04 0:44 ` Simon Horman
2014-10-27 0:22 ` [PATCH v2 0/2] ARM: shmobile: add USB3.0 device node on r8a7790 Simon Horman
2014-10-27 0:22 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5450CD42.9070101@renesas.com \
--to=yoshihiro.shimoda.uh@renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=horms@verge.net.au \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-sh@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.