Re: mxs-phy on i.MX233 not enumerating
On 8/14/12, Chen Peter-B29397 b29...@freescale.com wrote: HW_USBPHY_CTRL.ENHOSTDISCONDETECT should be set after bus reset is finished. I agree. How do we guarantee that ENHOSTDISCONDETECT is set after bus reset? Thanks, Fabio Estevam -- 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
mxs-phy on i.MX233 not enumerating
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.41] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.63] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.85] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 67.07] 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxs-phy on i.MX233 not enumerating
On 8/13/12, Sean Cross x...@xoblo.gs wrote: 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.41] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.63] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.85] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 67.07] 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; } I applied this change and it allowed a mx23-olinuxino board to detect a USB pen drive. Peter, Is this change related to this hack in FSL kernel? http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=commitdiff;h=c44dc00d2aecfcbf30336180f5ecd6a3a633545d What would be the proper way to handle HOSTDISCONDETECT so that it can work for mx23 as well? Thanks, Fabio Estevam -- 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: mxs-phy on i.MX233 not enumerating
Hi, On Mon, Aug 13, 2012 at 03:04:56PM -0300, Fabio Estevam wrote: On 8/13/12, Sean Cross x...@xoblo.gs wrote: 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.41] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.63] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.85] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 67.07] 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; } I applied this change and it allowed a mx23-olinuxino board to detect a USB pen drive. Peter, Is this change related to this hack in FSL kernel? http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=commitdiff;h=c44dc00d2aecfcbf30336180f5ecd6a3a633545d What would be the proper way to handle HOSTDISCONDETECT so that it can work for mx23 as well? Will there be another version for this or is this final ? Won't this cause any regressions to other boards ? -- balbi signature.asc Description: Digital signature
Re: mxs-phy on i.MX233 not enumerating
On 8/13/12, Felipe Balbi ba...@ti.com wrote: Will there be another version for this or is this final ? Won't this cause any regressions to other boards ? The proposed patch is not meant to be a final one. We still need to figure out the proper way to handle HOSTDISCONDETECT for all i.mx SoCs, including mx23, and would like to get some feedback from the FSL guys in Cc. Thanks, Fabio Estevam -- 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: mxs-phy on i.MX233 not enumerating
On 8/13/12, Felipe Balbi ba...@ti.com wrote: Will there be another version for this or is this final ? Won't this cause any regressions to other boards ? The proposed patch is not meant to be a final one. We still need to figure out the proper way to handle HOSTDISCONDETECT for all i.mx SoCs, including mx23, and would like to get some feedback from the FSL guys in Cc. According to IC guys, the logic of handling HOSTDISCONDETECT is the same between i.mx28 and i.mx23. Thanks, Fabio Estevam
Re: mxs-phy on i.MX233 not enumerating
Dear Chen Peter-B29397, On 8/13/12, Felipe Balbi ba...@ti.com wrote: Will there be another version for this or is this final ? Won't this cause any regressions to other boards ? The proposed patch is not meant to be a final one. We still need to figure out the proper way to handle HOSTDISCONDETECT for all i.mx SoCs, including mx23, and would like to get some feedback from the FSL guys in Cc. According to IC guys, the logic of handling HOSTDISCONDETECT is the same between i.mx28 and i.mx23. I recall we had issues with the discon detector on MX28, but on mx28 the chip was completely deaf (no messages in kernel log). Best regards, Marek Vasut -- 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: mxs-phy on i.MX233 not enumerating
Peter, On 8/13/12, Chen Peter-B29397 b29...@freescale.com wrote: According to IC guys, the logic of handling HOSTDISCONDETECT is the same between i.mx28 and i.mx23. As pointed out by Sean, on mx23 reference manual we have the following text describing HOSTDISCONDETECT: Due to a on chip issue (Errata #2791), software must pay attention to when to assert the HOSTDISCONDETECT bit description has the following: 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. and the same is not present on mx28 reference manual. How can we make sure we are not violating the point 2 above? Thanks, Fabio Estevam -- 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: mxs-phy on i.MX233 not enumerating
Add IC guy
Best regards,
Peter Chen
-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com]
Sent: Tuesday, August 14, 2012 10:01 AM
To: Chen Peter-B29397
Cc: ba...@ti.com; Sean Cross; linux-usb@vger.kernel.org; Estevam Fabio-
R49496; Zhao Richard-B20223; Shawn Guo; Marek Vasut; Li Frank-B20596
Subject: Re: mxs-phy on i.MX233 not enumerating
Peter,
On 8/13/12, Chen Peter-B29397 b29...@freescale.com wrote:
According to IC guys, the logic of handling HOSTDISCONDETECT is the
same
between i.mx28 and i.mx23.
As pointed out by Sean, on mx23 reference manual we have the following
text describing HOSTDISCONDETECT:
Due to a on chip issue (Errata #2791), software must
pay attention to when to assert the HOSTDISCONDETECT bit description
has the following:
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.
and the same is not present on mx28 reference manual.
How can we make sure we are not violating the point 2 above?
Thanks,
Fabio Estevam
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
RE: mxs-phy on i.MX233 not enumerating
According to IC guys, the logic of handling HOSTDISCONDETECT is the
same
between i.mx28 and i.mx23.
As pointed out by Sean, on mx23 reference manual we have the following
text describing HOSTDISCONDETECT:
Due to a on chip issue (Errata #2791), software must
pay attention to when to assert the HOSTDISCONDETECT bit description
has the following:
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.
and the same is not present on mx28 reference manual.
How can we make sure we are not violating the point 2 above?
It is the same with i.mx28. I think Richard's patch should not
violate point 2. Richard, can you confirm it?
Thanks,
Fabio Estevam
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: mxs-phy on i.MX233 not enumerating
On Tue, Aug 14, 2012 at 10:40:21AM +0800, Chen Peter-B29397 wrote: According to IC guys, the logic of handling HOSTDISCONDETECT is the same between i.mx28 and i.mx23. As pointed out by Sean, on mx23 reference manual we have the following text describing HOSTDISCONDETECT: Due to a on chip issue (Errata #2791), software must pay attention to when to assert the HOSTDISCONDETECT bit description has the following: 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. and the same is not present on mx28 reference manual. How can we make sure we are not violating the point 2 above? It is the same with i.mx28. If they're same, imx23 should be ok. The mxs_phy driver pass test on mx28. I think Richard's patch should not violate point 2. Richard, can you confirm it? You mean I should not set the bit in mxs_phy_on_connect? or mxs_phy_on_connect is called in wrong place? Thanks Richard Thanks, Fabio Estevam -- 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: mxs-phy on i.MX233 not enumerating
It is the same with i.mx28. If they're same, imx23 should be ok. The mxs_phy driver pass test on mx28. I think Richard's patch should not violate point 2. Richard, can you confirm it? You mean I should not set the bit in mxs_phy_on_connect? or mxs_phy_on_connect is called in wrong place? HW_USBPHY_CTRL.ENHOSTDISCONDETECT should be set after bus reset is finished. Thanks Richard Thanks, Fabio Estevam -- 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
