Hi, On 06/06/16 06:04, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 09:25 AM, Peter Chen wrote: >> On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote: >>> 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. >> You have admitted port mux is one of the ports of dual-role switch, >> Then, how they can co-work with each other? If can't, the dual-role >> switch framework needs another input events management for switching. > > My point is we need a generic framework for the port mux devices, > just like we have that for PHY and regulator. OTG framework > manages the port mux devices through the common interfaces > provided by the port mux framework. > > If we integrate the port mux device support into OTG itself, this will > force every use case of port mux to rely on the big OTG framework, > although what it needs is only a single driver. That causes unnecessary > software complexity. I agree with Lu here. Intel platforms seem to actually have a Mux device and we need a device driver for that. OTG/dual-role core cannot directly handle the Mux device. The Mux device can be used not only for dual-role but for other things so we can't force it to use just OTG/dual-role. For Mux devices implementing dual-role, the mux device driver _must_ use OTG/dual-role core API so that a common ABI is presented to user space for OTG/dual-role. I haven't yet looked at the mux framework but if we take care of the above point then we are not introducing any redundancy. > >> >>>> 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. >>> >> Yes, it is the same. GPIO pin or device registers is like ID pin >> event. >> > > <snip> > >>> 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. >>> >> Then how the user wants to switch the role through the mux driver's >> sysfs or dual-role switch sysfs? >> > > It depends. If you have an OTG/DRD capable controllers, you need to > do this through OTG sysfs; otherwise you only need to switch the port. > -- cheers, -roger -- 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
