i.MX8m USB ID support

gabriel_h · ‎03-11-2018

Dear NXP support,

I'd appreciate it if you could shed light on the USB PHY USB_ID issue.

What is the reason why the evaluation board logic implements it using a "ptn5110"? The dedicated USB signal is routed to TP only.

We were able to make our board recognize device type with a "extcon-usb-gpio", but we'd like to use the USB PHY dedicated USB ID pin.

Thank You

richard_hu · ‎06-06-2018

Hello, Gaby:

I spent several days to dive into this problem to figure out the solution.

The implementation of USB 3.0 on i.mx8m is based on DWC3 from Synopsys.

There are two key points to implement OTG role switch:

1. OTG ID detection

2. Vbus switch

There are several possible approaches to realize OTG role switch:

1. Utilize "extcon-usb-gpio.c" and use a GPIO pin as OTG ID:

When ID pin changes, extcon-usb-gpio will notify DWC3 core to switch the role of OTG.

The flaw is there is no hook to control VBUS power when ID pin detects role change.

You have to implement this part by yourself.

2. Use native OTG block:

You have to tweak drd driver(dual-role-device) under DWC3.

It requires to follow the "Programming flow for OTG in USB 3.0" to initialize OTG block.

It's lucky that an excellent developer already made it work on AM437X.

https://patchwork.kernel.org/project/LKML/list/?submitter=33442

I validate this also work on i.mx8m:

The patches i applied:

(1) usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode

(2) [v2,1/2] usb: dwc3: core.h: add some register definitions

(3) [v2,2/2] usb: dwc3: add dual role support using OTG block

(4) [v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

(5) ARM: dts: am43xx: Enable dual-role mode for USB1

(6) usb: dwc3: core: Fix broken system suspend/resume on AM437x

Then, you can add vbus control for the OTG controller based on usb2_generic_phy in DWC3.

But this solution isn't perfect. If you are interested, i'll tell you later.

BR,

Richard

Anonymous · ‎01-20-2020

Dear Richard,

The OTG driver flow requires GHWPARAMS6.SRPSupport=TRUE before proceeding as described in reference manual. But in case of iMX8M SOC, It's false !!. So Is it really possible to support OTG role switch based on OTG ID in iMX8M ?

Following steps describe overall programming flow as per reference manual:

1. During global initialization, read the GHWPARAMS6 register to see if SRP support
is enabled in the configured core. If SRP support is enabled, then proceed with the
OTG programming flow by programming USB_GCTL[PRTCAPDIR] as 2'b11. If
SRP support is not enabled, do not proceed further in the OTG programming flow.
The configured device must at least support SRP for cable connection-based
(Connector ID) role of operation.

2. Initialize the ADP controller as explained in ADP programming flow.

3. The OTG 2.0 state machine is initially in B-IDLE if IDDIG is 1, or A-IDLE if
IDDIG is 0. Enable USB_OEVTEN[ConIDStsChngEvntEn] for any change in the
Connector ID status.

4. Initialize the OTG control and configuration register to default values.

5. Read the OSTS register to find out the current status of the Connector ID
(ConIDSts). After power-on or soft reset, the ConIDSts will be valid only after the
PHY delay from IDPULL=1 to IDDIG active and any filter delay for IDDIG inside
or outside the USB 3.0 core.

6. If USB_OSTS[ConIDSts] is 1, the OTG 2.0 state machine is in B-IDLE, follow the
B-Device flow. Otherwise, if OTG 2.0 state machine is in A-IDLE, follow the A-
Device flow.

7. When there is any connector ID (IDDIG) change resulting in
USB_OEVT[ConIDStsChngEvnt], then exit the A-Device/B-Device flow. Stop the
active driver and re-initialize the OTG control and status registers.

richard_hu · ‎01-20-2020

Hello, Abhishek:

After i applied the patches, i can see the role switching happens.

----------------------------------------------------------------------------------------------------------------------------

[ 55.345882] ---------> dwc3_otg_update - DWC3_OTG_ROLE_HOST

[ 55.355893] Can't support > 32 bit dma.

[ 55.361178] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller

[ 55.366745] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 3

[ 55.378178] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220fe6c hci version 0x110 quirks 0x01010010

[ 55.386972] xhci-hcd xhci-hcd.1.auto: irq 220, io mem 0x38100000

[ 55.393708] hub 3-0:1.0: USB hub found

[ 55.397546] hub 3-0:1.0: 1 port detected

[ 55.401741] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller

[ 55.407301] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 4

[ 55.415095] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.

[ 55.423787] hub 4-0:1.0: USB hub found

[ 55.427621] hub 4-0:1.0: 1 port detected

[ 55.431802] ---------> dwc3_otg_update - dwc3_host_init succeeds

----------------------------------------------------------------------------------------------------------------------------

And i see the increment of interrupt counters:

-----------------------------------------------------------------------------------------------------------------------------

# cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

220: 8 0 0 0 GPC-PSCI 40 Edge dwc3-otg, xhci-hcd:usb3

-----------------------------------------------------------------------------------------------------------------------------

But it lacks the hook of configuring VBUS. So i implement it to get regulator "VBUS" and control it.

The host and device mode work.

I remember host mode has compatibility problem with USB 2.0 stick( i can't remember exactly the problem is USB 2.0 or USB 3.0 devices...it's already two years ago....)

Since we use type-C connector on our board and we don't want to spent too much time solving the state machine problem. Eventually, we change to use external type-C controller solution(TI TUSB320). (It still needs to tweak driver)

BR,

Richard

terry_cheng · ‎02-16-2020

Hi Richard,

Our design also use TI TUSB320 external type-C controller, and the TI TUSB320's ID pin is routed to GPIO1_IO10 to config it as USB1_OTG_ID. Should we need to port TUSB320 linux driver to do the OTG detection or use "Use native OTG block"?

Regards,

Terry Cheng

Anonymous · ‎01-21-2020

Dear Richard,

Thank you for the information. Also GHWPARAMS6.SRPSupport is TRUE. I was reading 0xC154 which is GHWPARAMS5...my bad

gabriel_h · ‎06-18-2018

Thank You Richard

I will investigate this. This can help us a lot.

igorpadykov · ‎03-11-2018

Hi Gaby

as described in sect.3.7. USB connectivity i.MX8M Hardware Developer’s Guide:
The i.MX 8MDQLQ provides two complete USB3.0 interfaces and the following
configurations (or any subset) are supported :
•Dedicated host or device using Type-A connector or Type-B connector;
•Dual role using Type-C connector

https://www.nxp.com/docs/en/user-guide/IMX8MDQLQHDG.pdf

According to usb specs available on USB.org - Welcome

ID pin is absent in USB Type-C receptacle.

The determination of host or peripheral functionality is handled differently in Type-C.

Short description can be found on web, for example:

Converting Existing USB Designs to Support Type-C Connections

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

gabriel_h · ‎03-13-2018

Hi Igor

We are looking to implement a micro USB 3.0 OTG interface. We are able to implement the USB_ID detection functionality by pinmuxing GPIO1_10 into USB_ID mode, but our desire to use a dedicated USB_ID node from the USB PHY and spare GPIO1_10 for it are GPIO functionality.

The question is only regarding the USB_ID node.

Thanks

P.S.

Please clear assumed answered flag.

igorpadykov · ‎03-13-2018

Hi Gaby

USB Type-C does not have USB_ID signal.

According to sect.11.1.1.1 Features i.MX8MDQ Reference Manual,
The USB 3.0 module includes the following features:

OTG (on-the-go) 2.0 compliant, which includes both device and host capability.
Super-speed operation is not supported when OTG is enabled.

Sect.11.1.2.6 OTG describes OTG for USB 3.0, and the programming requirements
for the USB 3.0 core in OTG mode.

https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf

Best regards
igor

gabriel_h · ‎03-15-2018

Hi Igor

Regarding

"OTG (on-the-go) 2.0 compliant, which includes both device and host capability.
Super-speed operation is not supported when OTG is enabled."

How do I handle the USB_ID node derived from the USB PHY? Lets forget USB type C and USB3.0 support, and stick to the legacy USB2.0. NXP BSP uses GPIO1_10 alternative USB_ID signal instead of the didecated PHY signal. Why?

Thank You

igorpadykov · ‎03-15-2018

Hi Gaby

NXP BSP software supports MCIMX8M-EVK official NXP reference design - that is

USB type C. Other hardware alternatives, not present in i.MX8 reference design,

are not supported in BSP. You can add such software support yourself or apply

for help to NXP Professional Services:

NXP Professional Services|NXP

Best regards
igor

gabriel_h · ‎03-20-2018

Hi Igor

I see there is no answer. Can you please clear the "assumed answeres" flag from this topic?

Thank You

gabriel_h · ‎03-15-2018

Hello Igor

I understand that but why you're avoiding to answer the direct question regarding the usage of GPIO1_10 instead of the dedicated USB_ID pin derived from the PHY? If the dedicated USB1_ID ball usage is not supported, that's ok too.

Thank You