All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: "tharvey@gateworks.com" <tharvey@gateworks.com>, Jun Li <jun.li@nxp.com>
Cc: Jacky Bai <ping.bai@nxp.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	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
Date: Wed, 31 Aug 2022 09:48:34 +0200	[thread overview]
Message-ID: <1907644.PYKUYFuaPT@steina-w> (raw)
In-Reply-To: <PA4PR04MB9640F578AEF2558BA3F08F8889789@PA4PR04MB9640.eurprd04.prod.outlook.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




WARNING: multiple messages have this Message-ID (diff)
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: "tharvey@gateworks.com" <tharvey@gateworks.com>, Jun Li <jun.li@nxp.com>
Cc: Jacky Bai <ping.bai@nxp.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	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
Date: Wed, 31 Aug 2022 09:48:34 +0200	[thread overview]
Message-ID: <1907644.PYKUYFuaPT@steina-w> (raw)
In-Reply-To: <PA4PR04MB9640F578AEF2558BA3F08F8889789@PA4PR04MB9640.eurprd04.prod.outlook.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

  reply	other threads:[~2022-08-31  7:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 17:53 imx8mp USB OTG/dual-role Tim Harvey
2022-08-30 17:53 ` Tim Harvey
2022-08-31  1:18 ` Jacky Bai
2022-08-31  1:18   ` Jacky Bai
2022-08-31  3:11   ` Jun Li
2022-08-31  3:11     ` Jun Li
2022-08-31  7:48     ` Alexander Stein [this message]
2022-08-31  7:48       ` Alexander Stein
2022-08-31 16:38     ` Tim Harvey
2022-08-31 16:38       ` Tim Harvey
2022-09-01  5:06       ` Ahmad Fatoum
2022-09-01  5:06         ` Ahmad Fatoum
2022-09-06  2:03       ` Jun Li
2022-09-06  2:03         ` Jun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1907644.PYKUYFuaPT@steina-w \
    --to=alexander.stein@ew.tq-group.com \
    --cc=aisheng.dong@nxp.com \
    --cc=balbi@kernel.org \
    --cc=festevam@denx.de \
    --cc=francesco.dolcini@toradex.com \
    --cc=jun.li@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=marex@denx.de \
    --cc=philippe.schenker@toradex.com \
    --cc=ping.bai@nxp.com \
    --cc=rikard.falkeborn@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=tharvey@gateworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.