Why is USB_2_OC# a GPIO on Verdin IMX8MP

matthijs · September 4, 2024, 8:58am

I’m working to configure the devicetree for our custom Verdin carrierboard (for Verdin IMX8MP) , and I noticed something weird for the USB_2_OC# verdin module pin.

Looking at the USB_1_OC# pin (the overcurrent detection pin for the first USB port, SODIMM 157), I see that it has hardware support for this function. From the Verdin iMX8M Plus V1.1 Datasheet:

However, the USB_2_OC# pin (SODIMM pin 187) does not have this function, so it can only be used as a GPIO to do overcurrent detection. At the same time, SODIMM pin 91 (IMX ball GPIO1_IO15/B5) does have the USB2_OTG_OC alt function, but is used as a regular GPIO (looking at the default pin mux function, bold in the above image).

I suspect that pin 91 / GPIO1_IO15 (named CSI_1_MCLK in the verdin family spec) might be needed for the MCLK pin function (provided by the CCM_CLKO2 alt function?) and that this is a compromise because of pin muxing limitations?

So I have a few questions:

Is pin muxing limitations the only reason why this routing was chosen? Or is there another limitation to consider?
Given that we do not need CSI MCLK and are not intending to be compatible across the entire verdin family, would there be any problems if we would connect our USB OC signal to pin 91 and configure the DT pinmux accordingly?
If we would keep the current assignment, is there an example of the devicetree configuration needed to connect the pin 187 GPIO to the usb controller as overcurrent detection? All the Toradex carrierboards I looked at (devboard, dahlia, mallow) have an USB hub on USB2, so they do OC detection on the hub downstream ports only.

ToradexAI · September 4, 2024, 8:58am

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

Answer:

Let’s address your questions one by one:

Pin muxing limitations:
Yes, pin muxing limitations are a significant reason for the current routing. The i.MX8M Plus SoC has a limited number of pins, and many of them are multiplexed to support multiple functions. The design choices for the Verdin iMX8M Plus module aim to balance the needs of various interfaces and functions. In this case, the USB_2_OC# pin (SODIMM pin 187) is configured as a GPIO because the USB2_OTG_OC function is not available on this pin. Instead, the USB2_OTG_OC function is available on SODIMM pin 91 (GPIO1_IO15), which is also used for the CSI_1_MCLK function. This decision likely reflects a compromise to support the most critical functions across the entire Verdin family.
Using pin 91 for USB OC signal:
If you do not need the CSI MCLK function and are not concerned about maintaining compatibility across the entire Verdin family, you can indeed connect your USB OC signal to pin 91 (GPIO1_IO15) and configure the device tree pinmux accordingly. This should work as long as you ensure that the pinmux settings in the device tree correctly reflect this change. You would need to modify the device tree to set the pin function to USB2_OTG_OC instead of its default GPIO function.

Device tree configuration for pin 187 GPIO as overcurrent detection:
If you decide to keep the current assignment and use pin 187 (USB_2_OC#) as a GPIO for overcurrent detection, you will need to configure the device tree to link this GPIO to the USB controller. Here is an example of how you might configure this in the device tree:

&usbotg2 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_usbotg2>;
    dr_mode = "host";
    vbus-supply = <&reg_usb_vbus>;
    status = "okay";

    oc-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>; // Assuming GPIO1_IO15 is used for OC detection
};

&iomuxc {
    pinctrl_usbotg2: usbotg2grp {
        fsl,pins = <
            MX8MP_IOMUXC

bruno.tx · September 6, 2024, 8:30pm

Hello @matthijs,

I apologize for the delay on this topic.

I will check internally about implementation details and send an update here.

Best Regards,
Bruno

matthijs · September 9, 2024, 8:52am

Thanks!

As for the DT suggestion from the bot, that seems to be totally off - Looking through the kernel documentation and sources, I can see there is an oc-gpio or oc-gpios attribute, but only for a few specific USB drivers (ohcid-da88xx, at91). Looking through the code for the imx8mp USB driver (which is a bit spread around because there is the dwc3 core, the usb core and the phy), I cannot find any code to handle GPIO overcurrent detection (but maybe there is some generic usb core code that handles this?). I also could not really find where the OC condition is handled if it occurs (drivers/usb/dwc3/dwc3-imx8mp.c sets the OC pin polarity, but does not seem to handle the actual condition, but maybe this also happens in a generic usb hci driver).

Also, the &usbotg2 node referenced does not exist in the imx8mp DT (it does seem to exist for the imx6/7 devicetrees, though).

bruno.tx · September 10, 2024, 8:18pm

Hello @matthijs,

In the Verdin iMX8M Plus V1.0 modules, pins 91 and 197 were swapped in the SoM.
This was changed in V1.1 in order to make the CSI MCLK function available.

As you do not need the CSI MCLK and you are only targeting the Verdin iMX8M Plus, you can use pin 91 as one of its alternate function without issues.
The following device tree snippet should contain the needed changes:

/* USB_2_OC# */
pinctrl_usb_2_oc_n: usb2ocngrp {
	fsl,pins =
		<MX8MP_IOMUXC_GPIO1_IO15__USB2_OC		0x1c4>;	/* SODIMM 91 */
};

&usb3_1 {
	fsl,over-current-active-low;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_usb_2_oc_n>;
};

// Remove pinctrl_gpio_hog3
&iomuxc {
	pinctrl-0 = <&pinctrl_gpio1>, <&pinctrl_gpio2>,
		    <&pinctrl_gpio3>, <&pinctrl_gpio4>,
		    <&pinctrl_gpio7>, <&pinctrl_gpio8>,
		    <&pinctrl_gpio_hog2>, <&pinctrl_gpio_hog4>,
		    <&pinctrl_hdmi_hog>;
};

It is unclear to me if such use case would be possible.
The OC signal is just a regular input, but the driver has no explicit use of GPIOs so that is why I am uncertain.
You could test this with USB1 on an existing board, by changing pinctrl_usb_1_oc_n:

&pinctrl_usb_1_oc_n {
	fsl,pins =
		<MX8MP_IOMUXC_GPIO1_IO13__GPIO1_IO13		0x1c4>;	/* SODIMM 157 */
};

If that works as intended, the device tree to use pin 187, would be similar to the one for USB_2_OC#, but with some changes to the pinctrls.

Thanks for the feedback.
The bot can help with many topics, but it has some difficulty when it comes to device tree node names.

Best Regards,
Bruno

matthijs · September 11, 2024, 4:45pm

Thanks for your response, I will followup below.

This is also my conclusion.

bruno.tx:

You could test this with USB1 on an existing board, by changing pinctrl_usb_1_oc_n:
&pinctrl_usb_1_oc_n {
	fsl,pins =
		<MX8MP_IOMUXC_GPIO1_IO13__GPIO1_IO13		0x1c4>;	/* SODIMM 157 */
};
If that works as intended, the device tree to use pin 187, would be similar to the one for USB_2_OC#, but with some changes to the pinctrls.

Your suggestion would, AFAICS, only set up the pin mux to turn the USB_1_OC pin into a GPIO. Without anything else, this would prevent the usb controller from detecting an overcurrent condition and needing some userspace code to read the pin and handle overcurrent conditions. Is that what you are suggesting?

Ok, that is what I suspected (assuming you meant 187 and not 197). But if Linux does not support a GPIO OC pin, then this seems like an unfortunate choice to me, since this now means that people should choose between CSI MCLK or USB2 OC, and also that the pin labeled “USB_2_OC” (which is an “Always compatible” pin in the Verdin family spec) is not actually usable as such?

Will this be at least documented in the verdin datasheet and carrier board design guide?

Thanks, as it looks I suspect that this might be our best route forward, but we’ll have to do a bit more testing on our current revision (if we can get a patch wire onto the SODIMM connector on pin 91 to test…).