We're trying to get USB host mode working on a Freescale i.MX233. I'm using a chumby hacker board, but there are several people trying on an OlinuXino board as well. We're running into a problem where every time the root hub is detected, it's disconnected. This results in kernel messages such as: [ 66.410000] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.630000] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.850000] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 67.070000] hub 1-0:1.0: unable to enumerate USB device on port 1 It looks like we're running into this chip issue described in the i.MX233 reference manual: > For host mode, enables high-speed disconnect detector. This signal > allows the override of enabling the detection that is normally done in > the UTMI controller. The UTMI controller enables this circuit whenever > the host sends a start-of-frame packet. Due to a on chip issue (Errata > #2791), software must pay attention to when to assert the > ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register: > 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed > host mode. > 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset > and speed negotiation period. > 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host > suspend/resume sequence. We suspect this because we can get it to detect a USB device when it first boots by applying the following patch: diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c index c1a67cb..23eeae6 100644 --- a/drivers/usb/otg/mxs-phy.c +++ b/drivers/usb/otg/mxs-phy.c @@ -81,8 +81,6 @@ static int mxs_phy_on_connect(struct usb_phy *phy, int port) dev_dbg(phy->dev, "Connect on port %d\n", port); mxs_phy_hw_init(to_mxs_phy(phy)); - writel_relaxed(BM_USBPHY_CTRL_ENHOSTDISCONDETECT, - phy->io_priv + HW_USBPHY_CTRL_SET); return 0; } On platforms where a hub is connected to the device, this works fine, as the hub will never be connected and we can rely on disconnect messages coming from the downstream hub. But on boards where USB devices may be connected directly to the processor, only the first device connected to the system will work. I think the controller will need to be modified to detect whether it's running on an i.MX233 or not, and to call the PHY to re-enable disconnect detection if it sees a hub successfully added. In this case, it's a ci13xxx. Where would the best place be to add this callback? Can anyone at Freescale comment on this particular chip quirk? I don't see #2791 in the chip errata document. And is this quirk present on any other devices supported by the mxs_phy driver, or is it purely an i.MX233-specific quirk? -- Sean Cross -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
