Hi, On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote: > On 2017-03-03 04:13, Guenter Roeck wrote: > > > On 03/02/2017 07:22 AM, Mats Karrman wrote: > > > .... > > > Looking forward, one thing I have run into is how to connect the typec driver with a > > > driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification > > > includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in the > > > Attention message. These signals are needed by the DisplayPort driver to know when to > > > start negotiation etc. > > > Have you got any thoughts on how to standardize such interfaces? My idea was to have something like the altmode "bus" at one point. We create a device for every alternate mode registered in typec class, so the alternate modes registered for the ports and partners would simply be attached to the altmode bus. There would be a bus per port of course. The drivers for the port alternate modes would take care of things like muxing and other platform specific stuff as needed, and they would be tied to the underlying subsystems and drivers, graphics in case of DisplayPort. The drivers for the partner alternate modes would take care of the actual communication with the alternate mode with VDMs if needed (but not necessarily), and they would need to be tied to the port alternate modes. In practice the driver for both the port and the partner alternate modes will be the same (in the same location) obviously, at least in most cases. I think a bus would allow us to support several ways of handling the alternate modes on different platforms. It would work fine also on platforms that had no use for it of course, like platforms where firmware or EC takes care of most things related to Type-C. But please note that since this is just a high level idea still, we wouldn't for example need to create an actual bus if there is no use for it, but since we have the SVIDs that can be used for matching, then why not try take advantage of them, right. How would something like that sound to you guys? > > That really depends on the lower level driver. For Chromebooks, where the Type-C > > Protocol Manager runs on the EC, we have an extcon driver which reports the pin states > > to the graphics drivers and connects to the Type-C class code using the Type-C class > > API. I still need to update, re-test, and publish that code. The published code in > > https://chromium.googlesource.com/chromiumos/third_party/kernel/, branch chromeos-4.4, > > shows how it can be done, though that code currently still uses the Android Type-C > > infrastructure. In this case I think you would only need to register a driver with the bus in case you want the handle to the device for the alternate mode. > OK, thanks! > > My system is a bit different. It's an i.MX6 SoC with the typec phy and DP controller connected > directly to the SoC and it's using DTB/OF. Is this "DP controller" a controller that is capable of taking care of the USB Power Delivery communication with the partner regarding DisplayPort alternate mode? > Using extcon I would have a driver that is both typec class and extcon driver at the same time > since I can't share the access to the typec phy. Is this done elsewhere in the kernel? > I don't know much about the wcove PMIC and what alternate modes it might support but I > guess that driver would end up in the same place. What alternate modes systems with WhiskeyCove supports depends on the platform. WhiskeyCove PMIC (as in Power Management IC) is available on a few Intel Atom platforms. The USB Type-C PHY in it provides a simple USB PD transceiver that does not touch the actual communication with the partners. The communication needs to be done in software, including dealing with alternate modes. I'm not planning on using extcon for anything with WhiskeyCove. I don't have any use for it. It looks to me that extcon is used just as a tool to create software couplings in many cases, and I'm not completely comfortable with that. In my case with DP altmode, if we had for example muxes to take care of, I don't think it would be a problem to tie the driver for the mux to the graphics directly, so basically make it part of the graphics stack. That driver would be the port (and partner) altmode driver. > Do we need to further standardize attributes under (each) specific alternate mode to > include things such as HPD for the DP mode? I'm not completely sure what kind of system you have, but I would imagine that if we had the bus, your DP controller driver would be the port (and partner) alternate mode driver. The bus would bind you to the typec phy. 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
