Re: Dual-role behavior with USB-C?
On Wed, Dec 13, 2017 at 02:37:14PM +0200, Heikki Krogerus wrote: > Hi guys, > > > > I think the USB-OTG PHY is part of i.MX6UL SoC? > > > > Yes, but it is just USB PHY, not PD PHY. You need external pure CC-logic > > chip (like PTN5150), or Type-C PD chip (like PTN5110) to support CC > > or PD event. > > Oh cool, PTP5150 seems to function autonomously if needed! So it would > have worked even without driver support initially. > Yes, if you configure PTN5150 as DRP, the ID pin for SoC will change accordingly. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
Hello. Now I am waiting for my USB-C breakout board to just re-using it for connecting to conventional micr-A/B receptacle. BTW, Looking into schematic, another board HiKey960 with USB-C receptacle seems to have USB-C controller in its circuit. >OK, from those schematics we can clearly see that the CC lines are >really connected to the USB_OTG_ID signal. I guess the idea has been >to attempt to get the USB_OTG_ID signal pulled down to ground when the >partner is UFP (device) and has the CC line connected to the ground >with the resistor Rd. That should put the board into host mode, but >I guess it's not working. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
Hi guys, On Wed, Dec 13, 2017 at 10:43:50AM +0800, Peter Chen wrote: > On Wed, Dec 13, 2017 at 01:17:23AM +, Takashi Matsuzawa wrote: > > Hello. > > > > >If you have a Type-C connector on your board, then you also should > > >have a USB Type-C PHY that takes care of CC logic. The host-to-device > > >relationship is determined using the Configuration Channel (CC) that > > >goes through the USB Type-C cable. Note that CC is not the same as ID! > > > > I am playing with i.MX6 pico board, which has USB-OTG receptacle with USB-C > > physical shape. > > http://download.wandboard.org/hobbitboard-imx6ul/documentation/pico-imx6ul-emmc-hobbit-reva1-hardware-manual-20160328.pdf OK, from those schematics we can clearly see that the CC lines are really connected to the USB_OTG_ID signal. I guess the idea has been to attempt to get the USB_OTG_ID signal pulled down to ground when the partner is UFP (device) and has the CC line connected to the ground with the resistor Rd. That should put the board into host mode, but I guess it's not working. With Type-C to Type-C connections, in case the partner is DFP (host) or DRP (dual-role), that configuration will just confuse the partner. The partner will now see that the CC is pulled high and probable think that your board is also DFP (host), i.e. your board and the partner connected to it, both think they need to be in device mode. I don't think there are actually any guarantees that connecting the CC lines to the ID input on the board will work in any scenario. There really should be a CC-logic chip if dual-role support was needed. For device mode only, simply connecting the CC lines to the ground from the connector would have been enough. > > I think the USB-OTG PHY is part of i.MX6UL SoC? > > Yes, but it is just USB PHY, not PD PHY. You need external pure CC-logic > chip (like PTN5150), or Type-C PD chip (like PTN5110) to support CC > or PD event. Oh cool, PTP5150 seems to function autonomously if needed! So it would have worked even without driver support initially. Cheers, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
On Wed, Dec 13, 2017 at 01:17:23AM +, Takashi Matsuzawa wrote: > Hello. > > >If you have a Type-C connector on your board, then you also should > >have a USB Type-C PHY that takes care of CC logic. The host-to-device > >relationship is determined using the Configuration Channel (CC) that > >goes through the USB Type-C cable. Note that CC is not the same as ID! > > I am playing with i.MX6 pico board, which has USB-OTG receptacle with USB-C > physical shape. > http://download.wandboard.org/hobbitboard-imx6ul/documentation/pico-imx6ul-emmc-hobbit-reva1-hardware-manual-20160328.pdf > > I think the USB-OTG PHY is part of i.MX6UL SoC? Yes, but it is just USB PHY, not PD PHY. You need external pure CC-logic chip (like PTN5150), or Type-C PD chip (like PTN5110) to support CC or PD event. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
On Tue, Dec 12, 2017 at 07:01:34AM +, Takashi Matsuzawa wrote: > Hello. > Thank you very much for your comment. > > > Since USB OTG FSM has not been accepted by industry during last ten years, > > we decide > > to give up maintaining OTG FSM at Linux kernel. For role switch use case, > > please use > > /sys/../role instead, see below commit for detail: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb- > next&id=a932a8041ff9941a244619555f1c75ecf299f662 > > I am still learning so just point me to existing memo / notes which I should > look into, before go furher. > > 1) HNP aware devices > > That means it does not work (or will not work) with HNP-aware device anymore, > or I can expect that it still works when I enable CONFIG_USB_OTG and > CONFIG_USB_OTG_FSM? Afaik, there is no fully HNP aware device, if you know any, please tell me. > > 2) role I/F. > > As for the role I/F. > I tried like below and confirmed that the role value changes gadget <-> host. > And new bus is added can see on lsusb output, when I change the role from > gadget to host. > > echo host > /sys/bus/platform/devices/ci_hdrc.0/role > > However, I am still confused since it does not more. > Say, I have two boards A and B connected with C-C cable. > And by command like above, I set A host role and B gadget role, and also load > mass storage driver on B. > > I expect to see on B is enumerated as mass storage device attached to the > newly added bus on A, but I cannot see it on lsusb output. > Not sure I am missing / skipping steps. Maybe vbus is not there or the gadget does not pull DP up correctly. > > 3) USB-C lines > > As for USB-C receptacle on my board, I can see the following. In my case I > am just trying to use it in place of old one (micro-A/B receptacle), but I > wonder if I further need kernel configuration specific to TYPEC. > For your hardware, I don't think you need. > board cable > > USB_OTG_DP - Dp1/Dp2 > USB_OTG_DN - Dn1/Dn2 > USB_OTG_ID - CC1/CC2 > You said the role has switched successfully, it is not related Type-C issue, it is the controller driver issue, please focus on if vbus is there and if the gadget pull DP up. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
Hello. >If you have a Type-C connector on your board, then you also should >have a USB Type-C PHY that takes care of CC logic. The host-to-device >relationship is determined using the Configuration Channel (CC) that >goes through the USB Type-C cable. Note that CC is not the same as ID! I am playing with i.MX6 pico board, which has USB-OTG receptacle with USB-C physical shape. http://download.wandboard.org/hobbitboard-imx6ul/documentation/pico-imx6ul-emmc-hobbit-reva1-hardware-manual-20160328.pdf I think the USB-OTG PHY is part of i.MX6UL SoC? I am also trying different cable configurations (e.g. C-A(f)+A(m)-C) to see if behavior changes. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
Hi Takashi, On Tue, Dec 12, 2017 at 07:01:34AM +, Takashi Matsuzawa wrote: > Hello. > Thank you very much for your comment. > > > Since USB OTG FSM has not been accepted by industry during last ten years, > > we decide > > to give up maintaining OTG FSM at Linux kernel. For role switch use case, > > please use > > /sys/../role instead, see below commit for detail: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb- > next&id=a932a8041ff9941a244619555f1c75ecf299f662 > > I am still learning so just point me to existing memo? / notes which I should > look into, before go furher. > > 1) HNP aware devices > > That means it does not work (or will not work) with HNP-aware device anymore, > or I can expect that it still works when I enable CONFIG_USB_OTG and > CONFIG_USB_OTG_FSM? > > 2) role I/F. > > As for the role I/F. > I tried like below and confirmed that the role value changes gadget <-> host.? > And new bus is added can see on lsusb output, when I change the role from > gadget to host. > > echo host > /sys/bus/platform/devices/ci_hdrc.0/role > > However, I am still confused since it does not more. > Say, I have two boards A and B connected with C-C cable. > And by command like above, I set A host role and B gadget role, and also load > mass storage driver on B. > > I expect to see on B is enumerated as mass storage device attached to the > newly added bus on A, but I cannot see it on lsusb output. > Not sure I am missing / skipping steps. > > 3) USB-C lines > > As for USB-C receptacle on my board, I can see the following.? In my case I am > just trying to use it in place of old one (micro-A/B receptacle), but I wonder > if I further need kernel configuration specific to TYPEC. > > board? ? cable > ? ? > USB_OTG_DP - Dp1/Dp2 > USB_OTG_DN - Dn1/Dn2 > USB_OTG_ID - CC1/CC2 If you have a Type-C connector on your board, then you also should have a USB Type-C PHY that takes care of CC logic. The host-to-device relationship is determined using the Configuration Channel (CC) that goes through the USB Type-C cable. Note that CC is not the same as ID! USB Type-C and USB Power Delivery follow their own state machines that are completely separate from OTG FSM. USB OTG is in practice not compatible with USB Type-C, and we should not even talk about OTG with USB Type-C. In mainline, the USB Type-C and USB Power Delivery state machines are implemented in drivers/usb/typec/tcpm.c . It is also possible to use stand-alone USB Type-C or USB Power Delivery controllers that handle the state machines inside their firmware, however I don't think you have those on your board, as I would expect everything to just work without any software control needed if you had. But in any case, the Type-C PHY on your board will do at least two basic things: 1) Determine the initial role: DFP (Host) or UFP (device). 2) Resolve the cable orientation: normal or upside-down. After that, depending on the components you have on the board, you will possible need to configure a mux that routes the correct data pairs to the USB controller (depending on the orientation of the cable), and then you need to configure the role of the controller (there is no support for this in mainline for the Chipidea USB controller). On top of those things, if you are acting as the host, you will also have somekind of a regulator for the VBUS of course, but also for the VCONN. So it is likely that we are missing driver support for some of the components on your board. Can you share some details about your the board you are using? After all the needed components are supported, then the initial role will be determined automatically, and in case of the Type-C to Type-C connections (where both partners are dual-role) you can also use the USB Type-C Connector Class ABI to request role swapping: % echo > /sys/class/typec/port0/data_role Cheers, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dual-role behavior with USB-C?
Hello. Thank you very much for your comment. > Since USB OTG FSM has not been accepted by industry during last ten years, we > decide > to give up maintaining OTG FSM at Linux kernel. For role switch use case, > please use > /sys/../role instead, see below commit for detail: > > > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb- next&id=a932a8041ff9941a244619555f1c75ecf299f662 I am still learning so just point me to existing memo / notes which I should look into, before go furher. 1) HNP aware devices That means it does not work (or will not work) with HNP-aware device anymore, or I can expect that it still works when I enable CONFIG_USB_OTG and CONFIG_USB_OTG_FSM? 2) role I/F. As for the role I/F. I tried like below and confirmed that the role value changes gadget <-> host. And new bus is added can see on lsusb output, when I change the role from gadget to host. echo host > /sys/bus/platform/devices/ci_hdrc.0/role However, I am still confused since it does not more. Say, I have two boards A and B connected with C-C cable. And by command like above, I set A host role and B gadget role, and also load mass storage driver on B. I expect to see on B is enumerated as mass storage device attached to the newly added bus on A, but I cannot see it on lsusb output. Not sure I am missing / skipping steps. 3) USB-C lines As for USB-C receptacle on my board, I can see the following. In my case I am just trying to use it in place of old one (micro-A/B receptacle), but I wonder if I further need kernel configuration specific to TYPEC. board cable USB_OTG_DP - Dp1/Dp2 USB_OTG_DN - Dn1/Dn2 USB_OTG_ID - CC1/CC2 Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Dual-role behavior with USB-C?
> > Hello. > > Just in case if you already have pointer or experience with this, any > suggestion is > highly appreciated. > > Some of the recent i.MX boards has USB-C socket for USB-OTG port, and I wonder > how I can try the following steps (Dual-role behavior testing) with USB-C > sockets. > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel. > org%2Fdoc%2FDocumentation%2Fusb%2Fchipidea.txt&data=02%7C01%7Cpeter.c > hen%40nxp.com%7Cc2f36f5be257466d78b608d53e8e2d57%7C686ea1d3bc2b4c6f > a92cd99c5c301635%7C0%7C0%7C636483702729739829&sdata=6slKCmxytnXl% > 2BP4J73NlXm6CPtVSq3GGsXqSXO%2Bn5fY%3D&reserved=0 > > The steps involves micro-A and micro-B plugs, but for my board only USB-C plug > can be inserted. > (I tried C-C cable to connect two boards, but nothing happened - both of the > boards > stayed in gadget role, neither becoming the host). > > I have confirmed my board can act as host (can detect a device attached and > shown > on lsusb output) or gadget (by loading mass storage driver, it can be shown as > external disk from my PC). > > (Well, however these behaviors are not stable yet with my local build image.) > > Anyway: > > - How can I conduct test steps outlined in chipidea.txt memo. Since USB OTG FSM has not been accepted by industry during last ten years, we decide to give up maintaining OTG FSM at Linux kernel. For role switch use case, please use /sys/../role instead, see below commit for detail: https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb-next&id=a932a8041ff9941a244619555f1c75ecf299f662 Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dual-role behavior with USB-C?
Hello. Just in case if you already have pointer or experience with this, any suggestion is highly appreciated. Some of the recent i.MX boards has USB-C socket for USB-OTG port, and I wonder how I can try the following steps (Dual-role behavior testing) with USB-C sockets. https://www.kernel.org/doc/Documentation/usb/chipidea.txt The steps involves micro-A and micro-B plugs, but for my board only USB-C plug can be inserted. (I tried C-C cable to connect two boards, but nothing happened - both of the boards stayed in gadget role, neither becoming the host). I have confirmed my board can act as host (can detect a device attached and shown on lsusb output) or gadget (by loading mass storage driver, it can be shown as external disk from my PC). (Well, however these behaviors are not stable yet with my local build image.) Anyway: - How can I conduct test steps outlined in chipidea.txt memo. How can I interpret it with UCB-C ports (may be using appropriate cables) or is there alternative test steps? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
