USB: usb-hub: Add a weak function for resetting devices

Hi Dan, guys,

Just would like to give my 5 cents: my humble experience with OMAP4 and OMAP5 tells me that this (that is, the need to reset devices after applying port power) seems to be a OMAP5 HSIC IP issue, and not a device problem. We at MMS have two custom designs, one with OMAP5430 and one with OMAP4460, both of which employ HSIC chips (LAN9730 and USB4640 on the OMAP5 board, and USB4640 on the OMAP4), along with a ULPI PHY (TUSB1210) on both boards. I had the pleasure of bringing up both boards with U-Boot a few months back, including USB EHCI, and can state the following:

Device reset after port power is applied is needed for the OMAP5 HSIC devices only. The ULPI PHY on both boards doesn't even have a hardware reset connected, nevertheless the device attached to it gets enumerated (even without performing PHY software reset via the ULPI viewport). I performed the HSIC device reset by calling a board function from within the ehci_hcd.c driver, which is compiled only for the OMAP5, and only if we have HSIC devices. An obsolete patch for this, working on my board, can still be found at http://patchwork.ozlabs.org/patch/232742/, as well as a RFC for the 5432uevm (untested) at http://patchwork.ozlabs.org/patch/244124/

On the OMAP4 board this reset is not needed, the HSIC device gets enumerated straightforward.

I don't know about other arches, but I'm not sure that having an unconditional common call, although weak, in usb_hub.c is the best solution.

Best regards,
Lubo

Lubo

Thanks for the reply

Quoted 27 lines · Lubomir Popov

Hi Dan, guys,

Just would like to give my 5 cents: my humble experience with OMAP4 and OMAP5 tells me that this (that is, the need to reset devices after applying port power) seems to be a OMAP5 HSIC IP issue, and not a device problem. We at MMS have two custom designs, one with OMAP5430 and one with OMAP4460, both of which employ HSIC chips (LAN9730 and USB4640 on the OMAP5 board, and USB4640 on the OMAP4), along with a ULPI PHY (TUSB1210) on both boards. I had the pleasure of bringing up both boards with U-Boot a few months back, including USB EHCI, and can state the following:

Device reset after port power is applied is needed for the OMAP5 HSIC devices only. The ULPI PHY on both boards doesn't even have a hardware reset connected, nevertheless the device attached to it gets enumerated (even without performing PHY software reset via the ULPI viewport). I performed the HSIC device reset by calling a board function from within the ehci_hcd.c driver, which is compiled only for the OMAP5, and only if we have HSIC devices. An obsolete patch for this, working on my board, can still be found at http://patchwork.ozlabs.org/patch/232742/, as well as a RFC for the 5432uevm (untested) at http://patchwork.ozlabs.org/patch/244124/

On the OMAP4 board this reset is not needed, the HSIC device gets enumerated straightforward.

Quoted 6 lines

I don't know about other arches, but I'm not sure that having an unconditional common call, although weak, in usb_hub.c is the best solution.

Best regards,
Lubo

I see your patches and see that you have added a omap5 specific call to reset the device in the ehci-hcd.c.

I originally had a similar implementation in ehci-hcd but decided to move it up to the usb-hub. http://patchwork.ozlabs.org/patch/258229/

But I can move it back since the patch exists.

This make it all board specific because as you point out it is only needed in HSIC connection

Crazy question was there any support documentation for the OMAP5 HSIC issue?

Lubo

Thanks for the reply

Quoted 27 lines · Lubomir Popov

Hi Dan, guys,

Just would like to give my 5 cents: my humble experience with OMAP4 and OMAP5 tells me that this (that is, the need to reset devices after applying port power) seems to be a OMAP5 HSIC IP issue, and not a device problem. We at MMS have two custom designs, one with OMAP5430 and one with OMAP4460, both of which employ HSIC chips (LAN9730 and USB4640 on the OMAP5 board, and USB4640 on the OMAP4), along with a ULPI PHY (TUSB1210) on both boards. I had the pleasure of bringing up both boards with U-Boot a few months back, including USB EHCI, and can state the following:

Device reset after port power is applied is needed for the OMAP5 HSIC devices only. The ULPI PHY on both boards doesn't even have a hardware reset connected, nevertheless the device attached to it gets enumerated (even without performing PHY software reset via the ULPI viewport). I performed the HSIC device reset by calling a board function from within the ehci_hcd.c driver, which is compiled only for the OMAP5, and only if we have HSIC devices. An obsolete patch for this, working on my board, can still be found at http://patchwork.ozlabs.org/patch/232742/, as well as a RFC for the 5432uevm (untested) at http://patchwork.ozlabs.org/patch/244124/

On the OMAP4 board this reset is not needed, the HSIC device gets enumerated straightforward.

Quoted 8 lines

I don't know about other arches, but I'm not sure that having an unconditional common call, although weak, in usb_hub.c is the best solution.

Best regards,
Lubo

I see your patches and see that you have added a omap5 specific call to reset the device in the ehci-hcd.c.

I originally had a similar implementation in ehci-hcd but decided to move it up to the usb-hub. http://patchwork.ozlabs.org/patch/258229/

But I can move it back since the patch exists.

This make it all board specific because as you point out it is only needed in HSIC connection

Crazy question was there any support documentation for the OMAP5 HSIC issue?

Dan

Signature · 2 lines

------------------
Dan Murphy