RE: imx8mp USB OTG/dual-role

[Alexander Stein <alexander.stein@ew.tq-group.com>]

Hi everybody,

Am Mittwoch, 31. August 2022, 05:11:38 CEST schrieb Jun Li:
> Hi,
> 
> 
> > -----Original Message-----
> > From: Jacky Bai <ping.bai@nxp.com>
> > Sent: Wednesday, August 31, 2022 9:18 AM
> > To: tharvey@gateworks.com; linux-usb@vger.kernel.org; Linux ARM Mailing
> > List <linux-arm-kernel@lists.infradead.org>; Jun Li <jun.li@nxp.com>
> > Cc: Alexander Stein <alexander.stein@ew.tq-group.com>; Jun Li
> > <jun.li@nxp.com>; Rikard Falkeborn <rikard.falkeborn@gmail.com>; Lucas
> > Stach <l.stach@pengutronix.de>; Philippe Schenker
> > <philippe.schenker@toradex.com>; Felipe Balbi <balbi@kernel.org>; Fabio
> > Estevam <festevam@denx.de>; Marcel Ziswiler
> > <marcel.ziswiler@toradex.com>;
> > Shawn Guo <shawnguo@kernel.org>; Marek Vasut <marex@denx.de>; Francesco
> > Dolcini <francesco.dolcini@toradex.com>; Aisheng Dong
> > <aisheng.dong@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>;
> > dl-linux-imx <linux-imx@nxp.com>; Pengutronix Kernel Team
> > <kernel@pengutronix.de>
> > Subject: RE: imx8mp USB OTG/dual-role
> > 
> > Jun, as we discussed before, any conclusion on how to handle the USB OTG
> > ID pin in RM?
> 
> 
> The NXP datasheet for iMX8MP already changed the ID pin name to be with
> _DNU
 suffix, RM may be updated in next version.
> If legacy ID is going to be used, any normal GPIO function can be selected
> for it, extcon is well supported in dwc3 controller driver. 
> 
> More comments for Tim, see below...
> 
> 
> > 
> > 
> > BR
> > Jacky Bai
> > 
> > 
> > > Subject: imx8mp USB OTG/dual-role
> > >
> > >
> > >
> > > Greetings,
> > >
> > >
> > >
> > > I have an imx8mp board (imx8mp-venice-gw74xx) which has a DWC3 USB
> > > host controller using imx8mp PHY
> > > (drivers/phy/freescale/phy-fsl-imx8mq-usb.c fsl,imx8mp-usb-phy) and
> > > DWC3 host controller core (drivers/usb/dwc3/core.c snps,dwc3) with
> > > imx8mp glue (drivers/usb/dwc3/dwc3-imx8mp.c fsl,imx8mp-dwc3).
> > >
> > >
> > >
> > > One of the 2x USB 3.0 hosts is connected to a USB Type C connector
> > > using a
> > > TPS25821 USB power switch and config controller which handles the CC
> > > pins on and VBUS enable as well as drives the mux sel pin of a
> > > USB3 mux to route the USB SS pairs to the appropriate half of the Type
> > > C connector. This device has no I2C or other management bus - only
> > > VBUS, FAULT#, SINK#, and POL# outputs based on CC pins.
> > >
> > >
> > >
> > > I'm not clear how to describe this in the device-tree in order for it
> > > to function as a dual-role controller for host vs device mode.
> > >
> > >
> > >
> > > The TPS25821 has a FAULT# signal that routes to IMX8MP GPIO1_IO13
> > > pinmuxed as MX8MP_IOMUXC_GPIO1_IO13__USB1_OTG_OC and a SINK# signal
> > > that routes to IMX8MP GPIO1_IO10 pinmuxed as
> > > MX8MP_IOMUXC_GPIO1_IO10__USB1_OTG_ID. Additionally the VBUS output of
> > > the TPS25821 also connected to the TypeC VBUS pin routes to the IMX8MP
> > > USB1_VBUS pin.
> 
> 
> So TPS25821 does not need a driver.
> 
> 
> > >
> > >
> > > I've noticed there are currently only 2 other IMX8MP boards in Linux
> > > mainline that specify dr_mode="otg"; the DH electronics i.MX8M Plus
> > > DHCOM SOM (imx8mp-dhcom-som.dtsi), and the Toradex i.MX8M Plus Verdin
> > > SOM (imx8mp-verdin.dtsi). I'm not clear how these are hooked up or if
> > > USB dual-role work on these currently. I did notice that
> 
> 
> NXP iMX8MP EVK has not enabled type-C port due to the SS orientation
> switch binding is still in discussion, but you don't need a SW control
> in your case so you are okay here.
> 
> 
> > > imx8mp-verdin.dtsi looks like it does not enable the phy or core via
> > > status prop and uses invalid 'over-current-active-low' and
> > 
> > 'disable-over-current' dt props.
> > 
> > >
> > >
> > > I am currently using the following with imx8mp-venice-gw74xx:
> > >
> > >
> > >
> > > /* USB1 - Type C front panel */
> > > &usb3_phy0 {
> > > 
> > >         status = "okay";
> > > 
> > > };
> > >
> > >
> > >
> > > /* USB1 dwc3 glue */
> > > &usb3_0 {
> > > 
> > >         fsl,over-current-active-low;
> > >         status = "okay";
> > > 
> > > };
> > >
> > >
> > >
> > > /* USB1 dwc3 core */
> > > &usb_dwc3_0 {
> > > 
> > >         pinctrl-names = "default";
> > >         pinctrl-0 = <&pinctrl_usb1>;
> > >         dr_mode = "otg";
> > > 
> > > };
> > >
> > >
> > >
> > > &iomuxc {
> > > 
> > >         pinctrl_usb1: usb1grp {
> > >         
> > >                 fsl,pins = <
> > >
> > >
> > >
> > > MX8MP_IOMUXC_GPIO1_IO13__USB1_OTG_OC    0x140
> > >
> > >
> > >
> > > MX8MP_IOMUXC_GPIO1_IO10__USB1_OTG_ID    0x140
> > > 
> > >                 >;
> > >         
> > >         };
> > > 
> > > };
> > >
> > >
> > >
> > > And currently v6.0-rc2 enumerates the host controller even without a
> > > Type-C to host cable attached which tells me that OTG_ID isn't doing
> > > its job. I vaguely recall some confusing statements on the IMX
> > > community forum that these pins might not even be used on the IMX8MP.
> > >
> > >
> > >
> > > How should I be describing the device-tree for this scenario in order
> > > to get dual-role behavior?
> 
> 
> Could this dts work for you?
> 
> /* Config the "ID" pin iomux to be GPIO */
> 
> pinctrl_usb1: usb1grp {
>                  fsl,pins = <
>                       MX8MP_IOMUXC_GPIO1_IO13__USB1_OTG_OC    0x140
>                       MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10    0x140
> 
>           >;
> 
>  };
> 
>  extcon_usb: extcon_iddig {
>                  compatible = "linux,extcon-usb-gpio";                      
>                                                                            
>                               
 id-gpio = <&gpio1 10 GPIO_ACTIVE_HIGH>;
>  };
> 
>  &usb_dwc3_0 {
>          pinctrl-names = "default";
>          pinctrl-0 = <&pinctrl_usb1>;
> 		 extcon = <&extcon_usb>
>          dr_mode = "otg";
>  };
> 
> Li Jun

I just send a patch for USB DR support on our TQMa8MPxL+MBa8MPxL platform, 
added Tim Harvey and Li Jun on CC. This is quite similar but uses usb-role-
switch instead of extcon.

Best regards,
Alexander




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel