From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752093AbcFFBbn (ORCPT ); Sun, 5 Jun 2016 21:31:43 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:34475 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbcFFBbl (ORCPT ); Sun, 5 Jun 2016 21:31:41 -0400 Date: Mon, 6 Jun 2016 09:25:57 +0800 From: Peter Chen To: Lu Baolu Cc: felipe.balbi@linux.intel.com, Mathias Nyman , Greg Kroah-Hartman , Lee Jones , Heikki Krogerus , Liam Girdwood , Mark Brown , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Roger Quadros Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux Message-ID: <20160606012557.GA16012@shlinux2> References: <1464831449-8973-1-git-send-email-baolu.lu@linux.intel.com> <1464831449-8973-3-git-send-email-baolu.lu@linux.intel.com> <20160603074113.GA30006@shlinux2> <5751AAEE.2090001@linux.intel.com> <20160604022838.GA26936@shlinux2> <5753CCFC.2060504@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5753CCFC.2060504@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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