On Fri, Apr 29, 2016 at 04:32:22PM +0300, Heikki Krogerus wrote: > 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. Yes it does, thanks for the explaination. I've applied this patch now. thanks, greg k-h -- 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
