Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

[David Cohen <david.a.cohen@linux.intel.com>]

On Tue, Dec 23, 2014 at 11:09:44PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/23/2014 10:57 PM, David Cohen wrote:
> 
> >>>Some platforms have an USB OTG port fully (or partially) controlled by
> >>>GPIOs:
> 
> >>>(1) USB ID is connected directly to GPIO
> 
> >>>Optionally:
> >>>(2) VBUS is enabled by a GPIO (when ID is grounded)
> 
> >>    Can't the host driver still control Vbus?
> 
> >I can't a clean way for host driver to control VBUS considering it
> >depends on USB ID.
> 
>    You're using the cable state notifiers, why not control Vbus from there?
> You need some way of passing the GPIO to host driver though... I assume
> you're not using the device tree, and your host controllers live on PCI, so
> the platform data is out of question. You may be right then...

Yes to all questions :)

> 
> >>>(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.
> 
> >>>As per initial version, this driver has the duty to control whether
> >>>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
> 
> >>>Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
> >>>---
> 
> >>>Hi,
> 
> >>>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 controllers with D+/-
> >>>    pins from port switched between different phys according a GPIO level.
> 
> >>>The ACPI table describes this USB port as a (virtual) device with all the
> >>>necessary GPIOs. This driver implements support to this virtual device 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.
> 
> >>    It's very close to my setup on R-Car R8A7791 based boards. :-)
> >>I have already submitted Maxim MAX3355 OTG chip GPIO-based driver.
> 
> >Hm. I'll look for it. Thanks for pointing.
> 
>    http://marc.info/?l=linux-usb&m=141825413802370
>    In my case, Vbus is not controlled via GPIO though. I would have probably
> used the generic GPIO extcon driver if I didn't have to drive MAX3355's
> SHDN# pin high...

Besides the USB ID, I need to control VBUS and the D+/- switch. We have
a new use case coming soon that may need to add a second switch control.

>    There were also some other patches for this issue, the one probably
> interesting to you is there:
> 
>    http://marc.info/?l=linux-usb&m=141877180912359

This one is interesting, but I'm restricted to ACPI and to the DSDTs already
released.
E.g. http://www.androidauthority.com/trekstor-xintron-lollipop-564364/

Br, David

> 
> >>>Comments are welcome.
> 
> >>>Br, David
> 
> [...]
> 
> >>>+static int __init vuport_init(void)
> >>>+{
> >>>+	return platform_driver_register(&vuport_driver);
> >>>+}
> >>>+subsys_initcall(vuport_init);
> 
> >>    Hm, why?
> 
> >We have drivers that depend on this one during their probe.
> 
>    What about deferred probing? With EPROBE_DEFER we don't need to play the
> initcall games any more AFAIU.
> 
> >Br, David
> 
> WBR, Sergei
>