usbh1 only works when booted plugged in. (mainline linux 3.17)

cancel
Showing results for 
Search instead for 
Did you mean: 

usbh1 only works when booted plugged in. (mainline linux 3.17)

Jump to solution
2,403 Views
Contributor III

I am in the process up porting an imx6q board from a 3.0.35 kernel to mainline 3.17

the board has usbotg and usbh1, with usbh1 connected to an onboard  usb hub chip (USB2513BI-AEZG).

usbh1 works when it is plugged in at boot, but not if it is plugged in later. It also does not work if I unplug it and plug it back in.

When I unplug the usb device:

root@EVi ~$ [  148.962971] usb 1-1.1: USB disconnect, device number 3

When I plug the usb device in:

root@EVi ~$ [  156.610650] usb 1-1: USB disconnect, device number 2

[  156.629883] usb usb1-port1: cannot reset (err = -32)

[  156.638274] usb usb1-port1: cannot reset (err = -32)

[  156.643533] usb usb1-port1: cannot reset (err = -32)

[  156.651132] usb usb1-port1: cannot reset (err = -32)

[  156.656248] usb usb1-port1: cannot reset (err = -32)

[  156.661331] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

[  156.669355] usb usb1-port1: cannot reset (err = -32)

[  156.674603] usb usb1-port1: cannot reset (err = -32)

[  156.679698] usb usb1-port1: cannot reset (err = -32)

[  156.684947] usb usb1-port1: cannot reset (err = -32)

[  156.690039] usb usb1-port1: cannot reset (err = -32)

[  156.695087] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

[  156.702029] usb usb1-port1: cannot reset (err = -32)

[  156.707118] usb usb1-port1: cannot reset (err = -32)

[  156.712595] usb usb1-port1: cannot reset (err = -32)

[  156.717799] usb usb1-port1: cannot reset (err = -32)

[  156.722846] usb usb1-port1: cannot reset (err = -32)

[  156.727822] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

[  156.734516] usb usb1-port1: cannot reset (err = -32)

[  156.739540] usb usb1-port1: cannot reset (err = -32)

[  156.744586] usb usb1-port1: cannot reset (err = -32)

[  156.749609] usb usb1-port1: cannot reset (err = -32)

[  156.754654] usb usb1-port1: cannot reset (err = -32)

[  156.759628] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

[  156.766248] usb usb1-port1: unable to enumerate USB device

I've tried everything I can think of in my dts.

...

                reg_5p0v: regulator@2 {

                        compatible = "regulator-fixed";

                        reg = <2>;

                        regulator-name = "5P0V";

                        regulator-min-microvolt = <5000000>;

                        regulator-max-microvolt = <5000000>;

                        regulator-boot-on;

                        regulator-always-on;

                };

&usbh1 {

        vbus-supply = <&reg_5p0v>;

        pinctrl-names = "default";

        pinctrl-0 = <&pinctrl_usbh1>;

        disable-over-current;

        status = "okay";

};

There s a GPIO connected to the usb hubs reset line... but it was never used with 3.0.35 and the usbh1 worked.

I'm not sure how to use the gpio reset this way if it is needed. If there is an example I have not found it.

0 Kudos
1 Solution
52 Views
NXP Employee
NXP Employee

If you look at the udoo schematics you will see the hub there ;-)

When I added usb host support to udoo board I also got a hard time to model the hub, as there is no way via device tree to describe it currently.

The reg_usb_vbus was kind of a 'hack' a did. The gpio controlled by reg_usb_vbus is the reset line that goes to the hub.

So you could try to see if it works for you. If still does not work then you need to check with a scope the reset, clock and power to the hub.

View solution in original post

0 Kudos
14 Replies
52 Views
NXP Employee
NXP Employee

Hi,

usbh1 works when it is plugged in at boot, but not if it is plugged in later. It also does not work if I unplug it and plug it back in

what do you mean? Do you plug out the hub or plug out the device that plugged in the hub?

In addition, I wonder why do you port 3.0.35 usb driver to 3.17. In 3.0.35, we adopt the ARC usb driver, in 3.10 and later, we adopt chipidea usb driver and ARC driver is deprecated!

52 Views
Contributor III

The hub is soldered to the circuit board, so it can't be physically unplugged.

I mean unplugging the device.

It does look like for some reason, when I plug in a device, the kernel is getting a disconnect event for the hub.

0 Kudos
52 Views
NXP Employee
NXP Employee

er, in my opinion, if in this case, it is related to your hub driver or hub hardware. Maybe it is only a hardware issue and you need to pass the usb eye-diagram.

52 Views
Contributor III

I have finally made some progress on this issue.

I got a board with the hub chip removed.

I enabled both usbh1 and osbotg.

I added

dr_mode="host"

to dts for both usbh1 AND usbotg nodes

Now usb works with chipidea driver.

THAT issue seems like a kernel driver issue (bug?) in 3.18, unless there is a connection I don't understand between otg and usbh1

But it only works with the hub chip removed.

Normal board with the hub chip fails to enumerate. Now with:

[    2.809099] usb 2-1: device descriptor read/64, error -71

[    3.129161] usb 2-1: device descriptor read/64, error -71

[    3.359145] usb 2-1: new full-speed USB device number 3 using ci_hdrc

[    3.579176] usb 2-1: device descriptor read/64, error -71

[    3.899157] usb 2-1: device descriptor read/64, error -71

[    4.129131] usb 2-1: new full-speed USB device number 4 using ci_hdrc

[    4.609056] usb 2-1: device not accepting address 4, error -71

[    4.729144] usb 2-1: new full-speed USB device number 5 using ci_hdrc

[    5.209059] usb 2-1: device not accepting address 5, error -71

[    5.215016] usb usb2-port1: unable to enumerate USB device

The hub chip also has a hardware reset line, I haven't figured out how to properly support. When I put it into and out of reset using userspace gpio access I trigger the above error again and again with ascending address numbers.

There may also be issues that need to be worked out with the hardware. Maybe its my dts. Maybe there is a problem with the driver.

I'm not ruling anything out a this point.

0 Kudos
52 Views
NXP Employee
NXP Employee

Hi, Joshoa

I remember there is an errata for USB HS device. When the host is connected to a HS device, it will not recognize this HS device and prompt similiar log as you paste. I'm not sure it is related to this errata, so can you ensure that:

  1. do your driver support runtime PM?
  2. is your HUB a HS device?
  3. whether your hub is reset after boot?
0 Kudos
52 Views
Contributor III

Not sure what "HS" device means. the hub is a USB2513BI-AEZG, which is a USB 2.0 highspeed hub with up to three ports.

It has its own clock and power, and we are configuring it using "pinstrapping" rather than i2c

The only connection to the IMX6q are the USBDN_DP1, USBDN_DM1, the overcurrent line, and a gpio to the reset line.

0 Kudos
52 Views
NXP Employee
NXP Employee

Joshua,

imx6q-udoo.dts also has usbh1 connected to a hub. You can take a look at it for reference.

0 Kudos
52 Views
Contributor III

imx6q-udoo.dts doesn't have any reference to a hub that I can find... unless it is the reg_usb_vbus, which has a startup delay and gpio...  I guess I can try that even though in my case there is not a real vbus involved.


btw in case anybody else comes across this:

yesterday I tried adding:


diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts

index 4af6a84..d8d44f8 100644

--- a/arch/arm/boot/dts/imx6q-evi.dts

+++ b/arch/arm/boot/dts/imx6q-evi.dts

@@ -55,11 +55,16 @@

                        regulator-always-on;

                };

        };

+

+       usbh1_phy2: usb2131bi@0 {

+               compatible = "usb-nop-xceiv";

+               reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;

+       };

};

@@ -192,6 +201,7 @@

        vbus-supply = <&reg_usbh1_vbus>;

        pinctrl-names = "default";

        pinctrl-0 = <&pinctrl_usbh1>;

+       fsl,usbphy = <&usbh1_phy2>;

        dr_mode = "host";

        disable-over-current;

        status = "okay";

... and it just locked up my board on boot:

[    2.147279] ci_hdrc ci_hdrc.0: EHCI Host Controller

[    2.152473] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1

[    2.173116] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00

[    2.181926] hub 1-0:1.0: USB hub found

[    2.185933] hub 1-0:1.0: 1 port detected

[    2.216043] ci_hdrc ci_hdrc.1: EHCI Host Controller

[    2.221005] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2

[    2.243102] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00

[    2.250638] hub 2-0:1.0: USB hub found

[    2.254500] hub 2-0:1.0: 1 port detected

0 Kudos
53 Views
NXP Employee
NXP Employee

If you look at the udoo schematics you will see the hub there ;-)

When I added usb host support to udoo board I also got a hard time to model the hub, as there is no way via device tree to describe it currently.

The reg_usb_vbus was kind of a 'hack' a did. The gpio controlled by reg_usb_vbus is the reset line that goes to the hub.

So you could try to see if it works for you. If still does not work then you need to check with a scope the reset, clock and power to the hub.

View solution in original post

0 Kudos
52 Views
Contributor III

That did it!

I added the reset gpio to the bogus vbus for usbh1 like imx6q-udoo.dts

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts

index 4af6a84..0563cbd 100644

--- a/arch/arm/boot/dts/imx6q-evi.dts

+++ b/arch/arm/boot/dts/imx6q-evi.dts

@@ -39,7 +39,9 @@

                        regulator-name = "usbh1_vbus";

                        regulator-min-microvolt = <5000000>;

                        regulator-max-microvolt = <5000000>;

-                       regulator-always-on;

+                       enable-active-high;

+                       startup-delay-us = <2>;

+                       gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;

                };

Thank you Fabio Estevam,

and thank you Tao Zheng.

0 Kudos
52 Views
NXP Employee
NXP Employee

Joshua,

Today I was working on imx51-babbage and I noticed an issue on getting usb to work (also via a hub) with mainline.

I fixed it with this change:

http://permalink.gmane.org/gmane.linux.ports.arm.kernel/380061

For the hub reset, maybe you can use the usb-nop-xceiv; Take a look at: Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt, and you will find a reset-gpios that will probably fit into what you need.

Also, check with the scope if the hub is getting proper power, clock and the level of the reset line is sane.

0 Kudos
52 Views
NXP Employee
NXP Employee

Hi, Fabio

It seems that your problem that has been fixed is different from this case. usb_nop_xceiv is used for phy which is integrated into USB Core IP. But our usb phy for OTG or Host1 is standalone with USB Core IP and we adopt phy-mxs-usb.c. Host 2 or Host 3 are HSIC port and there are no phy for them, so we adopt nop-phy.

0 Kudos
52 Views
NXP Employee
NXP Employee

Hi Tao Zheng,

Actually usb_nop_xceiv is used for external PHY transceivers, not internal ones.

0 Kudos
52 Views
NXP Employee
NXP Employee

Also, another hint that helped me debugging the kernel issue was to get USB to work in U-boot first.

0 Kudos