RE: imx8mp USB OTG/dual-role

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Tim Harvey <tharvey@xxxxxxxxxxxxx>
> Sent: Thursday, September 1, 2022 12:38 AM
> To: Jun Li <jun.li@xxxxxxx>; Alexander Stein
> <alexander.stein@xxxxxxxxxxxxxxx>
> Cc: Jacky Bai <ping.bai@xxxxxxx>; linux-usb@xxxxxxxxxxxxxxx; Linux ARM
> Mailing List <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; Rikard Falkeborn
> <rikard.falkeborn@xxxxxxxxx>; Lucas Stach <l.stach@xxxxxxxxxxxxxx>;
> Philippe Schenker <philippe.schenker@xxxxxxxxxxx>; Felipe Balbi
> <balbi@xxxxxxxxxx>; Fabio Estevam <festevam@xxxxxxx>; Marcel Ziswiler
> <marcel.ziswiler@xxxxxxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>; Marek
> Vasut <marex@xxxxxxx>; Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx>;
> Aisheng Dong <aisheng.dong@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>;
> dl-linux-imx <linux-imx@xxxxxxx>; Pengutronix Kernel Team
> <kernel@xxxxxxxxxxxxxx>
> Subject: Re: imx8mp USB OTG/dual-role
> 
> On Tue, Aug 30, 2022 at 8:11 PM Jun Li <jun.li@xxxxxxx> wrote:
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: Jacky Bai <ping.bai@xxxxxxx>
> > > Sent: Wednesday, August 31, 2022 9:18 AM
> > > To: tharvey@xxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; Linux ARM
> > > Mailing List <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; Jun Li
> > > <jun.li@xxxxxxx>
> > > Cc: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx>; Jun Li
> > > <jun.li@xxxxxxx>; Rikard Falkeborn <rikard.falkeborn@xxxxxxxxx>;
> > > Lucas Stach <l.stach@xxxxxxxxxxxxxx>; Philippe Schenker
> > > <philippe.schenker@xxxxxxxxxxx>; Felipe Balbi <balbi@xxxxxxxxxx>;
> > > Fabio Estevam <festevam@xxxxxxx>; Marcel Ziswiler
> > > <marcel.ziswiler@xxxxxxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>;
> > > Marek Vasut <marex@xxxxxxx>; Francesco Dolcini
> > > <francesco.dolcini@xxxxxxxxxxx>; Aisheng Dong
> > > <aisheng.dong@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>;
> > > dl-linux-imx <linux-imx@xxxxxxx>; Pengutronix Kernel Team
> > > <kernel@xxxxxxxxxxxxxx>
> > > 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
> 
> Jun,
> 
> Thank you, this does appear to work as intended as dual-role. I was not aware
> of linux,extcon-usb-gpio.
> 
> And thanks also Alexander, your usb-dual-role via connector method works
> as well.
> 
> Which method is preferred, using extcon or using usb-role-switch via a
> connector as in Alexander's patch?

Looks Alexander's usb role switch is better now, for you actual
typec connector, I am not sure if a new 
compatible = "gpio-usb-c-connector"
should be added.

> 
> Additionally, where is it appropriate to put the pinctrl for the OC and ID
> pins in the usb_dwc3_0 (dwc3 core) node, the usb3_0 (dwc3 glue) node, or
> the usb3_phy0 (phy) node?

usb_dwc3_0.

Li Jun

> 
> Best Regards,
> 
> Tim




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux