Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Peter Chen <hzpeterchen@gmail.com>]

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.

> 
> > 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.

> 
> >> 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.
> 

Then how the user wants to switch the role through the mux driver's
sysfs or dual-role switch sysfs?

-- 

Best Regards,
Peter Chen