Re: [PATCH v2 2/3] usb: chipidea: imx: support disabling runtime-pm

[Francesco Dolcini <francesco@dolcini.it>]

On Sat, May 06, 2023 at 09:02:39AM +0000, Jun Li wrote:
> > -----Original Message-----
> > From: Francesco Dolcini <francesco@dolcini.it>
> > Sent: Friday, May 5, 2023 7:00 PM
> > To: Luca Ceresoli <luca.ceresoli@bootlin.com>; Jun Li <jun.li@nxp.com>
> > Cc: Francesco Dolcini <francesco@dolcini.it>; devicetree@vger.kernel.org;
> > festevam@gmail.com; gregkh@linuxfoundation.org; kernel@pengutronix.de;
> > linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>;
> > linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org;
> > peter.chen@nxp.com; robh+dt@kernel.org; s.hauer@pengutronix.de;
> > shawnguo@kernel.org; Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>;
> > Francesco Dolcini <francesco.dolcini@toradex.com>
> > Subject: Re: [PATCH v2 2/3] usb: chipidea: imx: support disabling runtime-pm
> > 
> > On Fri, May 05, 2023 at 12:06:18PM +0200, Luca Ceresoli wrote:
> > > On Fri, 5 May 2023 09:49:16 +0000
> > > Jun Li <jun.li@nxp.com> wrote:
> > > > Is your board design similar like Francesco's as below?
> > >
> > > Possibly, but I'm afraid I can't say: I am using the Toradex Colibri
> > > i.MX6ULL SoM, whose schematics are not public.
> > 
> > I can confirm that it's the same.
> 
> Thanks Francesco for the confirmation, had a check with design team,
> there is no status bit which can be used to judge the VDD_USB_CAP is
> powered or not, so we have to add a board level dts property to tell
> this usb phy driver to bypass MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS.
> 
> Before send a formal patch, I want to confirm this should work for your
> HW design, like below simple hack:

Thanks Li Jun, I tested it with v6.3.1 kernel and it's all good.
I would be happy to test the patch as soon as you send it.


With that said I had another issue that I assume is unrelated.
In addition to the USB Host port, we have an additional OTG one. This
interface has the same circuit WRT to the VBUS, however in this case
it's possible to read the VBUS using extcon, e.g. a standard GPIO input.

With that setup, while doing a role switch, I had a couple of time this
error:

[  187.310421] ci_hdrc ci_hdrc.0: USB bus 2 deregistered
[  192.351452] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in OTGSC

that was recovered only doing an additional transition.

More complete logs here:

[  184.997619] usb 2-1: USB disconnect, device number 9
[  185.019620] ci_hdrc ci_hdrc.0: remove, state 1
[  185.024271] usb usb2: USB disconnect, device number 1
[  185.334975] ci_hdrc ci_hdrc.0: USB bus 2 deregistered
[  185.353857] ci_hdrc ci_hdrc.0: EHCI Host Controller
[  185.389670] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2
[  185.470170] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[  185.476097] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.01
[  185.484527] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  185.491811] usb usb2: Product: EHCI Host Controller
[  185.496704] usb usb2: Manufacturer: Linux 6.1.22-6.2.0+git.3b29299e5f60 ehci_hcd
[  185.504148] usb usb2: SerialNumber: ci_hdrc.0
[  185.531121] hub 2-0:1.0: USB hub found
[  185.542636] hub 2-0:1.0: 1 port detected
[  185.556586] mxs_phy 20c9000.usbphy: vbus is not valid
[  187.271684] ci_hdrc ci_hdrc.0: remove, state 4
[  187.276281] usb usb2: USB disconnect, device number 1
[  187.310421] ci_hdrc ci_hdrc.0: USB bus 2 deregistered
[  192.351452] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in OTGSC


> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index e1a2b2ea098b..ec5ee790455e 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -178,7 +178,6 @@ 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,
>  };
>  
>  static const struct mxs_phy_data imx7ulp_phy_data = {

Francesco