Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753046AbbBQTZV (ORCPT ); Tue, 17 Feb 2015 14:25:21 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:42324 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751646AbbBQTZT (ORCPT ); Tue, 17 Feb 2015 14:25:19 -0500 Date: Tue, 17 Feb 2015 13:25:00 -0600 From: Felipe Balbi To: David Cohen CC: Felipe Balbi , Linus Walleij , , , , , Subject: Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s) Message-ID: <20150217192459.GG31167@saruman.tx.rr.com> Reply-To: References: <1419288217-19262-1-git-send-email-david.a.cohen@linux.intel.com> <20141224002904.GE32702@saruman> <20141224224327.GA3175@psi-dev26.jf.intel.com> <20141226044929.GC7661@saruman> <20150217191844.GA2957@psi-dev26.jf.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5lq+205vWdkqwtk" Content-Disposition: inline In-Reply-To: <20150217191844.GA2957@psi-dev26.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8894 Lines: 215 --r5lq+205vWdkqwtk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Feb 17, 2015 at 11:18:44AM -0800, David Cohen wrote: > > > > > (3) Platform has 2 USB controllers connected to same port: one for > > > > > device and one for host role. D+/- are switched between phys > > > > > by GPIO. > > > >=20 > > > > so you have discrete mux with a GPIO select signal, like below ? > > > >=20 > > > >=20 > > > > .-------.----------------. .--------. > > > > | | | | | D+ > > > > | | | | |<-------------. > > > > | | | | | | > > > > | | USB Host -->| P | | > > > > | | | | H | | > > > > | | | | Y | D- | > > > > | '----------------' | 0 |<--------. | > > > > | | | | | | > > > > | | '--------' .--------. D+ > > > > | | | |------> > > > > | SOC GPIO | ----------------->| | > > > > | | | MUX | > > > > | | | |------> > > > > | | .--------. '--------' D- > > > > | .----------------. | | D- | | > > > > | | | | P |<------' | > > > > | | | | H | | > > > > | | | | Y | | > > > > | | USB Device -->| 1 | | > > > > | | | | | D+ | > > > > | | | | |<-------------' > > > > | | | | | > > > > '-------'----------------' '--------' > > >=20 > > > Nice ASCII pic :) > >=20 > > asciio ftw \o/ > >=20 > > > Yes, that's the case. > >=20 > > alright > >=20 > > > > I have been on and off about writing a pinctrl-gpio.c driver which = would > > > > allow us to hide this detail from users. It shouldn't really matter > > > > which modes are available behind the mux, but we should be able to = tell > > > > the mux to go into mode 0 or mode 1 by toggling its select signal. = And > > > > it shouldn't really matter that we have a GPIO pin. The problem is:= I > > > > don't really know if pinctrl would be able to handle discrete muxes. > > > >=20 > > > > Adding Linus W to ask. Linus, what do you think ? Should we have a > > > > pinctrl-gpio.c for such cases ? In TI we too have quite a few boards > > > > which different modes hidden behind discrete muxes. > > >=20 > > > An input from Linus would fine in this case. > > >=20 > > > >=20 > > > > > As per initial version, this driver has the duty to control wheth= er > > > > > USB-Host cable is plugged in or not: > > > > > - If yes, OTG port is configured for host role > > > > > - If no, by standard, the OTG port is configured for device role > > > >=20 > > > > correct, this default-B is mandated by OTG spec anyway. > > > >=20 > > > > > Signed-off-by: David Cohen > > > > > --- > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > Some Intel Bay Trail boards have an unusual way to handle the USB= OTG port: > > > > > - The USB ID pin is connected directly to GPIO on SoC > > > > > - When in host role, VBUS is provided by enabling a GPIO > > > > > - Device and host roles are supported by 2 independent controlle= rs with D+/- > > > > > pins from port switched between different phys according a GPI= O level. > > > > >=20 > > > > > The ACPI table describes this USB port as a (virtual) device with= all the > > > > > necessary GPIOs. This driver implements support to this virtual d= evice as an > > > > > extcon class driver. All drivers that depend on the USB OTG port = state (USB phy, > > > > > PMIC, charge detection) will listen to extcon events. > > > >=20 > > > > Right I think you're almost there, but I still think that this need= s to > > > > be a bit broken down. First, we need some generic DRD library under > > > > drivers/usb/common, and that should be the one listening to extcon = cable > > > > events. But your extcon driver should be doing only that: checking = which > > > > cable was attached, it shouldn't be doing the switch by itself. That > > > > should be part of the DRD library. > > > >=20 > > > > That DRD library would also be the one enabling the (optional) VBUS > > > > regulator. > > > >=20 > > > > George Cherian tried to implement a generic DRD library but I think > > > > there are still too many changes happening on usbcore and udc-core.= Most > > > > of the pieces are already there (usb_del_hcd() and usb_del_gadget_u= dc() > > > > know how to properly unload an hcd/udc), but there are details miss= ing, > > > > no doubt. > > > >=20 > > > > If we can find a way to broadcast (probably not the best term, but > > > > whatever) a "Hey ID pin was just grounded" message, we can get thin= gs > > > > working. > > > >=20 > > > > That message, btw, shouldn't really depend on extcon-gpio alone bec= ause > > > > other platforms might use non-gpio methods to verify ID pin level. = In > > > > any case, we need to have generic ID_PIN_LOW and ID_PIN_HIGH messag= es > > > > that a generic DRD library can listen to and load/unload the correct > > > > drivers by means of usb_{add,del}_{hcd,gadget_udc}(). > > >=20 > > > IMHO extcon is the correct way to broadcast it, as long as we define a > > > standard for the cable names. E.g. DRD library could listen to > > > "USB-HOST" cable state. Then it doesn't matter how ID pin is grounded, > > > it just matters that whoever is controlling it broadcast via this cab= le. > >=20 > > right, the likelyhood that someone would not use a GPIO is also quite > > minimal and for such cases, the controller would likely switch roles > > automatically (like with MUSB). > >=20 > > > > With that in mind, I think you can use extcon-gpio.c for your purpo= ses > > > > if the other pieces can be fullfilled by regulator and pinctrl. > > >=20 > > > In my case we have all gpios listed in a single ACPI device. In order= to > > > be backwards compatible with products already on market, we'd need > > > something like a single mfd to register platform devices for this > > > smaller pieces (extcon gpio, possible pintrl gpio, maybe vbus as regu= lator??). > >=20 > > correct. >=20 > Getting back to this case :) > Guess I need to get back my words. >=20 > extcon-gpio.c cannot work out-of-the-box with my case. There is no clean > way to get the GPIO given to this device via ACPI and refer it to another > device (i.e. extcon-gpio). add what's missing ? > Here's my scenario: > This platform has only one ACPI device representing the USB port with 3 > gpios controlling it. As GPIO consumer, there is no clean interface > where I could get a GPIO descriptor via ACPI without requesting it. > After request it, I cannot give it to extcon-gpio.c. Same would happen > for a possible pinctrl gpio and regulator controller by gpio. >=20 > So my choices: > 1) request GPIO locally, give it to other drivers and somehow inform > them they should not request, but just to handle it (ugly) >=20 > 2) implement a way to pass this GPIO resource to another device without > requesting locally >=20 > 3) stick with this driver fully handling the GPIOs which control this > virtual "USB OTG port" device 4) grab gpio via ACPI, gpio_free() it, pass to this driver. Would that work ? --=20 balbi --r5lq+205vWdkqwtk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU45WLAAoJEIaOsuA1yqREnIgQAI1uoWKfV+uvQiFb660/ZlRU Q92WcV+rpVNsBXah3MhiRYuOhHqPFEp7I0+j8QXQdpjqx9NZe2V+dfXZYVgEiPkj k9p2jkT3UVl7g/u1CK9WnolL181jmP37IqgNtuB5pG31n5duCM9ywcWmvFkOvbJZ UHznPwJGtHrMYQ8UAbOqpOWYR5db6gOKP/yV7CvltlU235UujLUMhziEZAiONUTb hB0t8z9zhGkKY1YtT6PnDsEyGgmG/HRLfF70xM4A4repQdfU92qBYctgB/wQjbFB WBRW2bayk9Wj7DQRW3PA/Xt5H+sYiUCuqC4lE2vw6vxOKZOGdXK3Z0HviACEVSJb HC35m+4BH9Ll0Wf/fpB6GYDhLKZRQfEvh2j3U2HjJce/SJ1h6grQazYiur9+k8HK gy8rv63iP1zhAwe06CJIvpc5gW7NQyk48uwqpMyfxcKmy/MmDwPXPC94nyolqRub 1+xDRkX2KaM7Co0gB8ES35fBAbi2AJ27XX5WFWQJHR9R5icrAaaJ2NF0qCCmpJe6 nGy2UovCP8qCuoHpvGqzc6B8Feah0BfXIbxRMtuao3apZc4cota/OjlSk2266alY aMYE0uY09p8R4aMdtZcz2gYrWV4xL0j7gS0U3UUDp4JjmiDQh65n7nzd1m1+Bwr8 mGWFSTLycbt5Q7Ru3zNs =J8ZH -----END PGP SIGNATURE----- --r5lq+205vWdkqwtk-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/