Hi Takashi, On Tue, Dec 12, 2017 at 07:01:34AM +0000, 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 <host|device> > /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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
