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

[Jun Li]

Hi

> -----Original Message-----
> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Lu Baolu
> Sent: Sunday, June 05, 2016 2:56 PM
> To: Peter Chen <hzpeterchen@xxxxxxxxx>
> Cc: felipe.balbi@xxxxxxxxxxxxxxx; Mathias Nyman <mathias.nyman@xxxxxxxxx>;
> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Lee Jones
> <lee.jones@xxxxxxxxxx>; Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>;
> Liam Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>;
> linux-usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Roger Quadros
> <rogerq@xxxxxx>
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> 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.
> 

I also think current OTG/Dual role framework can support your case, if you
find there is any limitation of it which can't meet your requirement, we
should improve it, Roger also provide an example of dual role switch with
USB3 based on his OTG core.

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

Those methods also can be mapped/added into OTG/dual role core framework.

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

>From previous discussion, I still think this is a special dual role
switch:) which should be covered by general OTG/dual role core(this
core framework is target to support one port with both host and
device capable by any HW/IC implementations).

Li Jun

> 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