Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-11-03 Thread Simon Horman 
On Fri, Oct 31, 2014 at 01:22:22PM +, yoshihiro shimoda wrote:
 Hi Simon-san,
 
  On Fri, Oct 31, 2014 at 02:06:14AM +, 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 ee00.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed 
 with error -2
 xhci-hcd ee00.usb: can't setup: -2
 xhci-hcd ee00.usb: USB bus 1 deregistered
 xhci-hcd: probe of ee00.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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-10-31 Thread yoshihiro shimoda 
Hi Simon-san,

 On Fri, Oct 31, 2014 at 02:06:14AM +, 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 ee00.usb: Direct firmware load for r8a779x_usb3_v1.dlmem failed 
with error -2
xhci-hcd ee00.usb: can't setup: -2
xhci-hcd ee00.usb: USB bus 1 deregistered
xhci-hcd: probe of ee00.usb failed with error -2

Best regards,
Yoshihiro Shimoda

--
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

RE: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-10-30 Thread yoshihiro shimoda 
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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-10-30 Thread Simon Horman 
On Fri, Oct 31, 2014 at 02:06:14AM +, 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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-10-29 Thread Yoshihiro Shimoda 
Hi Magnus-san,

(2014/10/29 15:53), Magnus Damm wrote:
 On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda
 yoshihiro.shimoda...@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 ee00.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 :02:02.0  /sys/bus/pci/drivers/ehci-pci/unbind
   echo :02:01.0  /sys/bus/pci/drivers/ohci-pci/unbind
   echo ee00.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 e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot 
 claim for ee00.usb
 sh-pfc e606.pfc: pin-182 (ee00.usb) status -22
 ata1: SATA link down (SStatus 0 SControl 300)
 sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2  on 
 device sh-pfc

 Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-10-29 Thread Simon Horman 
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...@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 ee00.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 :02:02.0  /sys/bus/pci/drivers/ehci-pci/unbind
echo :02:01.0  /sys/bus/pci/drivers/ohci-pci/unbind
echo ee00.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 e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot 
  claim for ee00.usb
  sh-pfc e606.pfc: pin-182 (ee00.usb) status -22
  ata1: SATA link down (SStatus 0 SControl 300)
  sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2  
  on device sh-pfc
 
  Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0

2014-10-24 Thread Yoshihiro Shimoda 
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 ee00.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 :02:02.0  /sys/bus/pci/drivers/ehci-pci/unbind
  echo :02:01.0  /sys/bus/pci/drivers/ohci-pci/unbind
  echo ee00.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 e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot 
claim for ee00.usb
sh-pfc e606.pfc: pin-182 (ee00.usb) status -22
ata1: SATA link down (SStatus 0 SControl 300)
sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2  on 
device sh-pfc

Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
 arch/arm/boot/dts/r8a7790-lager.dts |6 ++
 1 file changed, 6 insertions(+)

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;
-- 
1.7.9.5

--
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