Hi Peter, On 06/04/2016 10:28 AM, Peter Chen wrote: > On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: >>> from my point,it is a dual-role switch >>> driver too, >> No, it's not a dual-role switch driver, but a driver for USB port multiplexing. >> >> One example of port multiplexing can be found in several Intel SOC and PCH >> chips, inside of which, there are two independent USB controllers: host and >> device. They might share a single port and this port could be configured to >> route the line to one of these two controllers. This patch introduced a generic >> framework for port mux drivers. It aids the drivers to handle port mux by >> providing interfaces to 1) register/unregister a mux device; 2) lookup the >> mux device; and 3) switch the port. >> > For this case, I can't see it is different with dual-role switch. Port mux is part of dual role switch, but not the whole thing. Dual role switch includes at least below things: - ID or type-C event detection - port mux - VBUS management - start/stop host/device controllers An OTG/Dual-role framework can be used to keep all these things run together with an internal state machine. But it's not duplicated with a generic framework for port mux and the port mux drivers. > Your > case is just like Renesas case, which uses two different drivers between > peripheral and host[1]. In my case, the port mux devices are physical devices and they can be controlled through GPIO pins or device registers. They are independent of both peripheral and host controllers. >> Port multiplexing isn't equal to USB dual role. There are other cases in today's >> systems. In several Intel PCH chips, there equips two USB host controllers: ehci >> and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees all >> USB ports work even running an old version of OS which lacks of USB3 support. >> In theory, we can create a driver for the port mux and switch the ports between >> xhci and ehci, but that's silly, isn't it? Why not always USB3?:-) >> >> Another case is xHCI debug capability. The xHCI host controller might equip >> a unit for system debugging (refer to 7.6 of xHCI spec). The debugging unit is >> independent of xhci host controller. But it shares its port with xhci. Software >> could switch the port between xhci and the debugging unit through the registers >> defined in xHCI spec. >> > Yes, above two are different with dual role switch. But in your code and > Kconfig, it seems this framework is dedicated for dual-role. Eg: > > +menuconfig USB_PORTMUX > + bool "USB dual role port MUX support" > + help > + Generic USB dual role port mux support. Above two cases are examples for port multiplexing, but I don't think we need drivers for them. At this moment, this framework is only for dual role port mux devices. > > I think a general dual role port mux is necessary, it can be used to > manage different dual-role switch method, eg Yes, I agree. > - ID pin > - External connector through GPIO > - SoC register > - sysfs > - type-C events ID pin and type-C events are the *reasons* which trigger the port mux switch. Currently, on our platforms, gpio, registers and sysfs are methods to control the mux. > > But this code is better co-work with OTG/Dual-role framework, we'd > better have only interface that the user can know which role for the > current port. OTG/Dual-role framework and portmux framework are not overlapped. The sysfs interface shouldn't be overlapped as well. Say, I have a port mux device and I have a driver for it. I am able to read the status of my port mux device through sysfs. This is not part of OTG/Dual-role as far as I can see. Best regards, Lu Baolu -- 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
