| Message ID | Y1vLpaxpc5WBCuGD@francesco-nb.int.toradex.com |
|---|---|
| State | New |
| Headers | show |
| Series | USB runtime PM issues on i.MX6ULL | expand |
Hi Francesco, > -----Original Message----- > From: Francesco Dolcini <francesco@dolcini.it> > Sent: Friday, October 28, 2022 8:32 PM > To: Peter Chen <peter.chen@kernel.org>; linux-usb@vger.kernel.org; Jun Li > <jun.li@nxp.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Shawn Guo > <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix > Kernel Team <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > dl-linux-imx <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com> > Subject: USB runtime PM issues on i.MX6ULL > > Hello all, > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > ("fsl,imx6ul-usbphy"). > > The HW design has 2 USB interface, the first one is dual-role, while the > second > one is a host port with NO way to re-read the VBUS (USB_OTG2_VBUS is not > really connected, there is just a capacitor to GND). How is your USB_OTG1_VBUS status? Can you try to make your USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host only port test with runtime PM enabled? Li Jun > > Focusing on the second interface, USB Host only, what I do experience is > the > following: > > - if there is no USB HUB connected and no device connected at boot, any > USB > device hotplugged is not working, ci_runtime_suspend is called and it > never > resume. > - if there is a HUB in between it somehow works, however I have a continuos > runtime powermanagement reset loop every 2 seconds > [ 1026.146360] ci_hdrc ci_hdrc.1: at ci_runtime_suspend > [ 1026.164725] ci_hdrc ci_hdrc.1: at ci_controller_resume > [ 1026.487844] usb 1-1: reset high-speed USB device number 2 using > ci_hdrc > [ 1028.326789] ci_hdrc ci_hdrc.1: at ci_runtime_suspend > [ 1028.335378] ci_hdrc ci_hdrc.1: at ci_controller_resume > [ 1028.657853] usb 1-1: reset high-speed USB device number 2 using > ci_hdrc > > > I was able to have it fully working disabling the runtime power management > in > the chipidea driver or using sysfs (`echo on > /sys/.../power/control`). > > --- a/drivers/usb/chipidea/ci_hdrc_imx.c > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c > @@ -56,7 +56,7 @@ static const struct ci_hdrc_imx_platform_flag > imx6sx_usb_data = { > }; > > static const struct ci_hdrc_imx_platform_flag imx6ul_usb_data = { > - .flags = CI_HDRC_SUPPORTS_RUNTIME_PM | > + .flags = > > I was digging even more into the topic and I found out that what is happening > is that mxs_phy_disconnect_line() is called. I than tried to remove the > MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS flag. > > --- a/drivers/usb/phy/phy-mxs-usb.c > +++ b/drivers/usb/phy/phy-mxs-usb.c > @@ -178,7 +178,7 @@ static const struct mxs_phy_data imx6sx_phy_data = { > }; > > static const struct mxs_phy_data imx6ul_phy_data = { > - .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS, > + /*.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,*/ > }; > > This commit from NXP downstream kernel seems somehow related > https://github.com/nxp-imx/linux-imx/commit/89ec73836a9b1347743e406d62d > d446dc4365db3 > however it builds on other commits that allow to communicate the actual mode > to > the USB PHY driver and prevent mxs_phy_disconnect_line() to be called for > the > USB host case. > > With that the situation is way better, but while without > `CI_HDRC_SUPPORTS_RUNTIME_PM` it works perfectly, without > `MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS` it does not really work smootly > in case there is a hub in between (~20% of the time the device is not > enumerated after plugging it in). > > When it does not work I see that after plugging in a device runtime resume > function is called, but after that the device is not enumerated on the USB > bus. > It looks like something else is missing. > > It seems like having a pure USB Host interface without having a way to re-read > the VBUS is not really supported in SW at the moment, am I wrong? > Any idea? > > One last comment, even the USB dual role port is not working smoothly, however > I have not investigated this specific case that much because disabling runtime > pm > solves everything also in that case. > > Francesco
Hello Li Jun, On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > -----Original Message----- > > From: Francesco Dolcini <francesco@dolcini.it> > > Sent: Friday, October 28, 2022 8:32 PM > > To: Peter Chen <peter.chen@kernel.org>; linux-usb@vger.kernel.org; Jun Li > > <jun.li@nxp.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Shawn Guo > > <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix > > Kernel Team <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > dl-linux-imx <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > > philippe.schenker@toradex.com; Francesco Dolcini > > <francesco.dolcini@toradex.com> > > Subject: USB runtime PM issues on i.MX6ULL > > > > Hello all, > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > ("fsl,imx6ul-usbphy"). > > > > The HW design has 2 USB interface, the first one is dual-role, while the > > second > > one is a host port with NO way to re-read the VBUS (USB_OTG2_VBUS is not > > really connected, there is just a capacitor to GND). > > How is your USB_OTG1_VBUS status? Can you try to make your USB_OTG1_VBUS pad > has a valid VBUS voltage, then run your Host only port test with runtime PM > enabled? USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not really straightforward to do such a test. Francesco
> -----Original Message----- > From: Francesco Dolcini <francesco@dolcini.it> > Sent: Monday, October 31, 2022 9:54 PM > To: Jun Li (OSS) <jun.li@oss.nxp.com> > Cc: Francesco Dolcini <francesco@dolcini.it>; Peter Chen > <peter.chen@kernel.org>; linux-usb@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com> > Subject: Re: USB runtime PM issues on i.MX6ULL > > Hello Li Jun, > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > -----Original Message----- > > > From: Francesco Dolcini <francesco@dolcini.it> > > > Sent: Friday, October 28, 2022 8:32 PM > > > To: Peter Chen <peter.chen@kernel.org>; linux-usb@vger.kernel.org; > > > Jun Li <jun.li@nxp.com> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Shawn Guo > > > <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>; > > > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam > > > <festevam@gmail.com>; dl-linux-imx <linux-imx@nxp.com>; Felipe Balbi > > > <balbi@kernel.org>; philippe.schenker@toradex.com; Francesco Dolcini > > > <francesco.dolcini@toradex.com> > > > Subject: USB runtime PM issues on i.MX6ULL > > > > > > Hello all, > > > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > > ("fsl,imx6ul-usbphy"). > > > > > > The HW design has 2 USB interface, the first one is dual-role, while > > > the second one is a host port with NO way to re-read the VBUS > > > (USB_OTG2_VBUS is not really connected, there is just a capacitor to > > > GND). > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host only > > port test with runtime PM enabled? > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not really > straightforward to do such a test. iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) as input to power the internal USB LDO if I understand correctly, so you need change your HW to meet this: for Host only port, you have to connect USB_OTG2_VBUS to a valid VBUS and make it always present for simple. You can do some quick HW change to prove this. Li Jun > > Francesco
Hello Jun Li, On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > > > ("fsl,imx6ul-usbphy"). > > > > > > > > The HW design has 2 USB interface, the first one is dual-role, while > > > > the second one is a host port with NO way to re-read the VBUS > > > > (USB_OTG2_VBUS is not really connected, there is just a capacitor to > > > > GND). > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host only > > > port test with runtime PM enabled? > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not really > > straightforward to do such a test. > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) as input to > power the internal USB LDO if I understand correctly. This surprise me a little bit, since - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected if unused - downstream NXP kernel seems to work fine ("seems" since we do have some patches there, so I could be wrong) - disabling runtime pm on upstream Linux kernel make it works perfectly, so there is a way in SW to have this HW configuration working. > your HW to meet this: for Host only port, you have to connect USB_OTG2_VBUS > to a valid VBUS and make it always present for simple. > You can do some quick HW change to prove this. We have no way to change the HW in reality, therefore doing a one off test would be pretty much irrelevant. Said all of that, given what you wrote, I feel like having a specific dts property in the chipidea driver to disable runtime pm might be the way to go. Something like `ci,disable-runtime-pm`? I know the DTS is supposed to describe the HW, so maybe a different property name would be required. What do you think about this? Francesco
> -----Original Message----- > From: Francesco Dolcini <francesco@dolcini.it> > Sent: Wednesday, November 2, 2022 3:51 AM > To: Jun Li <jun.li@nxp.com> > Cc: Francesco Dolcini <francesco@dolcini.it>; Jun Li (OSS) > <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > linux-usb@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com> > Subject: Re: USB runtime PM issues on i.MX6ULL > > Hello Jun Li, > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > > > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > > > > ("fsl,imx6ul-usbphy"). > > > > > > > > > > The HW design has 2 USB interface, the first one is dual-role, > > > > > while the second one is a host port with NO way to re-read the > > > > > VBUS (USB_OTG2_VBUS is not really connected, there is just a > > > > > capacitor to GND). > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host > > > > only port test with runtime PM enabled? > > > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not > > > really straightforward to do such a test. > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) as > > input to power the internal USB LDO if I understand correctly. > This surprise me a little bit, since > - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected if > unused I think "unused" here means you do not need/enable the port at all. > - downstream NXP kernel seems to work fine ("seems" since we do have > some patches there, so I could be wrong) What do you mean by " downstream NXP kernel seems to work fine"? The downstream kernel can work on your HW? But upstream kernel driver does not? > - disabling runtime pm on upstream Linux kernel make it works > perfectly, so there is a way in SW to have this HW configuration > working. Again I want to make sure the both VBUS pads(OTG1 and OTG2) voltage are always at 0v on your HW, can you double check and confirm? I ask this again because such situation should cause the USB port Cannot work at any cases, but your current status is: only low power wakeup cannot work. > > > your HW to meet this: for Host only port, you have to connect > > USB_OTG2_VBUS to a valid VBUS and make it always present for simple. > > You can do some quick HW change to prove this. > We have no way to change the HW in reality, therefore doing a one off test > would be pretty much irrelevant. My intention of doing this HW rework is just for debug. > > Said all of that, given what you wrote, I feel like having a specific dts > property in the chipidea driver to disable runtime pm might be the way to > go. > > Something like `ci,disable-runtime-pm`? I know the DTS is supposed to > describe the HW, so maybe a different property name would be required. > > What do you think about this? This is the last step to consider, we cannot go this way before root cause identified. Thanks Li Jun > > Francesco
> -----Original Message----- > From: Jun Li <jun.li@nxp.com> > Sent: Wednesday, November 2, 2022 5:45 PM > To: Francesco Dolcini <francesco@dolcini.it> > Cc: Jun Li (OSS) <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > linux-usb@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com> > Subject: RE: USB runtime PM issues on i.MX6ULL > > > > > -----Original Message----- > > From: Francesco Dolcini <francesco@dolcini.it> > > Sent: Wednesday, November 2, 2022 3:51 AM > > To: Jun Li <jun.li@nxp.com> > > Cc: Francesco Dolcini <francesco@dolcini.it>; Jun Li (OSS) > > <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > > linux-usb@vger.kernel.org; Greg Kroah-Hartman > > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > dl-linux-imx > > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > > philippe.schenker@toradex.com; Francesco Dolcini > > <francesco.dolcini@toradex.com> > > Subject: Re: USB runtime PM issues on i.MX6ULL > > > > Hello Jun Li, > > > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > > > > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > > > > > ("fsl,imx6ul-usbphy"). > > > > > > > > > > > > The HW design has 2 USB interface, the first one is dual-role, > > > > > > while the second one is a host port with NO way to re-read the > > > > > > VBUS (USB_OTG2_VBUS is not really connected, there is just a > > > > > > capacitor to GND). > > > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host > > > > > only port test with runtime PM enabled? > > > > > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not > > > > really straightforward to do such a test. > > > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) as > > > input to power the internal USB LDO if I understand correctly. > > This surprise me a little bit, since > > - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected if > > unused > > I think "unused" here means you do not need/enable the port at all. > > > - downstream NXP kernel seems to work fine ("seems" since we do have > > some patches there, so I could be wrong) > > What do you mean by " downstream NXP kernel seems to work fine"? > The downstream kernel can work on your HW? But upstream kernel > driver does not? > > > - disabling runtime pm on upstream Linux kernel make it works > > perfectly, so there is a way in SW to have this HW configuration > > working. > > Again I want to make sure the both VBUS pads(OTG1 and OTG2) voltage > are always at 0v on your HW, can you double check and confirm? > I ask this again because such situation should cause the USB port > Cannot work at any cases, but your current status is: only low > power wakeup cannot work. Could you please check the voltage of pad of VDD_USB_CAP on your HW? Li Jun
On Wed, Nov 02, 2022 at 10:12:42AM +0000, Jun Li wrote: > > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > > > > > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > > > > > > ("fsl,imx6ul-usbphy"). > > > > > > > > > > > > > > The HW design has 2 USB interface, the first one is dual-role, > > > > > > > while the second one is a host port with NO way to re-read the > > > > > > > VBUS (USB_OTG2_VBUS is not really connected, there is just a > > > > > > > capacitor to GND). > > > > > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host > > > > > > only port test with runtime PM enabled? > > > > > > > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not > > > > > really straightforward to do such a test. > > > > > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) as > > > > input to power the internal USB LDO if I understand correctly. > > > This surprise me a little bit, since > > > - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected if > > > unused > > > > I think "unused" here means you do not need/enable the port at all. > > > > > - downstream NXP kernel seems to work fine ("seems" since we do have > > > some patches there, so I could be wrong) > > > > What do you mean by " downstream NXP kernel seems to work fine"? > > The downstream kernel can work on your HW? But upstream kernel > > driver does not? Correct, NXP downstream kernel is working fine, upstream kernel requires runtime PM disabled to work correctly. > > > - disabling runtime pm on upstream Linux kernel make it works > > > perfectly, so there is a way in SW to have this HW configuration > > > working. > > > > Again I want to make sure the both VBUS pads(OTG1 and OTG2) voltage > > are always at 0v on your HW, can you double check and confirm? > > I ask this again because such situation should cause the USB port > > Cannot work at any cases, but your current status is: only low > > power wakeup cannot work. > > Could you please check the voltage of pad of VDD_USB_CAP on your HW? I was about to clarify you this point, it's important and I forgot about it, sorry about that! VDD_USB_CAP in our design is connected to a 3.0V external LDO, voltage on both VBUS pads is 0V (FYI: this specific hardware design was validated by NXP hardware engineers). Francesco
> -----Original Message----- > From: Francesco Dolcini <francesco@dolcini.it> > Sent: Thursday, November 3, 2022 1:59 AM > To: Jun Li <jun.li@nxp.com> > Cc: Francesco Dolcini <francesco@dolcini.it>; Jun Li (OSS) > <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > linux-usb@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com> > Subject: Re: USB runtime PM issues on i.MX6ULL > > On Wed, Nov 02, 2022 at 10:12:42AM +0000, Jun Li wrote: > > > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > > > > I am debugging some unexpected USB behavior on a i.MX6ULL SOC, > > > > > > > > chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy > > > > > > > > ("fsl,imx6ul-usbphy"). > > > > > > > > > > > > > > > > The HW design has 2 USB interface, the first one is dual-role, > > > > > > > > while the second one is a host port with NO way to re-read > the > > > > > > > > VBUS (USB_OTG2_VBUS is not really connected, there is just > a > > > > > > > > capacitor to GND). > > > > > > > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > > > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your Host > > > > > > > only port test with runtime PM enabled? > > > > > > > > > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, not > > > > > > really straightforward to do such a test. > > > > > > > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) as > > > > > input to power the internal USB LDO if I understand correctly. > > > > This surprise me a little bit, since > > > > - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected if > > > > unused > > > > > > I think "unused" here means you do not need/enable the port at all. > > > > > > > - downstream NXP kernel seems to work fine ("seems" since we do have > > > > some patches there, so I could be wrong) > > > > > > What do you mean by " downstream NXP kernel seems to work fine"? > > > The downstream kernel can work on your HW? But upstream kernel > > > driver does not? > > Correct, NXP downstream kernel is working fine, upstream kernel requires > runtime PM disabled to work correctly. > > > > > - disabling runtime pm on upstream Linux kernel make it works > > > > perfectly, so there is a way in SW to have this HW configuration > > > > working. > > > > > > Again I want to make sure the both VBUS pads(OTG1 and OTG2) voltage > > > are always at 0v on your HW, can you double check and confirm? > > > I ask this again because such situation should cause the USB port > > > Cannot work at any cases, but your current status is: only low > > > power wakeup cannot work. > > > > Could you please check the voltage of pad of VDD_USB_CAP on your HW? > > I was about to clarify you this point, it's important and I forgot about > it, sorry about that! > > VDD_USB_CAP in our design is connected to a 3.0V external LDO, voltage > on both VBUS pads is 0V (FYI: this specific hardware design was validated > by NXP hardware engineers). Then the HW design should be fine. I need find time to try the upstream kernel on my iMX6ULL board to check this. Li Jun > > Francesco
Hi Francesco, > -----Original Message----- > From: Jun Li > Sent: Thursday, November 3, 2022 7:53 PM > To: Francesco Dolcini <francesco@dolcini.it> > Cc: Jun Li (OSS) <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > linux-usb@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com> > Subject: RE: USB runtime PM issues on i.MX6ULL > > > > > -----Original Message----- > > From: Francesco Dolcini <francesco@dolcini.it> > > Sent: Thursday, November 3, 2022 1:59 AM > > To: Jun Li <jun.li@nxp.com> > > Cc: Francesco Dolcini <francesco@dolcini.it>; Jun Li (OSS) > > <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > > linux-usb@vger.kernel.org; Greg Kroah-Hartman > > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > dl-linux-imx <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > > philippe.schenker@toradex.com; Francesco Dolcini > > <francesco.dolcini@toradex.com> > > Subject: Re: USB runtime PM issues on i.MX6ULL > > > > On Wed, Nov 02, 2022 at 10:12:42AM +0000, Jun Li wrote: > > > > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > > > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > > > > > I am debugging some unexpected USB behavior on a > > > > > > > > > i.MX6ULL SOC, chipidea controller ("fsl,imx6ul-usb") and > > > > > > > > > a fsl mxs usbphy ("fsl,imx6ul-usbphy"). > > > > > > > > > > > > > > > > > > The HW design has 2 USB interface, the first one is > > > > > > > > > dual-role, while the second one is a host port with NO > > > > > > > > > way to re-read > > the > > > > > > > > > VBUS (USB_OTG2_VBUS is not really connected, there is > > > > > > > > > just > > a > > > > > > > > > capacitor to GND). > > > > > > > > > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > > > > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your > > > > > > > > Host only port test with runtime PM enabled? > > > > > > > > > > > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, > > > > > > > not really straightforward to do such a test. > > > > > > > > > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) > > > > > > as input to power the internal USB LDO if I understand correctly. > > > > > This surprise me a little bit, since > > > > > - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected > if > > > > > unused > > > > > > > > I think "unused" here means you do not need/enable the port at all. > > > > > > > > > - downstream NXP kernel seems to work fine ("seems" since we do > have > > > > > some patches there, so I could be wrong) > > > > > > > > What do you mean by " downstream NXP kernel seems to work fine"? > > > > The downstream kernel can work on your HW? But upstream kernel > > > > driver does not? > > > > Correct, NXP downstream kernel is working fine, upstream kernel > > requires runtime PM disabled to work correctly. > > > > > > > - disabling runtime pm on upstream Linux kernel make it works > > > > > perfectly, so there is a way in SW to have this HW configuration > > > > > working. > > > > > > > > Again I want to make sure the both VBUS pads(OTG1 and OTG2) > > > > voltage are always at 0v on your HW, can you double check and confirm? > > > > I ask this again because such situation should cause the USB port > > > > Cannot work at any cases, but your current status is: only low > > > > power wakeup cannot work. > > > > > > Could you please check the voltage of pad of VDD_USB_CAP on your HW? > > > > I was about to clarify you this point, it's important and I forgot > > about it, sorry about that! > > > > VDD_USB_CAP in our design is connected to a 3.0V external LDO, voltage > > on both VBUS pads is 0V (FYI: this specific hardware design was > > validated by NXP hardware engineers). > > Then the HW design should be fine. > I need find time to try the upstream kernel on my iMX6ULL board to check > this. My iMX6ULL EVK board cannot reproduce this issue with upstream kernel. Could you try to set the bits [7,3] of 0x020c8200(for 2nd USB controller OTG2) to be value like 0x1000FC? This may be done at your bootloader(uboot), so make sure those targets bits are set before doing your test, or doing this with below change(not compiled or tested): diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c index d2836ef5d15c..e390ef534a7c 100644 --- a/drivers/usb/phy/phy-mxs-usb.c +++ b/drivers/usb/phy/phy-mxs-usb.c @@ -89,6 +89,9 @@ #define ANADIG_USB1_CHRG_DET_STAT_CHRG_DETECTED BIT(1) #define ANADIG_USB1_CHRG_DET_STAT_PLUG_CONTACT BIT(0) +#define ANADIG_USB2_VBUS_DET_SET 0x204 +#define ANADIG_USB2_VBUS_DET_VBUS_OVERRIDE GENMASK(7, 3) + #define ANADIG_USB2_VBUS_DET_STAT 0x220 #define ANADIG_USB1_LOOPBACK_SET 0x1e4 @@ -288,6 +291,11 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) if (ret) goto disable_pll; + if (mxs_phy->regmap_anatop && (mxs_phy->port_id == 1)) + regmap_write(mxs_phy->regmap_anatop, + ANADIG_USB2_VBUS_DET_SET, + ANADIG_USB2_VBUS_DET_VBUS_OVERRIDE); + /* Power up the PHY */ writel(0, base + HW_USBPHY_PWD); > > Li Jun > > > > Francesco
On Mon, Dec 26, 2022 at 03:17:12AM +0000, Jun Li wrote: > > From: Jun Li > > Sent: Thursday, November 3, 2022 7:53 PM > > > From: Francesco Dolcini <francesco@dolcini.it> > > > Sent: Thursday, November 3, 2022 1:59 AM > > > On Wed, Nov 02, 2022 at 10:12:42AM +0000, Jun Li wrote: > > > > > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > > > > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > > > > > > I am debugging some unexpected USB behavior on a > > > > > > > > > > i.MX6ULL SOC, chipidea controller ("fsl,imx6ul-usb") and > > > > > > > > > > a fsl mxs usbphy ("fsl,imx6ul-usbphy"). > > > > > > > > > > > > > > > > > > > > The HW design has 2 USB interface, the first one is > > > > > > > > > > dual-role, while the second one is a host port with NO > > > > > > > > > > way to re-read > > > the > > > > > > > > > > VBUS (USB_OTG2_VBUS is not really connected, there is > > > > > > > > > > just > > > a > > > > > > > > > > capacitor to GND). > > > > > > > > > > > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make your > > > > > > > > > USB_OTG1_VBUS pad has a valid VBUS voltage, then run your > > > > > > > > > Host only port test with runtime PM enabled? > > > > > > > > > > > > > > > > USB_OTG1_VBUS is tied to GND the same way as USB_OTG2_VBUS, > > > > > > > > not really straightforward to do such a test. > > > > > > > > > > > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or OTG2) > > > > > > > as input to power the internal USB LDO if I understand correctly. > > > > > > This surprise me a little bit, since > > > > > > - the i.MX6ULL datasheet prescribe to keep the VBUS disconnected > > if > > > > > > unused > > > > > > > > > > I think "unused" here means you do not need/enable the port at all. > > > > > > > > > > > - downstream NXP kernel seems to work fine ("seems" since we do > > have > > > > > > some patches there, so I could be wrong) > > > > > > > > > > What do you mean by " downstream NXP kernel seems to work fine"? > > > > > The downstream kernel can work on your HW? But upstream kernel > > > > > driver does not? > > > > > > Correct, NXP downstream kernel is working fine, upstream kernel > > > requires runtime PM disabled to work correctly. > > > > > > > > > - disabling runtime pm on upstream Linux kernel make it works > > > > > > perfectly, so there is a way in SW to have this HW configuration > > > > > > working. > > > > > > > > > > Again I want to make sure the both VBUS pads(OTG1 and OTG2) > > > > > voltage are always at 0v on your HW, can you double check and confirm? > > > > > I ask this again because such situation should cause the USB port > > > > > Cannot work at any cases, but your current status is: only low > > > > > power wakeup cannot work. > > > > > > > > Could you please check the voltage of pad of VDD_USB_CAP on your HW? > > > > > > I was about to clarify you this point, it's important and I forgot > > > about it, sorry about that! > > > > > > VDD_USB_CAP in our design is connected to a 3.0V external LDO, voltage > > > on both VBUS pads is 0V (FYI: this specific hardware design was > > > validated by NXP hardware engineers). > > > > Then the HW design should be fine. > > I need find time to try the upstream kernel on my iMX6ULL board to check > > this. > > My iMX6ULL EVK board cannot reproduce this issue with upstream kernel. > > Could you try to set the bits [7,3] of 0x020c8200(for 2nd USB controller OTG2) > to be value like 0x1000FC? This may be done at your bootloader(uboot), so > make sure those targets bits are set before doing your test, or doing this > with below change(not compiled or tested): > > diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c > index d2836ef5d15c..e390ef534a7c 100644 > --- a/drivers/usb/phy/phy-mxs-usb.c > +++ b/drivers/usb/phy/phy-mxs-usb.c > @@ -89,6 +89,9 @@ > #define ANADIG_USB1_CHRG_DET_STAT_CHRG_DETECTED BIT(1) > #define ANADIG_USB1_CHRG_DET_STAT_PLUG_CONTACT BIT(0) > > +#define ANADIG_USB2_VBUS_DET_SET 0x204 > +#define ANADIG_USB2_VBUS_DET_VBUS_OVERRIDE GENMASK(7, 3) > + > #define ANADIG_USB2_VBUS_DET_STAT 0x220 > > #define ANADIG_USB1_LOOPBACK_SET 0x1e4 > @@ -288,6 +291,11 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) > if (ret) > goto disable_pll; > > + if (mxs_phy->regmap_anatop && (mxs_phy->port_id == 1)) > + regmap_write(mxs_phy->regmap_anatop, > + ANADIG_USB2_VBUS_DET_SET, > + ANADIG_USB2_VBUS_DET_VBUS_OVERRIDE); > + > /* Power up the PHY */ > writel(0, base + HW_USBPHY_PWD); Hello, I tested your patch and it does not work. I therefore tested a slightly improved version that really ensure the right register value is written. [ 8.408564] port=0 reg=0x200 val=0x1000fc [ 8.440235] port=1 reg=0x204 val=0x1000fc but it does not work never the less. Unfortunately bits 7-3 are not documented, so I was not able to do much more. diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c index d2836ef5d15c..3ff5489d679e 100644 --- a/drivers/usb/phy/phy-mxs-usb.c +++ b/drivers/usb/phy/phy-mxs-usb.c @@ -89,6 +89,10 @@ #define ANADIG_USB1_CHRG_DET_STAT_CHRG_DETECTED BIT(1) #define ANADIG_USB1_CHRG_DET_STAT_PLUG_CONTACT BIT(0) +#define ANADIG_USB1_VBUS_DET_SET 0x200 +#define ANADIG_USB2_VBUS_DET_SET 0x204 +#define ANADIG_USB1_VBUS_DET_VBUS_OVERRIDE GENMASK(7, 3) + #define ANADIG_USB2_VBUS_DET_STAT 0x220 #define ANADIG_USB1_LOOPBACK_SET 0x1e4 @@ -309,6 +313,7 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) writel(BM_USBPHY_IP_FIX, base + HW_USBPHY_IP_SET); if (mxs_phy->regmap_anatop) { + unsigned int val; unsigned int reg = mxs_phy->port_id ? ANADIG_USB1_CHRG_DETECT_SET : ANADIG_USB2_CHRG_DETECT_SET; @@ -319,6 +324,15 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) regmap_write(mxs_phy->regmap_anatop, reg, ANADIG_USB1_CHRG_DETECT_EN_B | ANADIG_USB1_CHRG_DETECT_CHK_CHRG_B); + + reg = mxs_phy->port_id ? + ANADIG_USB2_VBUS_DET_SET : + ANADIG_USB1_VBUS_DET_SET; + + regmap_set_bits(mxs_phy->regmap_anatop, reg, + ANADIG_USB1_VBUS_DET_VBUS_OVERRIDE); + regmap_read(mxs_phy->regmap_anatop, reg, &val); + printk("port=%d reg=0x%x val=0x%x\n", mxs_phy->port_id, reg, val); } mxs_phy_tx_init(mxs_phy);
> -----Original Message----- > From: Francesco Dolcini <francesco@dolcini.it> > Sent: Monday, December 26, 2022 11:45 PM > To: Jun Li <jun.li@nxp.com> > Cc: Francesco Dolcini <francesco@dolcini.it>; Jun Li (OSS) > <jun.li@oss.nxp.com>; Peter Chen <peter.chen@kernel.org>; > linux-usb@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; dl-linux-imx > <linux-imx@nxp.com>; Felipe Balbi <balbi@kernel.org>; > philippe.schenker@toradex.com; Francesco Dolcini > <francesco.dolcini@toradex.com>; Xu Yang <xu.yang_2@nxp.com> > Subject: Re: USB runtime PM issues on i.MX6ULL > > On Mon, Dec 26, 2022 at 03:17:12AM +0000, Jun Li wrote: > > > From: Jun Li > > > Sent: Thursday, November 3, 2022 7:53 PM > > > > From: Francesco Dolcini <francesco@dolcini.it> > > > > Sent: Thursday, November 3, 2022 1:59 AM On Wed, Nov 02, 2022 at > > > > 10:12:42AM +0000, Jun Li wrote: > > > > > > > On Tue, Nov 01, 2022 at 03:10:46AM +0000, Jun Li wrote: > > > > > > > > > On Mon, Oct 31, 2022 at 01:40:39PM +0000, Jun Li (OSS) wrote: > > > > > > > > > > > I am debugging some unexpected USB behavior on a > > > > > > > > > > > i.MX6ULL SOC, chipidea controller ("fsl,imx6ul-usb") > > > > > > > > > > > and a fsl mxs usbphy ("fsl,imx6ul-usbphy"). > > > > > > > > > > > > > > > > > > > > > > The HW design has 2 USB interface, the first one is > > > > > > > > > > > dual-role, while the second one is a host port with > > > > > > > > > > > NO way to re-read > > > > the > > > > > > > > > > > VBUS (USB_OTG2_VBUS is not really connected, there > > > > > > > > > > > is just > > > > a > > > > > > > > > > > capacitor to GND). > > > > > > > > > > > > > > > > > > > > How is your USB_OTG1_VBUS status? Can you try to make > > > > > > > > > > your USB_OTG1_VBUS pad has a valid VBUS voltage, then > > > > > > > > > > run your Host only port test with runtime PM enabled? > > > > > > > > > > > > > > > > > > USB_OTG1_VBUS is tied to GND the same way as > > > > > > > > > USB_OTG2_VBUS, not really straightforward to do such a test. > > > > > > > > > > > > > > > > iMX6ULL need at least one valid VBUS(either from OTG1 or > > > > > > > > OTG2) as input to power the internal USB LDO if I understand > correctly. > > > > > > > This surprise me a little bit, since > > > > > > > - the i.MX6ULL datasheet prescribe to keep the VBUS > > > > > > > disconnected > > > if > > > > > > > unused > > > > > > > > > > > > I think "unused" here means you do not need/enable the port at > all. > > > > > > > > > > > > > - downstream NXP kernel seems to work fine ("seems" since > > > > > > > we do > > > have > > > > > > > some patches there, so I could be wrong) > > > > > > > > > > > > What do you mean by " downstream NXP kernel seems to work fine"? > > > > > > The downstream kernel can work on your HW? But upstream kernel > > > > > > driver does not? > > > > > > > > Correct, NXP downstream kernel is working fine, upstream kernel > > > > requires runtime PM disabled to work correctly. > > > > > > > > > > > - disabling runtime pm on upstream Linux kernel make it works > > > > > > > perfectly, so there is a way in SW to have this HW configuration > > > > > > > working. > > > > > > > > > > > > Again I want to make sure the both VBUS pads(OTG1 and OTG2) > > > > > > voltage are always at 0v on your HW, can you double check and confirm? > > > > > > I ask this again because such situation should cause the USB > > > > > > port Cannot work at any cases, but your current status is: > > > > > > only low power wakeup cannot work. > > > > > > > > > > Could you please check the voltage of pad of VDD_USB_CAP on your > HW? > > > > > > > > I was about to clarify you this point, it's important and I forgot > > > > about it, sorry about that! > > > > > > > > VDD_USB_CAP in our design is connected to a 3.0V external LDO, > > > > voltage on both VBUS pads is 0V (FYI: this specific hardware > > > > design was validated by NXP hardware engineers). > > > > > > Then the HW design should be fine. > > > I need find time to try the upstream kernel on my iMX6ULL board to > > > check this. > > > > My iMX6ULL EVK board cannot reproduce this issue with upstream kernel. > > > > Could you try to set the bits [7,3] of 0x020c8200(for 2nd USB > > controller OTG2) to be value like 0x1000FC? This may be done at your > > bootloader(uboot), so make sure those targets bits are set before > > doing your test, or doing this with below change(not compiled or tested): > > > > diff --git a/drivers/usb/phy/phy-mxs-usb.c > > b/drivers/usb/phy/phy-mxs-usb.c index d2836ef5d15c..e390ef534a7c > > 100644 > > --- a/drivers/usb/phy/phy-mxs-usb.c > > +++ b/drivers/usb/phy/phy-mxs-usb.c > > @@ -89,6 +89,9 @@ > > #define ANADIG_USB1_CHRG_DET_STAT_CHRG_DETECTED BIT(1) > > #define ANADIG_USB1_CHRG_DET_STAT_PLUG_CONTACT BIT(0) > > > > +#define ANADIG_USB2_VBUS_DET_SET 0x204 > > +#define ANADIG_USB2_VBUS_DET_VBUS_OVERRIDE GENMASK(7, 3) > > + > > #define ANADIG_USB2_VBUS_DET_STAT 0x220 > > > > #define ANADIG_USB1_LOOPBACK_SET 0x1e4 > > @@ -288,6 +291,11 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) > > if (ret) > > goto disable_pll; > > > > + if (mxs_phy->regmap_anatop && (mxs_phy->port_id == 1)) > > + regmap_write(mxs_phy->regmap_anatop, > > + ANADIG_USB2_VBUS_DET_SET, > > + ANADIG_USB2_VBUS_DET_VBUS_OVERRIDE); > > + > > /* Power up the PHY */ > > writel(0, base + HW_USBPHY_PWD); > > Hello, > I tested your patch and it does not work. I therefore tested a slightly > improved version that really ensure the right register value is written. > > [ 8.408564] port=0 reg=0x200 val=0x1000fc > [ 8.440235] port=1 reg=0x204 val=0x1000fc > > but it does not work never the less. Unfortunately bits 7-3 are not documented, > so I was not able to do much more. > > > diff --git a/drivers/usb/phy/phy-mxs-usb.c > b/drivers/usb/phy/phy-mxs-usb.c index d2836ef5d15c..3ff5489d679e 100644 > --- a/drivers/usb/phy/phy-mxs-usb.c > +++ b/drivers/usb/phy/phy-mxs-usb.c > @@ -89,6 +89,10 @@ > #define ANADIG_USB1_CHRG_DET_STAT_CHRG_DETECTED BIT(1) > #define ANADIG_USB1_CHRG_DET_STAT_PLUG_CONTACT BIT(0) > > +#define ANADIG_USB1_VBUS_DET_SET 0x200 > +#define ANADIG_USB2_VBUS_DET_SET 0x204 > +#define ANADIG_USB1_VBUS_DET_VBUS_OVERRIDE GENMASK(7, 3) > + > #define ANADIG_USB2_VBUS_DET_STAT 0x220 > > #define ANADIG_USB1_LOOPBACK_SET 0x1e4 > @@ -309,6 +313,7 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) > writel(BM_USBPHY_IP_FIX, base + HW_USBPHY_IP_SET); > > if (mxs_phy->regmap_anatop) { > + unsigned int val; > unsigned int reg = mxs_phy->port_id ? > ANADIG_USB1_CHRG_DETECT_SET : > ANADIG_USB2_CHRG_DETECT_SET; @@ -319,6 +324,15 @@ > static int mxs_phy_hw_init(struct mxs_phy *mxs_phy) > regmap_write(mxs_phy->regmap_anatop, reg, > ANADIG_USB1_CHRG_DETECT_EN_B | > ANADIG_USB1_CHRG_DETECT_CHK_CHRG_B); > + > + reg = mxs_phy->port_id ? > + ANADIG_USB2_VBUS_DET_SET : > + ANADIG_USB1_VBUS_DET_SET; > + > + regmap_set_bits(mxs_phy->regmap_anatop, reg, > + ANADIG_USB1_VBUS_DET_VBUS_OVERRIDE); > + regmap_read(mxs_phy->regmap_anatop, reg, &val); > + printk("port=%d reg=0x%x val=0x%x\n", mxs_phy->port_id, > + reg, val); > } > > mxs_phy_tx_init(mxs_phy); > Thanks for try those, those bits are for vbus valid override, You can verify if the override real works by checking the OTGSC Registers(a few bits to show the BSV/ASV/AVV) via the debugfs /sys/kernel/debug/usb/ci_hdrc.1/registers. echo on > /sys/bus/platform/devices/ci_hdrc.1/power/control cat /sys/kernel/debug/usb/ci_hdrc.1/registers if the BSV/ASV/AVV are all set to be 1, means it works. Enable runtime PM back: echo auto > /sys/bus/platform/devices/ci_hdrc.1/power/control then do your issue test. if this cannot work for your HW, I need a similar HW to reproduce the issue for further debug. BTW, how is __mxs_phy_disconnect_line() impacting this issue result on your HW? If not called, then the direct plug usb device to the OTG2 port can work, but adding an external hub between still cannot work? Li Jun
On Fri, Oct 28, 2022 at 9:31 AM Francesco Dolcini <francesco@dolcini.it> wrote: > static const struct ci_hdrc_imx_platform_flag imx6ul_usb_data = { > - .flags = CI_HDRC_SUPPORTS_RUNTIME_PM | > + .flags = Not sure if this is related to a problem I was having on imx7d. I was also disabling runtime pm as you showed above to workaround a USB modem detection problem. Li Jun suggested I check for the over-current polarity description of the devicetree. Passing 'disable-over-current' or ''over-current-active-low' made the issue go away.
--- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -56,7 +56,7 @@ static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = { }; static const struct ci_hdrc_imx_platform_flag imx6ul_usb_data = { - .flags = CI_HDRC_SUPPORTS_RUNTIME_PM | + .flags = I was digging even more into the topic and I found out that what is happening is that mxs_phy_disconnect_line() is called. I than tried to remove the MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS flag. --- a/drivers/usb/phy/phy-mxs-usb.c +++ b/drivers/usb/phy/phy-mxs-usb.c @@ -178,7 +178,7 @@ static const struct mxs_phy_data imx6sx_phy_data = { }; static const struct mxs_phy_data imx6ul_phy_data = { - .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS, + /*.flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,*/ }; This commit from NXP downstream kernel seems somehow related
Hello all, I am debugging some unexpected USB behavior on a i.MX6ULL SOC, chipidea controller ("fsl,imx6ul-usb") and a fsl mxs usbphy ("fsl,imx6ul-usbphy"). The HW design has 2 USB interface, the first one is dual-role, while the second one is a host port with NO way to re-read the VBUS (USB_OTG2_VBUS is not really connected, there is just a capacitor to GND). Focusing on the second interface, USB Host only, what I do experience is the following: - if there is no USB HUB connected and no device connected at boot, any USB device hotplugged is not working, ci_runtime_suspend is called and it never resume. - if there is a HUB in between it somehow works, however I have a continuos runtime powermanagement reset loop every 2 seconds [ 1026.146360] ci_hdrc ci_hdrc.1: at ci_runtime_suspend [ 1026.164725] ci_hdrc ci_hdrc.1: at ci_controller_resume [ 1026.487844] usb 1-1: reset high-speed USB device number 2 using ci_hdrc [ 1028.326789] ci_hdrc ci_hdrc.1: at ci_runtime_suspend [ 1028.335378] ci_hdrc ci_hdrc.1: at ci_controller_resume [ 1028.657853] usb 1-1: reset high-speed USB device number 2 using ci_hdrc I was able to have it fully working disabling the runtime power management in the chipidea driver or using sysfs (`echo on > /sys/.../power/control`). https://github.com/nxp-imx/linux-imx/commit/89ec73836a9b1347743e406d62dd446dc4365db3 however it builds on other commits that allow to communicate the actual mode to the USB PHY driver and prevent mxs_phy_disconnect_line() to be called for the USB host case. With that the situation is way better, but while without `CI_HDRC_SUPPORTS_RUNTIME_PM` it works perfectly, without `MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS` it does not really work smootly in case there is a hub in between (~20% of the time the device is not enumerated after plugging it in). When it does not work I see that after plugging in a device runtime resume function is called, but after that the device is not enumerated on the USB bus. It looks like something else is missing. It seems like having a pure USB Host interface without having a way to re-read the VBUS is not really supported in SW at the moment, am I wrong? Any idea? One last comment, even the USB dual role port is not working smoothly, however I have not investigated this specific case that much because disabling runtime pm solves everything also in that case. Francesco