From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B6C3ECAAD1 for ; Tue, 30 Aug 2022 17:54:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=6BGh9wml3M6n366X8iUZZZTNFx6rjq7hCLXTtU1Q02I=; b=EcFF1D9pDROhsN 6u4hqEIIMt0r1wGGdXhwRm7VOykZlBi0UBBibimN668zvJgzAB1goJ+F+fNc8zRgwUQXTTxFf2Hau qcAnhO29Np3f1083erEYER4BPQgXMUBrqiLUt8rJa8bbRyEpDnpaYHbk4868Y1YOyohiX54L03BQ/ lwJ/rQs7sa5unEymLUcyybOWDC5JWylZDAkISNlgC4PlBBAlGHLIBekF3oKkoVbBfpdgQgaHNVyYg vd/mB1a2Mj+uGxUMel8sVnA53iNKhrLb2t7GW2nnFmUhxUVpDgJb4iOjbsjncLPrS/8lctH9hRgNl CEcDrFhfVcqH3npINijg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oT5Qh-001052-GF; Tue, 30 Aug 2022 17:53:39 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oT5Qe-001032-D0 for linux-arm-kernel@lists.infradead.org; Tue, 30 Aug 2022 17:53:37 +0000 Received: by mail-pj1-x102c.google.com with SMTP id j9-20020a17090a3e0900b001fd9568b117so8936307pjc.3 for ; Tue, 30 Aug 2022 10:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc; bh=kx3QMApec5L1A/kJjq+NRNfAaAm3kYhF5kN0XuMgkn4=; b=X8ZCuWBv89RQu/4ryrySIIp8KEnqAX7pc8bX7DIeUFi1scKtiGmOsFYmx7H0ZLJpnO E1bF9PWP4D24pOcqEe09ZJWQAl/DE+xfjsQK/0WZiw+XmK+Zu5FWzSorguXNQkjqEeC1 JMqWQyXTgOMw6J1X0RLHre4954g3h1/FGHtRi3mULd/xVSvfUzQE7lnqjk8d9aEXWs7v 2tJNRzVkWkjtoHVBlGrzkg40sf16hiHH1A145hyFxX03wKw5kP2BkB+wZDhs5ruVAhEn yETPdl/GQ5Gpv7jGLAlph+BYRX14YjZ+HV/vu1ysdXhzPxnN+3eOWT8QvfTXexMDA1+s t7xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=kx3QMApec5L1A/kJjq+NRNfAaAm3kYhF5kN0XuMgkn4=; b=N3A7R8+ZkYgzit1I5Z3pEpf8fiHlxQezDOApTZReUiGTXI9afBuKFKVqndCXBsO28b SJu0RePdeeCgKBNdeNjm5YZihws/AtTvzgHIOD2wiMdHXgnYYKxxcpBeYkIsvA2BtzvM y6zcR7f9He51pS7j5L81chPtTMgu4mVLUGuDNYQxLA+0Yh/783J+JKP/78xvakSbbBWj YOD8W63x+18hA80AKiw08zfRh2N+doHiX7SOc8wvRjV7DekvZmg7hOJ5cyYxChdC0J8I /elVCJcRQ5qONH1VUO3tOBndxlUXJ/7b+fLuqFFXPaJkUjCIKeGG1tMfTq6y5SQMiF71 IF7g== X-Gm-Message-State: ACgBeo1/KzB2SCEmxz48ak/wUhXMnPKzPKQDNUclR7MiYdAwzMU9aZOE ITtanPUGH3lt+2efaNKW9YvJZNDNG5MliK25zF4tbw== X-Google-Smtp-Source: AA6agR4LMxeVzSbHbrBCfoW9nkhiokhP34fYeiwTkSjSnnHyPMkVZmOKyBSU6gWtfJHV/5B/ltB3B957xplg7fRue9A= X-Received: by 2002:a17:902:9887:b0:172:7090:6485 with SMTP id s7-20020a170902988700b0017270906485mr22096257plp.63.1661882014306; Tue, 30 Aug 2022 10:53:34 -0700 (PDT) MIME-Version: 1.0 From: Tim Harvey Date: Tue, 30 Aug 2022 10:53:23 -0700 Message-ID: Subject: imx8mp USB OTG/dual-role To: linux-usb@vger.kernel.org, Linux ARM Mailing List Cc: Alexander Stein , Li Jun , Rikard Falkeborn , Lucas Stach , Philippe Schenker , Felipe Balbi , Fabio Estevam , Marcel Ziswiler , Shawn Guo , Marek Vasut , Francesco Dolcini , Jacky Bai , Dong Aisheng , Sascha Hauer , NXP Linux Team , Pengutronix Kernel Team X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220830_105336_646843_2C3C0C0D X-CRM114-Status: GOOD ( 12.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B351DECAAD1 for ; Tue, 30 Aug 2022 17:56:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231284AbiH3R4J (ORCPT ); Tue, 30 Aug 2022 13:56:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231181AbiH3Rzl (ORCPT ); Tue, 30 Aug 2022 13:55:41 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33022876A9 for ; Tue, 30 Aug 2022 10:53:44 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id h11-20020a17090a470b00b001fbc5ba5224so12587363pjg.2 for ; Tue, 30 Aug 2022 10:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc; bh=kx3QMApec5L1A/kJjq+NRNfAaAm3kYhF5kN0XuMgkn4=; b=X8ZCuWBv89RQu/4ryrySIIp8KEnqAX7pc8bX7DIeUFi1scKtiGmOsFYmx7H0ZLJpnO E1bF9PWP4D24pOcqEe09ZJWQAl/DE+xfjsQK/0WZiw+XmK+Zu5FWzSorguXNQkjqEeC1 JMqWQyXTgOMw6J1X0RLHre4954g3h1/FGHtRi3mULd/xVSvfUzQE7lnqjk8d9aEXWs7v 2tJNRzVkWkjtoHVBlGrzkg40sf16hiHH1A145hyFxX03wKw5kP2BkB+wZDhs5ruVAhEn yETPdl/GQ5Gpv7jGLAlph+BYRX14YjZ+HV/vu1ysdXhzPxnN+3eOWT8QvfTXexMDA1+s t7xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=kx3QMApec5L1A/kJjq+NRNfAaAm3kYhF5kN0XuMgkn4=; b=s3ADMEOIYXl9VHN0yBKNVULMf2r3zc6AWReM8VqzBFIhSb4t46xEvVK9dhot80IyiJ aXibpksmArFi2sh5yqN9HlEhMbX1rQr+odTHJIWGe36663sGdrUW6knzuVAcI8QKYsTg NlEjeF+1VuLk1ei8dYt5CAYOm7TvUmkY9Rkt5nCQPbMccAUdSmQxQNKoptokFoT6FlV6 Is7YKuUxhCijzm8CKlwz0Y/z4vjcI6BtNRMm83L8L7MdxZeDnSZAY78ZDWg4PKIdiR1t 5bmu4aH3vQ/VgFTV2WY/+p+SPqRlGYQvmsBTAgW9mg7/u8GgK9JdZmtRWV/nkOUWUcS1 jOqA== X-Gm-Message-State: ACgBeo03WVqY1Ud0IAhpFmZY97HMapZPWDt0Zg5QktUbKVA7o6Xey0/p z4Qun/6O3/nQKZKewTvBhzQVrSGB5hgiITVs6/PI1IUM9bJyCzv1 X-Google-Smtp-Source: AA6agR4LMxeVzSbHbrBCfoW9nkhiokhP34fYeiwTkSjSnnHyPMkVZmOKyBSU6gWtfJHV/5B/ltB3B957xplg7fRue9A= X-Received: by 2002:a17:902:9887:b0:172:7090:6485 with SMTP id s7-20020a170902988700b0017270906485mr22096257plp.63.1661882014306; Tue, 30 Aug 2022 10:53:34 -0700 (PDT) MIME-Version: 1.0 From: Tim Harvey Date: Tue, 30 Aug 2022 10:53:23 -0700 Message-ID: Subject: imx8mp USB OTG/dual-role To: linux-usb@vger.kernel.org, Linux ARM Mailing List Cc: Alexander Stein , Li Jun , Rikard Falkeborn , Lucas Stach , Philippe Schenker , Felipe Balbi , Fabio Estevam , Marcel Ziswiler , Shawn Guo , Marek Vasut , Francesco Dolcini , Jacky Bai , Dong Aisheng , Sascha Hauer , NXP Linux Team , Pengutronix Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org 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