From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755384AbcFGODW (ORCPT ); Tue, 7 Jun 2016 10:03:22 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:42461 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752606AbcFGODU (ORCPT ); Tue, 7 Jun 2016 10:03:20 -0400 Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux To: Felipe Balbi , Lu Baolu , Jun Li , Peter Chen 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> <20160606012557.GA16012@shlinux2> <5754E850.1020707@linux.intel.com> <57552006.7080108@ti.com> <5756999B.9020809@linux.intel.com> <5756C4DB.1050400@ti.com> <87a8ixb15w.fsf@linux.intel.com> CC: Mathias Nyman , Greg Kroah-Hartman , Lee Jones , Heikki Krogerus , Liam Girdwood , Mark Brown , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Roger Quadros Message-ID: <5756D410.30003@ti.com> Date: Tue, 7 Jun 2016 17:02:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <87a8ixb15w.fsf@linux.intel.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X5nIrp8O2UPuRXpKQFH1hwvou8hoCoGLK" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --X5nIrp8O2UPuRXpKQFH1hwvou8hoCoGLK Content-Type: multipart/mixed; boundary="kTWehIT03icf4qTg1iNJCnf1oLfaq9TlU" From: Roger Quadros To: Felipe Balbi , Lu Baolu , Jun Li , Peter Chen Cc: Mathias Nyman , Greg Kroah-Hartman , Lee Jones , Heikki Krogerus , Liam Girdwood , Mark Brown , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Message-ID: <5756D410.30003@ti.com> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux 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> <20160606012557.GA16012@shlinux2> <5754E850.1020707@linux.intel.com> <57552006.7080108@ti.com> <5756999B.9020809@linux.intel.com> <5756C4DB.1050400@ti.com> <87a8ixb15w.fsf@linux.intel.com> In-Reply-To: <87a8ixb15w.fsf@linux.intel.com> --kTWehIT03icf4qTg1iNJCnf1oLfaq9TlU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/06/16 16:04, Felipe Balbi wrote: >=20 > Hi, >=20 > Roger Quadros writes: >>> But you said I must run an unnecessary OTG state machine, even though= t it >>> has nothing to do with my system, only because the two sides of my po= rt >>> mux device is a host and peripheral controller. >> >> We have a minimal dual-role state machine that just looks at ID pin >> and toggles the port role. >=20 > I don't know if we want to bring all that extra baggage just to write a= > few bits in a single register. Even for DWC3-only dual-role (what > Synopsys licenses as part of some DWC3 instantiations), the OTG/DRD > layer is a bit overkill. >=20 > If you take my testing/next, for example, we have everything we need fo= r > dual-role; except for OTG/DRD IRQ handler. Just look at how we implemen= t > ->suspend()/->resume() and it's be clear that we're just missing one > step. >=20 > I might be able to find some time to implement a proof of concept which= > would allow your platforms to get dual-role with code we already have, > but I need DWC3's OTG support which, I'm assuming, you already have :-)= >=20 > If you wanna try something offline, just ping me ;-) I'll be happy to > help. What you are proposing is a dwc3 only solution. With the otg/dual-role series we are trying to be generic as much as possible. Whether controller drivers want to use it or not is upto the driver maint= ainers but we should at least ensure that user space ABI if any, is consistent across different implementations. >=20 >> How are you switching the port mux between host and peripheral? Only >> by sysfs or do you have a GPIO for ID pin as well? >=20 > depends. Some SoCs have GPIO-controller muxes while some just have mux'= s > select signals (one for ID, one for VBUS) mapped on xHCI's address > space. >=20 >> What happens to the gadget controller when the port is muxed to the >> host controller? Is it stopped or it continues to run? >=20 > it continues running, but that's pretty irrelevant for Intel's dual-rol= e Isn't that unnecessary waste of power? Or you have firmware assisted low power mode? > setup. We have an actual physical (inside the die, though) mux which > muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only > DWC3. >=20 Probably irrelevant for Intel's dual-role but many platforms that share the port can't have device controller running when port is in host mode a= nd vice versa.=20 So there has to be a central point of control where the respective contro= llers are started/stopped. That is the other point we are trying to address with the common otg/dual-role code. Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we need to stop the host controller for device mode, right? If so then who will deal with start/stop of the controllers then? So for Intel port-mux case it seems that OTG/dual-role is overcomplicated= and I wouldn't force you to use it. It is upto Peter to decide how he wan= ts dual-role users to behave. cheers, -roger --kTWehIT03icf4qTg1iNJCnf1oLfaq9TlU-- --X5nIrp8O2UPuRXpKQFH1hwvou8hoCoGLK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXVtQQAAoJENJaa9O+djCTsLwP/15odlcl4BGJE93nbWMcdDFU dJqGvHafRj0bOkkKHaYme7aAQTKvhdnFyJ6v1Awi6SbGGZ874bTv5LAIPWCXwj6l WVxaas8TLPfSSWPFAR/SNjzSNzlG29ErVnuOjgkzvAHEWmXoZmp54d+tdfaERxTh KqRr2eCrrD9uGzdsn+2qaVC3u4E703RC0eZ3zp8eJowgqMPUOedqjGJuBOyNNIra byFwYgk/rH+moGxoKn0F7g3lkLxxr+pDJn+zEz9MmhyOWWrPfOaMkiGYhm4GquFU Pje+brmAI6NGmm4ogN5ZcPolOYLiJppyaAC5Ihk+CRp2t0DtzRY0krBdoTmOaOyi E9sDlvlNPU2sqwWA68uvoayhwEgEbewiZvpQl8bNoHPB69Q/DsaFzGBHYq9+ZYmU T7m8hGWrgaXT7WauYwMDigagt1A7o08pgX/Ik/gy5UAjQPvs3Hq1b+F2ssU7Fh5h BsD6ky0eP2l7bo8uajm/ba5LTKFYaSWOdmfDMv/pikSzxV5QZGuISTJKXNkewL7E 6FT5hrW8LEwYgmpYKl9phtCvHMT7Ke/QlnIPVcjbwgyRhvUgGrA2o8x3557Cm2St Kx6fnPg/d4DmhRWUdsyqv7voEOou0jFcktN79z0c+8IZi0Z1KKaXGA2EctL1eIrD 73mEv3T+JqpMmPMrNVfB =Dn80 -----END PGP SIGNATURE----- --X5nIrp8O2UPuRXpKQFH1hwvou8hoCoGLK--