Hi Greg, On Thu, Apr 28, 2016 at 12:53:24PM -0700, Greg Kroah-Hartman wrote: > On Thu, Apr 21, 2016 at 03:43:40PM +0300, Heikki Krogerus wrote: > > USB Type-C Connector System Software Interface (UCSI) is > > specification that defines the registers and data structures > > that can be used to control USB Type-C ports on a system. > > UCSI is used on several Intel Broxton SoC based platforms. > > Things that UCSI can be used to control include at least USB > > Data Role swapping, Power Role swapping and controlling of > > Alternate Modes on top of providing general details about > > the port and the partners that are attached to it. > > > > The initial purpose of the UCSI driver is to make sure USB > > is in host mode on desktop and server systems that are USB > > dual role capable, and provide UCSI interface. > > > > The goal is to integrate the driver later to an USB Type-C > > framework for Linux kernel, and at the same time add support > > for more extensive USB Type-C port control that UCSI offers, > > for example data role swapping, power role swapping, > > Alternate Mode control etc. > > My big worry here is this second thing "integrate into a USB Type-C > framework". We don't have one upstream, but we have lots of different > ones floating around in different products at the moment, all of them > seeming to only do one-off things (i.e. only work for one specific > device.) How is this going to be integrated into such a future scheme? > > Are you working on this larger task? Or working with others who are? > Any ideas of when this will happen? This is my plan: With UCSI and also most of the complex USB PD/Type-C controllers (for example TI's TPS65982) that take care of the USB PD stack, handle all the muxes autonomously etc., the only thing I see we need to do, and actually can do, is to provide userspace control over the data role swapping, power role swapping and possibly alternate mode control. And for that I'm going to propose the USB Type-C class. The second case is where we have just USB Type-C/PD PHY and any USB PD communication needs to be handled in OS, so we will need USB PD stack for this case, I guess starting from protocol layer followed by policy engines and so on. We have guys working on that and they have already something working, and I know many other companies have their own implementations for the USB PD stack. But the PD stack will in any case be inside the kernel, and with USB Type-C connectors the things that the userspace needs to know and control are the same as with UCSI, so the Type-C class can take care of that part even in this case. So the USB Type-C/PD PHY drivers will just utilize the USB PD stack witch is inside the kernel, and still present the ports to the userspace with the help of the class. The class is also enough for USB Type-C PHYs that don't support USB PD, and for example for some of our platforms that do have USB PD transceiver, but have no use for USB PD (no AltModes, no use for the higher currents and voltages) so we just use it as USB Type-C PHY (USB PD disabled). There is actually a third case. The USB PD controllers that handle the USB PD stack "partially". Those worry me, but I'm not going to go into those now. Even with them the userspace should in any case get the same stuff about the ports with the help of the class. So I think we should move forward with this in steps. I'm going to propose that the first step is the USB Type-C class (or if not that, some other userspace interface) so we have the ABI more or less the way it's going to be forever from the beginning, so to prevent people from making ad-hoc solutions for example for the data role swapping. I'm not going to give any guesses about when USB PD stack could be available, but I'm hoping we can bring it into kernel in parts, starting from the protocol layer. We are going to need to handle the Alternate Modes with AltMode specific drivers. There is no way to avoid that. Felipe's idea was that we make a bus for the Alternate Modes which sounds more the reasonable to me. So that could be an example of an independent part after the protocol layer. As the final step we can add the policy engines, the Device Policy and System Policy. The policy engines will bring the full USB PD support to kernel, but for example the Alternate Modes should be possible to make available even before them. I'm attempting to prepare a new version of the USB Type-C class proposal within the next few weeks. I hope this plan makes some sense. Sorry about the too long email. Thanks, -- 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
