All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacky Bai <ping.bai@nxp.com>
To: "tharvey@gateworks.com" <tharvey@gateworks.com>,
	"linux-usb@vger.kernel.org" <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
Date: Wed, 31 Aug 2022 01:18:17 +0000	[thread overview]
Message-ID: <DB9PR04MB8412164E22460736FB15B8D687789@DB9PR04MB8412.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAJ+vNU2bLPAta6GpDn_dGSrCnCRuBtxvLZ-g01h1jGwQuruBuA@mail.gmail.com>

Jun, as we discussed before, any conclusion on how to handle the USB OTG ID pin in RM?


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.
> 
> 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 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?
> 
> Best Regards,
> 
> Tim

WARNING: multiple messages have this Message-ID (diff)
From: Jacky Bai <ping.bai@nxp.com>
To: "tharvey@gateworks.com" <tharvey@gateworks.com>,
	"linux-usb@vger.kernel.org" <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
Date: Wed, 31 Aug 2022 01:18:17 +0000	[thread overview]
Message-ID: <DB9PR04MB8412164E22460736FB15B8D687789@DB9PR04MB8412.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAJ+vNU2bLPAta6GpDn_dGSrCnCRuBtxvLZ-g01h1jGwQuruBuA@mail.gmail.com>

Jun, as we discussed before, any conclusion on how to handle the USB OTG ID pin in RM?


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.
> 
> 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 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?
> 
> Best Regards,
> 
> Tim
_______________________________________________
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  1:18 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 [this message]
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
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=DB9PR04MB8412164E22460736FB15B8D687789@DB9PR04MB8412.eurprd04.prod.outlook.com \
    --to=ping.bai@nxp.com \
    --cc=aisheng.dong@nxp.com \
    --cc=alexander.stein@ew.tq-group.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=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.