[PATCH] usb: chipidea: Fix ULPI on imx51

[PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
exhibits a kernel frozen on PORTSC access and applying the workaround
resolves the issue.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e431c5aafe35..19f5f5f2a48a 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -291,7 +291,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
 	pdata.usb_phy = data->phy;
 
-	if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
+	if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
+	     of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
 	    of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
 		pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
 		data->override_phy_control = true;
-- 
2.17.0

usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
exhibits a kernel frozen on PORTSC access and applying the workaround
resolves the issue.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e431c5aafe35..19f5f5f2a48a 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -291,7 +291,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
 	pdata.usb_phy = data->phy;
 
-	if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
+	if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
+	     of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
 	    of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
 		pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
 		data->override_phy_control = true;

[PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
exhibits a kernel frozen on PORTSC access and applying the workaround
resolves the issue.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Chris Healy <cphealy@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index e431c5aafe35..19f5f5f2a48a 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -291,7 +291,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
 	pdata.usb_phy = data->phy;
 
-	if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
+	if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
+	     of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
 	    of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
 		pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
 		data->override_phy_control = true;
-- 
2.17.0

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.

Confirmed on 8.9'' RDU1

Tested-By: Nikita Yushchenko <nikita.yoush@cogentembedded.com>

usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.

Confirmed on 8.9'' RDU1

Tested-By: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.

Confirmed on 8.9'' RDU1

Tested-By: Nikita Yushchenko <nikita.yoush@cogentembedded.com>

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>

This patches causes a regression on a imx51-babbage running 4.18-rc1:
I get a kernel hang.

If I revert it on top of 4.18-rc1, then it boots fine and USB host is
functional.

I understand this patch fixes a kernel hang for you, so which commit
is responsible for the hang you observe?

It seems this commit fixes a hang for you and causes another hang for me :-)

Any ideas?

Thanks

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>

This patches causes a regression on a imx51-babbage running 4.18-rc1:
I get a kernel hang.

If I revert it on top of 4.18-rc1, then it boots fine and USB host is
functional.

I understand this patch fixes a kernel hang for you, so which commit
is responsible for the hang you observe?

It seems this commit fixes a hang for you and causes another hang for me :-)

Any ideas?

Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Wed, May 30, 2018 at 2:34 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Workaround introduced for i.MX53 in be9cae2479f48 ("usb: chipidea:
> imx: Fix ULPI on imx53") seems to be applicable in case of i.MX51 as
> well. Running latest kernel on ZII RDU1 Board (imx51-zii-rdu1.dts)
> exhibits a kernel frozen on PORTSC access and applying the workaround
> resolves the issue.
>
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-usb at vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>

This patches causes a regression on a imx51-babbage running 4.18-rc1:
I get a kernel hang.

If I revert it on top of 4.18-rc1, then it boots fine and USB host is
functional.

I understand this patch fixes a kernel hang for you, so which commit
is responsible for the hang you observe?

It seems this commit fixes a hang for you and causes another hang for me :-)

Any ideas?

Thanks

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:

> This patches causes a regression on a imx51-babbage running 4.18-rc1:
> I get a kernel hang.
>
> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> functional.
>
> I understand this patch fixes a kernel hang for you, so which commit
> is responsible for the hang you observe?
>
> It seems this commit fixes a hang for you and causes another hang for me :-)
>
> Any ideas?

I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:

--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -294,7 +294,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
        if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
             of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
            of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
-               pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
                data->override_phy_control = true;
                usb_phy_init(pdata.usb_phy);
        }

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:

> This patches causes a regression on a imx51-babbage running 4.18-rc1:
> I get a kernel hang.
>
> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> functional.
>
> I understand this patch fixes a kernel hang for you, so which commit
> is responsible for the hang you observe?
>
> It seems this commit fixes a hang for you and causes another hang for me :-)
>
> Any ideas?

I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -294,7 +294,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
        if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
             of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
            of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
-               pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
                data->override_phy_control = true;
                usb_phy_init(pdata.usb_phy);
        }

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:

> This patches causes a regression on a imx51-babbage running 4.18-rc1:
> I get a kernel hang.
>
> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> functional.
>
> I understand this patch fixes a kernel hang for you, so which commit
> is responsible for the hang you observe?
>
> It seems this commit fixes a hang for you and causes another hang for me :-)
>
> Any ideas?

I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:

--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -294,7 +294,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
        if ((of_device_is_compatible(np, "fsl,imx53-usb") ||
             of_device_is_compatible(np, "fsl,imx51-usb")) && pdata.usb_phy &&
            of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
-               pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
                data->override_phy_control = true;
                usb_phy_init(pdata.usb_phy);
        }

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Wed, Jun 20, 2018 at 3:22 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
> > This patches causes a regression on a imx51-babbage running 4.18-rc1:
> > I get a kernel hang.
> >
> > If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> > functional.
> >
> > I understand this patch fixes a kernel hang for you, so which commit
> > is responsible for the hang you observe?
> >

I never assumed it was a regression and that USB worked on RDU1 board
before, so I never tried to see if this was a regression. I can only
tell you that it hangs as soon as any PORTSC registers are accessed.

> > It seems this commit fixes a hang for you and causes another hang for me :-)
> >
> > Any ideas?
>

RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
portion of it is an exact copy (it does use different GPIO for PHY
reset, but that's irrelevant), so I am surprised that it breaks in
your case.

However looking at imx51-babbage.dts, I am suspicious of it's USB1
setup. There we have usbh1phy node that references <&gpio2 5
GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
is not being used anywhere. Cold that be that the problem you are
seeing is due to USB PHY not being properly reset?

> I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:
>

Yeah, IMHO if you are dropping that flag, you may as well revert the
whole patch :-). The path that make the kernel hang in my case would
be taken if that flag is dropped.

Thanks,
Andrey Smirnov

usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Wed, Jun 20, 2018 at 3:22 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
> > This patches causes a regression on a imx51-babbage running 4.18-rc1:
> > I get a kernel hang.
> >
> > If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> > functional.
> >
> > I understand this patch fixes a kernel hang for you, so which commit
> > is responsible for the hang you observe?
> >

I never assumed it was a regression and that USB worked on RDU1 board
before, so I never tried to see if this was a regression. I can only
tell you that it hangs as soon as any PORTSC registers are accessed.

> > It seems this commit fixes a hang for you and causes another hang for me :-)
> >
> > Any ideas?
>

RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
portion of it is an exact copy (it does use different GPIO for PHY
reset, but that's irrelevant), so I am surprised that it breaks in
your case.

However looking at imx51-babbage.dts, I am suspicious of it's USB1
setup. There we have usbh1phy node that references <&gpio2 5
GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
is not being used anywhere. Cold that be that the problem you are
seeing is due to USB PHY not being properly reset?

> I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:
>

Yeah, IMHO if you are dropping that flag, you may as well revert the
whole patch :-). The path that make the kernel hang in my case would
be taken if that flag is dropped.

Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Wed, Jun 20, 2018 at 3:22 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
> > This patches causes a regression on a imx51-babbage running 4.18-rc1:
> > I get a kernel hang.
> >
> > If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> > functional.
> >
> > I understand this patch fixes a kernel hang for you, so which commit
> > is responsible for the hang you observe?
> >

I never assumed it was a regression and that USB worked on RDU1 board
before, so I never tried to see if this was a regression. I can only
tell you that it hangs as soon as any PORTSC registers are accessed.

> > It seems this commit fixes a hang for you and causes another hang for me :-)
> >
> > Any ideas?
>

RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
portion of it is an exact copy (it does use different GPIO for PHY
reset, but that's irrelevant), so I am surprised that it breaks in
your case.

However looking at imx51-babbage.dts, I am suspicious of it's USB1
setup. There we have usbh1phy node that references <&gpio2 5
GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
is not being used anywhere. Cold that be that the problem you are
seeing is due to USB PHY not being properly reset?

> I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:
>

Yeah, IMHO if you are dropping that flag, you may as well revert the
whole patch :-). The path that make the kernel hang in my case would
be taken if that flag is dropped.

Thanks,
Andrey Smirnov

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.

I think we need to investigate this portsc register hang further.

> RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
> portion of it is an exact copy (it does use different GPIO for PHY
> reset, but that's irrelevant), so I am surprised that it breaks in
> your case.
>
> However looking at imx51-babbage.dts, I am suspicious of it's USB1
> setup. There we have usbh1phy node that references <&gpio2 5
> GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
> is not being used anywhere. Cold that be that the problem you are
> seeing is due to USB PHY not being properly reset?

Yes, this can be improved, but this is not the cause of the issue .

gpio2 5 is passed as the USB PHY reset:

reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;

The default IOMUX setting after power on reset  is GPIO, so not an issue.

> Yeah, IMHO if you are dropping that flag, you may as well revert the
> whole patch :-). The path that make the kernel hang in my case would
> be taken if that flag is dropped.

Yes, it seems we need to revert the full patch and have a proper fix
in place that works for imx51 RDU, imx53-ppd and imx51 babbage.

The USB host 1 on imx51-babbage has been working since kernel 3.19 :-)

Thanks

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.

I think we need to investigate this portsc register hang further.

> RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
> portion of it is an exact copy (it does use different GPIO for PHY
> reset, but that's irrelevant), so I am surprised that it breaks in
> your case.
>
> However looking at imx51-babbage.dts, I am suspicious of it's USB1
> setup. There we have usbh1phy node that references <&gpio2 5
> GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
> is not being used anywhere. Cold that be that the problem you are
> seeing is due to USB PHY not being properly reset?

Yes, this can be improved, but this is not the cause of the issue .

gpio2 5 is passed as the USB PHY reset:

reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;

The default IOMUX setting after power on reset  is GPIO, so not an issue.

> Yeah, IMHO if you are dropping that flag, you may as well revert the
> whole patch :-). The path that make the kernel hang in my case would
> be taken if that flag is dropped.

Yes, it seems we need to revert the full patch and have a proper fix
in place that works for imx51 RDU, imx53-ppd and imx51 babbage.

The USB host 1 on imx51-babbage has been working since kernel 3.19 :-)

Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.

I think we need to investigate this portsc register hang further.

> RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
> portion of it is an exact copy (it does use different GPIO for PHY
> reset, but that's irrelevant), so I am surprised that it breaks in
> your case.
>
> However looking at imx51-babbage.dts, I am suspicious of it's USB1
> setup. There we have usbh1phy node that references <&gpio2 5
> GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
> is not being used anywhere. Cold that be that the problem you are
> seeing is due to USB PHY not being properly reset?

Yes, this can be improved, but this is not the cause of the issue .

gpio2 5 is passed as the USB PHY reset:

reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;

The default IOMUX setting after power on reset  is GPIO, so not an issue.

> Yeah, IMHO if you are dropping that flag, you may as well revert the
> whole patch :-). The path that make the kernel hang in my case would
> be taken if that flag is dropped.

Yes, it seems we need to revert the full patch and have a proper fix
in place that works for imx51 RDU, imx53-ppd and imx51 babbage.

The USB host 1 on imx51-babbage has been working since kernel 3.19 :-)

Thanks

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>> I get a kernel hang.
>>>
>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>> functional.
>>>
>>> I understand this patch fixes a kernel hang for you, so which commit
>>> is responsible for the hang you observe?
>>>
> 
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.

Hang at register access usually means that module that owns the register
is not clocked.

usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>> I get a kernel hang.
>>>
>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>> functional.
>>>
>>> I understand this patch fixes a kernel hang for you, so which commit
>>> is responsible for the hang you observe?
>>>
> 
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.

Hang at register access usually means that module that owns the register
is not clocked.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>> I get a kernel hang.
>>>
>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>> functional.
>>>
>>> I understand this patch fixes a kernel hang for you, so which commit
>>> is responsible for the hang you observe?
>>>
> 
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.

Hang at register access usually means that module that owns the register
is not clocked.

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

21.06.2018 17:12, Nikita Yushchenko wrote:
>>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>>> I get a kernel hang.
>>>>
>>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>>> functional.
>>>>
>>>> I understand this patch fixes a kernel hang for you, so which commit
>>>> is responsible for the hang you observe?
>>>>
>>
>> I never assumed it was a regression and that USB worked on RDU1 board
>> before, so I never tried to see if this was a regression. I can only
>> tell you that it hangs as soon as any PORTSC registers are accessed.
> 
> Hang at register access usually means that module that owns the register
> is not clocked.

On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that
does regulator_enable() for &vusb_reg and clk_prepare_enable() for
&clk_26M_usb.  I thing some of these two is actually needed to avoid
hang on register access.

usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

21.06.2018 17:12, Nikita Yushchenko wrote:
>>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>>> I get a kernel hang.
>>>>
>>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>>> functional.
>>>>
>>>> I understand this patch fixes a kernel hang for you, so which commit
>>>> is responsible for the hang you observe?
>>>>
>>
>> I never assumed it was a regression and that USB worked on RDU1 board
>> before, so I never tried to see if this was a regression. I can only
>> tell you that it hangs as soon as any PORTSC registers are accessed.
> 
> Hang at register access usually means that module that owns the register
> is not clocked.

On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that
does regulator_enable() for &vusb_reg and clk_prepare_enable() for
&clk_26M_usb.  I thing some of these two is actually needed to avoid
hang on register access.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Nikita Yushchenko]

21.06.2018 17:12, Nikita Yushchenko wrote:
>>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>>> I get a kernel hang.
>>>>
>>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>>> functional.
>>>>
>>>> I understand this patch fixes a kernel hang for you, so which commit
>>>> is responsible for the hang you observe?
>>>>
>>
>> I never assumed it was a regression and that USB worked on RDU1 board
>> before, so I never tried to see if this was a regression. I can only
>> tell you that it hangs as soon as any PORTSC registers are accessed.
> 
> Hang at register access usually means that module that owns the register
> is not clocked.

On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that
does regulator_enable() for &vusb_reg and clk_prepare_enable() for
&clk_26M_usb.  I thing some of these two is actually needed to avoid
hang on register access.

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>

I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.

Any chance you can try it on your end and see if that makes a difference?

Thanks,
Andrey Smirnov

usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>

I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.

Any chance you can try it on your end and see if that makes a difference?

Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>

I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.

Any chance you can try it on your end and see if that makes a difference?

Thanks,
Andrey Smirnov

RE: [PATCH] usb: chipidea: Fix ULPI on imx51

[Peter Chen]

 
> >>>>
> >>
> >> I never assumed it was a regression and that USB worked on RDU1 board
> >> before, so I never tried to see if this was a regression. I can only
> >> tell you that it hangs as soon as any PORTSC registers are accessed.
> >
> > Hang at register access usually means that module that owns the
> > register is not clocked.
> 
> On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that does
> regulator_enable() for &vusb_reg and clk_prepare_enable() for &clk_26M_usb.  I
> thing some of these two is actually needed to avoid hang on register access.

Fabio, would you please check both regulator and clock for ULPI PHY are on at imx51bbg?

Peter

usb: chipidea: Fix ULPI on imx51

[Peter Chen]

> >>>>
> >>
> >> I never assumed it was a regression and that USB worked on RDU1 board
> >> before, so I never tried to see if this was a regression. I can only
> >> tell you that it hangs as soon as any PORTSC registers are accessed.
> >
> > Hang at register access usually means that module that owns the
> > register is not clocked.
> 
> On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that does
> regulator_enable() for &vusb_reg and clk_prepare_enable() for &clk_26M_usb.  I
> thing some of these two is actually needed to avoid hang on register access.

Fabio, would you please check both regulator and clock for ULPI PHY are on at imx51bbg?

Peter

[PATCH] usb: chipidea: Fix ULPI on imx51

[Peter Chen]

 
> >>>>
> >>
> >> I never assumed it was a regression and that USB worked on RDU1 board
> >> before, so I never tried to see if this was a regression. I can only
> >> tell you that it hangs as soon as any PORTSC registers are accessed.
> >
> > Hang at register access usually means that module that owns the
> > register is not clocked.
> 
> On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that does
> regulator_enable() for &vusb_reg and clk_prepare_enable() for &clk_26M_usb.  I
> thing some of these two is actually needed to avoid hang on register access.

Fabio, would you please check both regulator and clock for ULPI PHY are on at imx51bbg?

Peter

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> I just finished experimenting with it on RDU1 and Babbage boards and I
> can't reproduce the hang that you describe against 4.18-rc1. At this
> point I wonder if it's the bootloader that is a variable that plays
> into this. I was booting both boards with 2018.06.0 version of barebox
> + the custom patches that can be found here
> https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> last patch in that branch/stack was added as a part of this
> investigation, but even before it, I was able to boot Linux just fine,
> albeit without working USB.

Thanks for investigating this issue.

Yes, t is possible that the difference in behaviour that we see could
be related to the fact we use different bootloaders.

In order to make things easier, I am sharing a Buildroot image for
imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0

Please flash it directly to the SD card via dd and boot it.

You will notice that it will boot normally. Then please copy a
4.18-rc1 zImage into the first SD card partition and you will notice
the hang.

Thanks

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> I just finished experimenting with it on RDU1 and Babbage boards and I
> can't reproduce the hang that you describe against 4.18-rc1. At this
> point I wonder if it's the bootloader that is a variable that plays
> into this. I was booting both boards with 2018.06.0 version of barebox
> + the custom patches that can be found here
> https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> last patch in that branch/stack was added as a part of this
> investigation, but even before it, I was able to boot Linux just fine,
> albeit without working USB.

Thanks for investigating this issue.

Yes, t is possible that the difference in behaviour that we see could
be related to the fact we use different bootloaders.

In order to make things easier, I am sharing a Buildroot image for
imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0

Please flash it directly to the SD card via dd and boot it.

You will notice that it will boot normally. Then please copy a
4.18-rc1 zImage into the first SD card partition and you will notice
the hang.

Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> I just finished experimenting with it on RDU1 and Babbage boards and I
> can't reproduce the hang that you describe against 4.18-rc1. At this
> point I wonder if it's the bootloader that is a variable that plays
> into this. I was booting both boards with 2018.06.0 version of barebox
> + the custom patches that can be found here
> https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> last patch in that branch/stack was added as a part of this
> investigation, but even before it, I was able to boot Linux just fine,
> albeit without working USB.

Thanks for investigating this issue.

Yes, t is possible that the difference in behaviour that we see could
be related to the fact we use different bootloaders.

In order to make things easier, I am sharing a Buildroot image for
imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0

Please flash it directly to the SD card via dd and boot it.

You will notice that it will boot normally. Then please copy a
4.18-rc1 zImage into the first SD card partition and you will notice
the hang.

Thanks

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I just finished experimenting with it on RDU1 and Babbage boards and I
> > can't reproduce the hang that you describe against 4.18-rc1. At this
> > point I wonder if it's the bootloader that is a variable that plays
> > into this. I was booting both boards with 2018.06.0 version of barebox
> > + the custom patches that can be found here
> > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> > last patch in that branch/stack was added as a part of this
> > investigation, but even before it, I was able to boot Linux just fine,
> > albeit without working USB.
>
> Thanks for investigating this issue.
>
> Yes, t is possible that the difference in behaviour that we see could
> be related to the fact we use different bootloaders.
>
> In order to make things easier, I am sharing a Buildroot image for
> imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
> https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
>
> Please flash it directly to the SD card via dd and boot it.
>
> You will notice that it will boot normally. Then please copy a
> 4.18-rc1 zImage into the first SD card partition and you will notice
> the hang.
>

It's definitely the bootloader, or more specifically whether or not it
initialized/used USB before booting the kernel. Some interesting
highlights:

 - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
start" (optionally "usb stop") and then "boot", you'll get the hang
that I was trying to fix with my patch.

 - Things are exact opposite with 4.18-rc1 and doing the above would
_prevent_ the hang and the image would boot fine.

 - Disabling USB in Barebox based boot "stack" gets it to behave the
same way as U-boot from your image (hanging when booting 4.18-rc1)

Digging more into code it seems that the reason for 4.18-rc1's
behavior is the fact that it's missing a call hw_phymode_configure()
after usb_phy_init() and, AFAICT, the only reason it is not happening
is because default image is being built without
CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
options on 4.18-rc1, seem to fix the problem on both your U-Boot based
image and my "special" Barebox setup.

So AFAICT, this patch still fixes a valid issue (my use-case was net
booting via USB-Ethernet dongle), but an additional patch enabling
those two configuration options might be needed. Thoughts?

Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
of enabling those two options there.

Thanks,
Andrey Smirnov

usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I just finished experimenting with it on RDU1 and Babbage boards and I
> > can't reproduce the hang that you describe against 4.18-rc1. At this
> > point I wonder if it's the bootloader that is a variable that plays
> > into this. I was booting both boards with 2018.06.0 version of barebox
> > + the custom patches that can be found here
> > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> > last patch in that branch/stack was added as a part of this
> > investigation, but even before it, I was able to boot Linux just fine,
> > albeit without working USB.
>
> Thanks for investigating this issue.
>
> Yes, t is possible that the difference in behaviour that we see could
> be related to the fact we use different bootloaders.
>
> In order to make things easier, I am sharing a Buildroot image for
> imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
> https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
>
> Please flash it directly to the SD card via dd and boot it.
>
> You will notice that it will boot normally. Then please copy a
> 4.18-rc1 zImage into the first SD card partition and you will notice
> the hang.
>

It's definitely the bootloader, or more specifically whether or not it
initialized/used USB before booting the kernel. Some interesting
highlights:

 - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
start" (optionally "usb stop") and then "boot", you'll get the hang
that I was trying to fix with my patch.

 - Things are exact opposite with 4.18-rc1 and doing the above would
_prevent_ the hang and the image would boot fine.

 - Disabling USB in Barebox based boot "stack" gets it to behave the
same way as U-boot from your image (hanging when booting 4.18-rc1)

Digging more into code it seems that the reason for 4.18-rc1's
behavior is the fact that it's missing a call hw_phymode_configure()
after usb_phy_init() and, AFAICT, the only reason it is not happening
is because default image is being built without
CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
options on 4.18-rc1, seem to fix the problem on both your U-Boot based
image and my "special" Barebox setup.

So AFAICT, this patch still fixes a valid issue (my use-case was net
booting via USB-Ethernet dongle), but an additional patch enabling
those two configuration options might be needed. Thoughts?

Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
of enabling those two options there.

Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Andrey Smirnov]

On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I just finished experimenting with it on RDU1 and Babbage boards and I
> > can't reproduce the hang that you describe against 4.18-rc1. At this
> > point I wonder if it's the bootloader that is a variable that plays
> > into this. I was booting both boards with 2018.06.0 version of barebox
> > + the custom patches that can be found here
> > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> > last patch in that branch/stack was added as a part of this
> > investigation, but even before it, I was able to boot Linux just fine,
> > albeit without working USB.
>
> Thanks for investigating this issue.
>
> Yes, t is possible that the difference in behaviour that we see could
> be related to the fact we use different bootloaders.
>
> In order to make things easier, I am sharing a Buildroot image for
> imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
> https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
>
> Please flash it directly to the SD card via dd and boot it.
>
> You will notice that it will boot normally. Then please copy a
> 4.18-rc1 zImage into the first SD card partition and you will notice
> the hang.
>

It's definitely the bootloader, or more specifically whether or not it
initialized/used USB before booting the kernel. Some interesting
highlights:

 - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
start" (optionally "usb stop") and then "boot", you'll get the hang
that I was trying to fix with my patch.

 - Things are exact opposite with 4.18-rc1 and doing the above would
_prevent_ the hang and the image would boot fine.

 - Disabling USB in Barebox based boot "stack" gets it to behave the
same way as U-boot from your image (hanging when booting 4.18-rc1)

Digging more into code it seems that the reason for 4.18-rc1's
behavior is the fact that it's missing a call hw_phymode_configure()
after usb_phy_init() and, AFAICT, the only reason it is not happening
is because default image is being built without
CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
options on 4.18-rc1, seem to fix the problem on both your U-Boot based
image and my "special" Barebox setup.

So AFAICT, this patch still fixes a valid issue (my use-case was net
booting via USB-Ethernet dongle), but an additional patch enabling
those two configuration options might be needed. Thoughts?

Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
of enabling those two options there.

Thanks,
Andrey Smirnov

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> It's definitely the bootloader, or more specifically whether or not it
> initialized/used USB before booting the kernel. Some interesting
> highlights:
>
>  - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> start" (optionally "usb stop") and then "boot", you'll get the hang
> that I was trying to fix with my patch.
>
>  - Things are exact opposite with 4.18-rc1 and doing the above would
> _prevent_ the hang and the image would boot fine.
>
>  - Disabling USB in Barebox based boot "stack" gets it to behave the
> same way as U-boot from your image (hanging when booting 4.18-rc1)
>
> Digging more into code it seems that the reason for 4.18-rc1's
> behavior is the fact that it's missing a call hw_phymode_configure()
> after usb_phy_init() and, AFAICT, the only reason it is not happening
> is because default image is being built without
> CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> image and my "special" Barebox setup.
>
> So AFAICT, this patch still fixes a valid issue (my use-case was net
> booting via USB-Ethernet dongle), but an additional patch enabling
> those two configuration options might be needed. Thoughts?

Yes, I can confirm that your suggested change avoids the kernel hang:

diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index d14de86..2da678c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_ULPI=y
 CONFIG_USB_SERIAL=m
 CONFIG_USB_SERIAL_GENERIC=y
 CONFIG_USB_SERIAL_FTDI_SIO=m
@@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
 CONFIG_USB_FUNCTIONFS=m
 CONFIG_USB_MASS_STORAGE=m
 CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI_BUS=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y

> Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> of enabling those two options there.

The imx53 board I have access to does not use ULPI.

Maybe Sebastian on Cc may help testing this on his imx53 board as he
is the author of:
be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")

I am wondering if we need to force some kind of USB reset to put the
USB controller into a known state independently of what the bootloader
has done previously.

Thanks

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> It's definitely the bootloader, or more specifically whether or not it
> initialized/used USB before booting the kernel. Some interesting
> highlights:
>
>  - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> start" (optionally "usb stop") and then "boot", you'll get the hang
> that I was trying to fix with my patch.
>
>  - Things are exact opposite with 4.18-rc1 and doing the above would
> _prevent_ the hang and the image would boot fine.
>
>  - Disabling USB in Barebox based boot "stack" gets it to behave the
> same way as U-boot from your image (hanging when booting 4.18-rc1)
>
> Digging more into code it seems that the reason for 4.18-rc1's
> behavior is the fact that it's missing a call hw_phymode_configure()
> after usb_phy_init() and, AFAICT, the only reason it is not happening
> is because default image is being built without
> CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> image and my "special" Barebox setup.
>
> So AFAICT, this patch still fixes a valid issue (my use-case was net
> booting via USB-Ethernet dongle), but an additional patch enabling
> those two configuration options might be needed. Thoughts?

Yes, I can confirm that your suggested change avoids the kernel hang:


> Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> of enabling those two options there.

The imx53 board I have access to does not use ULPI.

Maybe Sebastian on Cc may help testing this on his imx53 board as he
is the author of:
be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")

I am wondering if we need to force some kind of USB reset to put the
USB controller into a known state independently of what the bootloader
has done previously.

Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index d14de86..2da678c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_ULPI=y
 CONFIG_USB_SERIAL=m
 CONFIG_USB_SERIAL_GENERIC=y
 CONFIG_USB_SERIAL_FTDI_SIO=m
@@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
 CONFIG_USB_FUNCTIONFS=m
 CONFIG_USB_MASS_STORAGE=m
 CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI_BUS=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Andrey,

On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:

> It's definitely the bootloader, or more specifically whether or not it
> initialized/used USB before booting the kernel. Some interesting
> highlights:
>
>  - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> start" (optionally "usb stop") and then "boot", you'll get the hang
> that I was trying to fix with my patch.
>
>  - Things are exact opposite with 4.18-rc1 and doing the above would
> _prevent_ the hang and the image would boot fine.
>
>  - Disabling USB in Barebox based boot "stack" gets it to behave the
> same way as U-boot from your image (hanging when booting 4.18-rc1)
>
> Digging more into code it seems that the reason for 4.18-rc1's
> behavior is the fact that it's missing a call hw_phymode_configure()
> after usb_phy_init() and, AFAICT, the only reason it is not happening
> is because default image is being built without
> CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> image and my "special" Barebox setup.
>
> So AFAICT, this patch still fixes a valid issue (my use-case was net
> booting via USB-Ethernet dongle), but an additional patch enabling
> those two configuration options might be needed. Thoughts?

Yes, I can confirm that your suggested change avoids the kernel hang:

diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index d14de86..2da678c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_ULPI=y
 CONFIG_USB_SERIAL=m
 CONFIG_USB_SERIAL_GENERIC=y
 CONFIG_USB_SERIAL_FTDI_SIO=m
@@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
 CONFIG_USB_FUNCTIONFS=m
 CONFIG_USB_MASS_STORAGE=m
 CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI_BUS=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y

> Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> of enabling those two options there.

The imx53 board I have access to does not use ULPI.

Maybe Sebastian on Cc may help testing this on his imx53 board as he
is the author of:
be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")

I am wondering if we need to force some kind of USB reset to put the
USB controller into a known state independently of what the bootloader
has done previously.

Thanks

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

Hi,

On Sun, Jun 24, 2018 at 08:51:20PM -0300, Fabio Estevam wrote:
> Hi Andrey,
> 
> On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
> 
> > It's definitely the bootloader, or more specifically whether or not it
> > initialized/used USB before booting the kernel. Some interesting
> > highlights:
> >
> >  - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> > start" (optionally "usb stop") and then "boot", you'll get the hang
> > that I was trying to fix with my patch.
> >
> >  - Things are exact opposite with 4.18-rc1 and doing the above would
> > _prevent_ the hang and the image would boot fine.
> >
> >  - Disabling USB in Barebox based boot "stack" gets it to behave the
> > same way as U-boot from your image (hanging when booting 4.18-rc1)
> >
> > Digging more into code it seems that the reason for 4.18-rc1's
> > behavior is the fact that it's missing a call hw_phymode_configure()
> > after usb_phy_init() and, AFAICT, the only reason it is not happening
> > is because default image is being built without
> > CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> > options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> > image and my "special" Barebox setup.
> >
> > So AFAICT, this patch still fixes a valid issue (my use-case was net
> > booting via USB-Ethernet dongle), but an additional patch enabling
> > those two configuration options might be needed. Thoughts?
> 
> Yes, I can confirm that your suggested change avoids the kernel hang:
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index d14de86..2da678c 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
>  CONFIG_USB_CHIPIDEA=y
>  CONFIG_USB_CHIPIDEA_UDC=y
>  CONFIG_USB_CHIPIDEA_HOST=y
> +CONFIG_USB_CHIPIDEA_ULPI=y
>  CONFIG_USB_SERIAL=m
>  CONFIG_USB_SERIAL_GENERIC=y
>  CONFIG_USB_SERIAL_FTDI_SIO=m
> @@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
>  CONFIG_USB_FUNCTIONFS=m
>  CONFIG_USB_MASS_STORAGE=m
>  CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_ULPI_BUS=y
>  CONFIG_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_PLTFM=y
> 
> > Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> > of enabling those two options there.
> 
> The imx53 board I have access to does not use ULPI.
> 
> Maybe Sebastian on Cc may help testing this on his imx53 board as he
> is the author of:
> be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")

I still have access to the imx53 based PPD from General Electric.
But I don't understand what patch you want me to test. FWIW the
images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
and CONFIG_USB_ULPI_BUS enabled.

> I am wondering if we need to force some kind of USB reset to put the
> USB controller into a known state independently of what the bootloader
> has done previously.

Makes sense to me.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

usb: chipidea: Fix ULPI on imx51

[Sebastian Reichel]

Hi,

On Sun, Jun 24, 2018 at 08:51:20PM -0300, Fabio Estevam wrote:
> Hi Andrey,
> 
> On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
> 
> > It's definitely the bootloader, or more specifically whether or not it
> > initialized/used USB before booting the kernel. Some interesting
> > highlights:
> >
> >  - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> > start" (optionally "usb stop") and then "boot", you'll get the hang
> > that I was trying to fix with my patch.
> >
> >  - Things are exact opposite with 4.18-rc1 and doing the above would
> > _prevent_ the hang and the image would boot fine.
> >
> >  - Disabling USB in Barebox based boot "stack" gets it to behave the
> > same way as U-boot from your image (hanging when booting 4.18-rc1)
> >
> > Digging more into code it seems that the reason for 4.18-rc1's
> > behavior is the fact that it's missing a call hw_phymode_configure()
> > after usb_phy_init() and, AFAICT, the only reason it is not happening
> > is because default image is being built without
> > CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> > options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> > image and my "special" Barebox setup.
> >
> > So AFAICT, this patch still fixes a valid issue (my use-case was net
> > booting via USB-Ethernet dongle), but an additional patch enabling
> > those two configuration options might be needed. Thoughts?
> 
> Yes, I can confirm that your suggested change avoids the kernel hang:
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index d14de86..2da678c 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
>  CONFIG_USB_CHIPIDEA=y
>  CONFIG_USB_CHIPIDEA_UDC=y
>  CONFIG_USB_CHIPIDEA_HOST=y
> +CONFIG_USB_CHIPIDEA_ULPI=y
>  CONFIG_USB_SERIAL=m
>  CONFIG_USB_SERIAL_GENERIC=y
>  CONFIG_USB_SERIAL_FTDI_SIO=m
> @@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
>  CONFIG_USB_FUNCTIONFS=m
>  CONFIG_USB_MASS_STORAGE=m
>  CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_ULPI_BUS=y
>  CONFIG_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_PLTFM=y
> 
> > Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> > of enabling those two options there.
> 
> The imx53 board I have access to does not use ULPI.
> 
> Maybe Sebastian on Cc may help testing this on his imx53 board as he
> is the author of:
> be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")

I still have access to the imx53 based PPD from General Electric.
But I don't understand what patch you want me to test. FWIW the
images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
and CONFIG_USB_ULPI_BUS enabled.

> I am wondering if we need to force some kind of USB reset to put the
> USB controller into a known state independently of what the bootloader
> has done previously.

Makes sense to me.

-- Sebastian

[PATCH] usb: chipidea: Fix ULPI on imx51

[Sebastian Reichel]

Hi,

On Sun, Jun 24, 2018 at 08:51:20PM -0300, Fabio Estevam wrote:
> Hi Andrey,
> 
> On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
> 
> > It's definitely the bootloader, or more specifically whether or not it
> > initialized/used USB before booting the kernel. Some interesting
> > highlights:
> >
> >  - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> > start" (optionally "usb stop") and then "boot", you'll get the hang
> > that I was trying to fix with my patch.
> >
> >  - Things are exact opposite with 4.18-rc1 and doing the above would
> > _prevent_ the hang and the image would boot fine.
> >
> >  - Disabling USB in Barebox based boot "stack" gets it to behave the
> > same way as U-boot from your image (hanging when booting 4.18-rc1)
> >
> > Digging more into code it seems that the reason for 4.18-rc1's
> > behavior is the fact that it's missing a call hw_phymode_configure()
> > after usb_phy_init() and, AFAICT, the only reason it is not happening
> > is because default image is being built without
> > CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> > options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> > image and my "special" Barebox setup.
> >
> > So AFAICT, this patch still fixes a valid issue (my use-case was net
> > booting via USB-Ethernet dongle), but an additional patch enabling
> > those two configuration options might be needed. Thoughts?
> 
> Yes, I can confirm that your suggested change avoids the kernel hang:
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index d14de86..2da678c 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
>  CONFIG_USB_CHIPIDEA=y
>  CONFIG_USB_CHIPIDEA_UDC=y
>  CONFIG_USB_CHIPIDEA_HOST=y
> +CONFIG_USB_CHIPIDEA_ULPI=y
>  CONFIG_USB_SERIAL=m
>  CONFIG_USB_SERIAL_GENERIC=y
>  CONFIG_USB_SERIAL_FTDI_SIO=m
> @@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
>  CONFIG_USB_FUNCTIONFS=m
>  CONFIG_USB_MASS_STORAGE=m
>  CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_ULPI_BUS=y
>  CONFIG_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_PLTFM=y
> 
> > Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> > of enabling those two options there.
> 
> The imx53 board I have access to does not use ULPI.
> 
> Maybe Sebastian on Cc may help testing this on his imx53 board as he
> is the author of:
> be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")

I still have access to the imx53 based PPD from General Electric.
But I don't understand what patch you want me to test. FWIW the
images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
and CONFIG_USB_ULPI_BUS enabled.

> I am wondering if we need to force some kind of USB reset to put the
> USB controller into a known state independently of what the bootloader
> has done previously.

Makes sense to me.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180625/bcdea32f/attachment.sig>

Re: [PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Sebastian,

On Mon, Jun 25, 2018 at 9:18 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:

> I still have access to the imx53 based PPD from General Electric.
> But I don't understand what patch you want me to test. FWIW the
> images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
> and CONFIG_USB_ULPI_BUS enabled.

I was referring to the patch that enables CONFIG_USB_CHIPIDEA_ULPI and
CONFIG_USB_ULPI_BUS.

Will submit this change as suggested by Andrey.

Regards,

Fabio Estevam

usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Sebastian,

On Mon, Jun 25, 2018 at 9:18 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:

> I still have access to the imx53 based PPD from General Electric.
> But I don't understand what patch you want me to test. FWIW the
> images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
> and CONFIG_USB_ULPI_BUS enabled.

I was referring to the patch that enables CONFIG_USB_CHIPIDEA_ULPI and
CONFIG_USB_ULPI_BUS.

Will submit this change as suggested by Andrey.

Regards,

Fabio Estevam
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: chipidea: Fix ULPI on imx51

[Fabio Estevam]

Hi Sebastian,

On Mon, Jun 25, 2018 at 9:18 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:

> I still have access to the imx53 based PPD from General Electric.
> But I don't understand what patch you want me to test. FWIW the
> images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
> and CONFIG_USB_ULPI_BUS enabled.

I was referring to the patch that enables CONFIG_USB_CHIPIDEA_ULPI and
CONFIG_USB_ULPI_BUS.

Will submit this change as suggested by Andrey.

Regards,

Fabio Estevam