Message-ID: <917495af-96c3-b35c-f5f9-8e244a0d7d0b@kontron.de>
Date:   Thu, 4 Aug 2022 11:57:42 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        "dev@...henker.ch" <dev@...henker.ch>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>
Cc:     "linux-imx@....com" <linux-imx@....com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peter.chen@...nel.org" <peter.chen@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "ping.bai@....com" <ping.bai@....com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        Philippe Schenker <philippe.schenker@...adex.com>,
        Andrejs Cainikovs <andrejs.cainikovs@...adex.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "festevam@...il.com" <festevam@...il.com>,
        "jun.li@....com" <jun.li@....com>
Subject: Re: [PATCH] arm64: dts: verdin-imx8mm: add otg2 pd to usbphy

Hi Marcel,

Am 03.08.22 um 23:26 schrieb Marcel Ziswiler:
> 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.

Thanks for following up on this!

> 
> 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@...adex.com>
>>>
>>> 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@...adex.com>
>>
>> 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)?

We have both (same SoM):

Kontron BL i.MX8MM:
* USB1 connected to Micro-B Port with ID pin (full OTG)
* USB2 connected to always-on onboard Ethernet adapter

Customer Board:
* USB1 connected to USB-A Port, ID-Pin floating (host only)
* USB2 connected to always-on onboard HUB

> 
> 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.

Hm, that's news to me. So far I can't remember having problems with
designs that use the OTG port in host-only mode and leave the ID pin
unconnected.

> 
>> 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.

Yes, I think this is unrelated to the ID pin.

> 
> 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.

This is similar to the hw setup on our BL i.MX8MM board and your results
match with mine in that Li's patch *appears* to fix the issue. In fact
when you disable usbotg2 (status = "disabled") where the hub is
connected you will probably see, that detection on usbotg1 stops working
again which tells us there's something wrong with a resource that is
shared by the two ports (clock, reset, power-domain, etc.)

> 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.

I think this is due to the fact that on this hw there's no always-on
device on the other port. So whatever shared resource is needed for
autodetection to work gets disabled when all ports are autosuspended.

> 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).

So if Phillipe's patch fixes the issue for your customer board, but Li's
patch doesn't, this means that the HSIOMIX needs to be kept enabled
while suspending the port!?

This is strange because I think I tried this on my board and it still
failed as soon as the other port was not unsuspended/enabled anymore.

And I don't see how it's related to the missing ID pin connection.

> 
>> 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.

I was asking because of what I explained above. If the "other" port is
not kept out of autosuspend by some always-on device, than Li's fix
doesn't work for some reason.

>> 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...

For me it looks like this is exactly what this issue is about and what
prevents us from applying Li's patch as a global fix for the
autodetection issue.

> 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

Powered by blists - more mailing lists