Hi Frieder
As Philippe is about to go on his well-deserved vacation he asked my to help answering your questions. As I was
also involved in the initial analysis of this issue I am happy to help.
On Mon, 2022-08-01 at 14:14 +0200, Frieder Schrempf wrote:
> +CC: Li Jun, Jacky Bai, Lucas Stach
>
> Hi Philippe,
>
> Am 22.07.22 um 09:55 schrieb Philippe Schenker:
> > From: Philippe Schenker <philippe.schenker@xxxxxxxxxxx>
> >
> > The Verdin iMX8M Mini System on Module does not have VBUS
It's actually the ID pin we are talking about. VBUS is connected just fine.
> > signal
> > connected on Verdin USB_2 (usbotg2). On Verdin Development board this is
> > no problem, as we have connected a USB-Hub that is always connected.
> >
> > However, if Verdin USB_2 is desired to be used as a single USB-Host port
> > the chipidea driver does not detect if a USB device is plugged into this
> > port, due to runtime pm shutting down the PHY.
> >
> > Add the power-domain &pgc_otg2 to &usbphynop2 in order to detect
> > plugging events and enumerate the usb device.
> >
> > Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini")
> > Signed-off-by: Philippe Schenker <philippe.schenker@xxxxxxxxxxx>
>
> I'm probably having the same issue on our hardware.
Does your hardware also NOT connect the ID pin (sorry, Philippe initially confused it with the VBUS pin)?
BTW: According to a lengthy discussion under NDA with NXP the ID pin would need connecting even for host only
operation but our current PCB does really not allow for this to be easily done even just for verifying NXP's
claim.
> There was a previous
> attempt to fix this globally for all the i.MX8MM boards here: [1].
>
> Unfortunately this didn't seem to work as intended in my case (see
> discussion for that patch). Looking at your patch I wonder if not having
> the vcc-supply for the usbphynop causes problems in my case. Do you
> happen to know the effect of adding the regulator here? I don't see this
> in any other i.MX8MM board devicetree.
>
> Could you test Li's patch instead of this board specific fix and see if
> it works for you?
I read that and doing some more testing I just realised that detection does indeed not seem to work on usbotg1
neither, even though that one has the ID pin connected just fine! So it indeed seems to be a more generic
issue.
Okay, for me Li's patch actually fixed that detection issue on usbotg1. Yeah! That is on one of our carrier
boards either Dahlia or the Verdin development board where usbotg1 goes to a regular fully OTG resp.
device/host-switchable USB-C port (with ID and VBUS pins being connected). usbotg2 connects to an always
connected USB hub, so no detection issues ever there as that hub handles it just fine.
Now the issue Philippe's patch addresses is on a different custom carrier board where usbotg1 is a device-only
micro-USB port while usbotg2 is a regular USB-A host-only port. There, unfortunately, Li's patch does not fix
the issue. However, as stated above, according to NXP that ID pin would really need to be connected. So
basically this patch here from Philippe addresses an issue with our broken hardware to make detection work
regardless (by basically indirectly disabling auto-suspend).
> On your hardware, do you have an always-on device on
> the usbotg1 port?
No, as mentioned above, our Dahlia and Verdin development board have a regular fully OTG resp. device/host-
switchable USB-C port. While that custom carrier board has a device only micro-USB port.
> If yes, does the detection on the usbotg2 port still
> work if the usbotg1 port is disabled in the devicetree?
I believe this might be a separate issue recently also reported to us by a customer. However, most likely that
is/was on downstream and maybe even on a different i.MX 8 series based module, not quite sure. Let me check...
Anyway, for us on that custom carrier board detection does not even work in the regular case with usbotg1 being
available (albeit micro-USB device-mode only). Unfortunately, we don't have any carrier board where the full
range of USB tests could easily be conducted.
> Thanks
> Frieder
Thank you!
Cheers
Marcel
> [1]
> https://lore.kernel.org/linux-arm-kernel/f4879eed-79a7-3a1a-8dd0-c1a6ed367f34@xxxxxxxxxx
>
> >
> > ---
> >
> > arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-
> > verdin.dtsi
> > index eafa88d980b3..197da74837ca 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
> > @@ -737,6 +737,7 @@ &usbphynop1 {
> > };
> >
> > &usbphynop2 {
> > + power-domains = <&pgc_otg2>;
> > vcc-supply = <®_vdd_3v3>;
> > };
