Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi, On Wed, Feb 18, 2015 at 12:17:06PM +0200, Mika Westerberg wrote: > On Tue, Feb 17, 2015 at 11:35:23AM -0800, David Cohen wrote: > > Hi, > > > > Adding Mika. > > > > On Tue, Feb 17, 2015 at 01:25:00PM -0600, Felipe Balbi wrote: > > > 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. > > > > > > > > > > > > > > so you have discrete mux with a GPIO select signal, like below ? > > > > > > > > > > > > > > > > > > > > > .---.. .. > > > > > > > | || || D+ > > > > > > > | || ||<-. > > > > > > > | || || | > > > > > > > | |USB Host-->|P | | > > > > > > > | || |H | | > > > > > > > | || |Y |D-| > > > > > > > | '' |0 |<.| > > > > > > > | | || || > > > > > > > | | '' .. D+ > > > > > > > | | ||--> > > > > > > > | SOCGPIO | ->|| > > > > > > > | | | MUX | > > > > > > > | | ||--> > > > > > > > | | .. '' D- > > > > > > > | .. || D- | | > > > > > > > | || |P |<--' | > > > > > > > | || |H | | > > > > > > > | || |Y | | > > > > > > > | | USB Device -->|1 | | > > > > > > > | || || D+ | > > > > > > > | || ||<-' > > > > > > > | || || > > > > > > > '---'' '' > > > > > > > > > > > > Nice ASCII pic :) > > > > > > > > > > asciio ftw \o/ > > > > > > > > > > > Yes, that's the case. > > > > > > > > > > alright > > > > > > > > > > > > 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. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > An input from Linus would fine in this case. > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > correct, this default-B is mandated by OTG spec anyway. > > > > > > > > > > > > > > > Signed-off-by: David Cohen > > > > > > > > --- > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Right I think you're almost there, but I still think that this > > > > > > > needs to > > > > > > > be a bit broken down. First, we need some
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Tue, Feb 17, 2015 at 11:35:23AM -0800, David Cohen wrote: > Hi, > > Adding Mika. > > On Tue, Feb 17, 2015 at 01:25:00PM -0600, Felipe Balbi wrote: > > 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. > > > > > > > > > > > > so you have discrete mux with a GPIO select signal, like below ? > > > > > > > > > > > > > > > > > > .---.. .. > > > > > > | || || D+ > > > > > > | || ||<-. > > > > > > | || || | > > > > > > | |USB Host-->|P | | > > > > > > | || |H | | > > > > > > | || |Y |D-| > > > > > > | '' |0 |<.| > > > > > > | | || || > > > > > > | | '' .. D+ > > > > > > | | ||--> > > > > > > | SOCGPIO | ->|| > > > > > > | | | MUX | > > > > > > | | ||--> > > > > > > | | .. '' D- > > > > > > | .. || D- | | > > > > > > | || |P |<--' | > > > > > > | || |H | | > > > > > > | || |Y | | > > > > > > | | USB Device -->|1 | | > > > > > > | || || D+ | > > > > > > | || ||<-' > > > > > > | || || > > > > > > '---'' '' > > > > > > > > > > Nice ASCII pic :) > > > > > > > > asciio ftw \o/ > > > > > > > > > Yes, that's the case. > > > > > > > > alright > > > > > > > > > > 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. > > > > > > > > > > > > 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. > > > > > > > > > > An input from Linus would fine in this case. > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > correct, this default-B is mandated by OTG spec anyway. > > > > > > > > > > > > > Signed-off-by: David Cohen > > > > > > > --- > > > > > > > > > > > > > > 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. > > > > > > > > > > > > Right I think you're almost there, but I still think that this > > > > > > needs 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
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi, Adding Mika. On Tue, Feb 17, 2015 at 01:25:00PM -0600, Felipe Balbi wrote: > 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. > > > > > > > > > > so you have discrete mux with a GPIO select signal, like below ? > > > > > > > > > > > > > > > .---.. .. > > > > > | || || D+ > > > > > | || ||<-. > > > > > | || || | > > > > > | |USB Host-->|P | | > > > > > | || |H | | > > > > > | || |Y |D-| > > > > > | '' |0 |<.| > > > > > | | || || > > > > > | | '' .. D+ > > > > > | | ||--> > > > > > | SOCGPIO | ->|| > > > > > | | | MUX | > > > > > | | ||--> > > > > > | | .. '' D- > > > > > | .. || D- | | > > > > > | || |P |<--' | > > > > > | || |H | | > > > > > | || |Y | | > > > > > | | USB Device -->|1 | | > > > > > | || || D+ | > > > > > | || ||<-' > > > > > | || || > > > > > '---'' '' > > > > > > > > Nice ASCII pic :) > > > > > > asciio ftw \o/ > > > > > > > Yes, that's the case. > > > > > > alright > > > > > > > > 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. > > > > > > > > > > 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. > > > > > > > > An input from Linus would fine in this case. > > > > > > > > > > > > > > > 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 > > > > > > > > > > correct, this default-B is mandated by OTG spec anyway. > > > > > > > > > > > Signed-off-by: David Cohen > > > > > > --- > > > > > > > > > > > > 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. > > > > > > > > > > Right I think you're almost there, but I still think that this needs > > > > > 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. > > > > > > > > > > That DRD library would also be the one enabling the (optional) VBUS > > > > > regulator. > > > > > > > > > > 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 > > > > > o
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
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. > > > > > > > > so you have discrete mux with a GPIO select signal, like below ? > > > > > > > > > > > > .---.. .. > > > > | || || D+ > > > > | || ||<-. > > > > | || || | > > > > | |USB Host-->|P | | > > > > | || |H | | > > > > | || |Y |D-| > > > > | '' |0 |<.| > > > > | | || || > > > > | | '' .. D+ > > > > | | ||--> > > > > | SOCGPIO | ->|| > > > > | | | MUX | > > > > | | ||--> > > > > | | .. '' D- > > > > | .. || D- | | > > > > | || |P |<--' | > > > > | || |H | | > > > > | || |Y | | > > > > | | USB Device -->|1 | | > > > > | || || D+ | > > > > | || ||<-' > > > > | || || > > > > '---'' '' > > > > > > Nice ASCII pic :) > > > > asciio ftw \o/ > > > > > Yes, that's the case. > > > > alright > > > > > > 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. > > > > > > > > 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. > > > > > > An input from Linus would fine in this case. > > > > > > > > > > > > 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 > > > > > > > > correct, this default-B is mandated by OTG spec anyway. > > > > > > > > > Signed-off-by: David Cohen > > > > > --- > > > > > > > > > > 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. > > > > > > > > Right I think you're almost there, but I still think that this needs 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. > > > > > > > > That DRD library would also be the one enabling the (optional) VBUS > > > > regulator. > > > > > > > > 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_udc() > > > > know how to properly unload an hcd/udc), but there are details missing, > > > > no doubt. > > > > > > > > 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 things > > > > workin
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi Linus,
Thanks for reviewing.
On Thu, Jan 08, 2015 at 08:23:03PM +0100, Linus Walleij wrote:
> On Mon, Dec 22, 2014 at 11:43 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)
> > (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
>
> Pretty interesting! I don't understand the USB stuff so commenting
> from a GPIO side of things only.
>
> > +config EXTCON_OTG_GPIO
> > + tristate "VIRTUAL USB OTG PORT support"
> > + depends on GPIOLIB
>
> Isn't it dependent on ACPI? This was mentioned in the commit message.
Yep, I'll add it :)
>
> > +/*
> > + * Virtual USB OTG Port driver controlled by gpios
> > + *
> > + * Copyright (c) 2014, Intel Corporation.
> > + * Author: David Cohen
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
>
> You should include
>
> And nothing else. (I think it'll just work.)
It should work. I'll fix it.
>
> > +static int __init vuport_init(void)
> > +{
> > + return platform_driver_register(&vuport_driver);
> > +}
> > +subsys_initcall(vuport_init);
>
> Usually we try to avoid this kind of early initcalls.
> Doesn't deferred probe work as intended?
Yeah, deferred probe is a better thing to try here.
Br, David
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi Felipe and Linus, On Thu, Dec 25, 2014 at 10:49:29PM -0600, Felipe Balbi wrote: > Hi, > > On Wed, Dec 24, 2014 at 02:43:27PM -0800, David Cohen wrote: > > Hi Felipe, > > > > Thanks replying. > > > > On Tue, Dec 23, 2014 at 06:29:04PM -0600, Felipe Balbi wrote: > > > Hi, > > > > > > On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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) > > > > > > ok, so a fixed regulator with a GPIO enable pin. > > > > Pretty much yes. > > ok > > > > > (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. > > > > > > so you have discrete mux with a GPIO select signal, like below ? > > > > > > > > > .---.. .. > > > | || || D+ > > > | || ||<-. > > > | || || | > > > | |USB Host-->|P | | > > > | || |H | | > > > | || |Y |D-| > > > | '' |0 |<.| > > > | | || || > > > | | '' .. D+ > > > | | ||--> > > > | SOCGPIO | ->|| > > > | | | MUX | > > > | | ||--> > > > | | .. '' D- > > > | .. || D- | | > > > | || |P |<--' | > > > | || |H | | > > > | || |Y | | > > > | | USB Device -->|1 | | > > > | || || D+ | > > > | || ||<-' > > > | || || > > > '---'' '' > > > > Nice ASCII pic :) > > asciio ftw \o/ > > > Yes, that's the case. > > alright > > > > 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. > > > > > > 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. > > > > An input from Linus would fine in this case. > > > > > > > > > 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 > > > > > > correct, this default-B is mandated by OTG spec anyway. > > > > > > > Signed-off-by: David Cohen > > > > --- > > > > > > > > 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. > > > > > > Right I think you're almost there, but I still think that this needs 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. > > > > > > That DRD library would also be the one enabling the (optional) VBUS > > > regulator. > > > > > > George Cherian tried to implement a generic DRD library but I thi
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Mon, Dec 22, 2014 at 11:43 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)
> (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
Pretty interesting! I don't understand the USB stuff so commenting
from a GPIO side of things only.
> +config EXTCON_OTG_GPIO
> + tristate "VIRTUAL USB OTG PORT support"
> + depends on GPIOLIB
Isn't it dependent on ACPI? This was mentioned in the commit message.
> +/*
> + * Virtual USB OTG Port driver controlled by gpios
> + *
> + * Copyright (c) 2014, Intel Corporation.
> + * Author: David Cohen
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
You should include
And nothing else. (I think it'll just work.)
> +static int __init vuport_init(void)
> +{
> + return platform_driver_register(&vuport_driver);
> +}
> +subsys_initcall(vuport_init);
Usually we try to avoid this kind of early initcalls.
Doesn't deferred probe work as intended?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi, On Wed, Dec 24, 2014 at 02:43:27PM -0800, David Cohen wrote: > Hi Felipe, > > Thanks replying. > > On Tue, Dec 23, 2014 at 06:29:04PM -0600, Felipe Balbi wrote: > > Hi, > > > > On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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) > > > > ok, so a fixed regulator with a GPIO enable pin. > > Pretty much yes. ok > > > (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. > > > > so you have discrete mux with a GPIO select signal, like below ? > > > > > > .---.. .. > > | || || D+ > > | || ||<-. > > | || || | > > | |USB Host-->|P | | > > | || |H | | > > | || |Y |D-| > > | '' |0 |<.| > > | | || || > > | | '' .. D+ > > | | ||--> > > | SOCGPIO | ->|| > > | | | MUX | > > | | ||--> > > | | .. '' D- > > | .. || D- | | > > | || |P |<--' | > > | || |H | | > > | || |Y | | > > | | USB Device -->|1 | | > > | || || D+ | > > | || ||<-' > > | || || > > '---'' '' > > Nice ASCII pic :) asciio ftw \o/ > Yes, that's the case. alright > > 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. > > > > 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. > > An input from Linus would fine in this case. > > > > > > 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 > > > > correct, this default-B is mandated by OTG spec anyway. > > > > > Signed-off-by: David Cohen > > > --- > > > > > > 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. > > > > Right I think you're almost there, but I still think that this needs 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. > > > > That DRD library would also be the one enabling the (optional) VBUS > > regulator. > > > > 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_udc() > > know how to properly unload an hcd/udc), but there are details missing, > > no doubt. > > > > If we can find a way to broadcast (probably not the best term, but > > whatever)
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Wed, Dec 24, 2014 at 11:08:52AM +0800, Peter Chen wrote: > On Tue, Dec 23, 2014 at 11:40:23AM -0800, David Cohen wrote: > > Hi Peter, > > > > Thanks for the review. > > > > On Tue, Dec 23, 2014 at 09:25:18AM +0800, Peter Chen wrote: > > > On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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) > > > > (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. > > > > > > Would you explain how it works? Choosing controller runtime? > > > > Both controllers are (indirectly) connected to the same micro B port. > > The D+/- goes from the port to a switch operated by a GPIO. From the > > switch, D+/- may go to Host controller's phy or Device controller's phy. > > Depends on the GPIO level. > > > > Get it, why the design like that? If your controller supports both > roles, the software can do role switch by ID pin (through gpio in your > case). It's really 2 controllers: 1 for each role. And the ID pin from port is connected to GPIO only. > > > > > > > > > > > > As per initial version, this driver has the duty to control whether > > > > USB-Host cable is plugged in or not: > > > > > > You mean Micro-AB cable, right? > > > > > > + > > > > + vup->gpio_usb_mux = devm_gpiod_get_index(dev, "usb mux", > > > > +VUPORT_GPIO_USB_MUX); > > > > + if (IS_ERR(vup->gpio_usb_mux)) > > > > + dev_info(dev, "cannot request USB USB MUX, skipping > > > > it.\n"); > > > > > > Using dev_err > > > > That's not really an error, although the IS_ERR() suggests otherwise. > > The driver works well if a board doesn't need this mux (I'll add a > > comment to state that clear). IMHO either keep dev_info or use dev_dgb > > instead? > > > > If that, dev_dbg may be suitable. Ack. Br, David > > > -- > > Best Regards, > Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi Felipe, Thanks replying. On Tue, Dec 23, 2014 at 06:29:04PM -0600, Felipe Balbi wrote: > Hi, > > On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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) > > ok, so a fixed regulator with a GPIO enable pin. Pretty much yes. > > > (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. > > so you have discrete mux with a GPIO select signal, like below ? > > > .---.. .. > | || || D+ > | || ||<-. > | || || | > | |USB Host-->|P | | > | || |H | | > | || |Y |D-| > | '' |0 |<.| > | | || || > | | '' .. D+ > | | ||--> > | SOCGPIO | ->|| > | | | MUX | > | | ||--> > | | .. '' D- > | .. || D- | | > | || |P |<--' | > | || |H | | > | || |Y | | > | | USB Device -->|1 | | > | || || D+ | > | || ||<-' > | || || > '---'' '' Nice ASCII pic :) Yes, that's the case. > > 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. > > 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. An input from Linus would fine in this case. > > > 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 > > correct, this default-B is mandated by OTG spec anyway. > > > Signed-off-by: David Cohen > > --- > > > > 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. > > Right I think you're almost there, but I still think that this needs 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. > > That DRD library would also be the one enabling the (optional) VBUS > regulator. > > 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_udc() > know how to properly unload an hcd/udc), but there are details missing, > no doubt. > > 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 things > working. > > That message, btw, shouldn't really depend on extcon-gpio alone because > 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 messages > that a generic DRD library can
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Tue, Dec 23, 2014 at 11:40:23AM -0800, David Cohen wrote: > Hi Peter, > > Thanks for the review. > > On Tue, Dec 23, 2014 at 09:25:18AM +0800, Peter Chen wrote: > > On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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) > > > (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. > > > > Would you explain how it works? Choosing controller runtime? > > Both controllers are (indirectly) connected to the same micro B port. > The D+/- goes from the port to a switch operated by a GPIO. From the > switch, D+/- may go to Host controller's phy or Device controller's phy. > Depends on the GPIO level. > Get it, why the design like that? If your controller supports both roles, the software can do role switch by ID pin (through gpio in your case). > > > > > > > > As per initial version, this driver has the duty to control whether > > > USB-Host cable is plugged in or not: > > > > You mean Micro-AB cable, right? > > > > + > > > + vup->gpio_usb_mux = devm_gpiod_get_index(dev, "usb mux", > > > + VUPORT_GPIO_USB_MUX); > > > + if (IS_ERR(vup->gpio_usb_mux)) > > > + dev_info(dev, "cannot request USB USB MUX, skipping it.\n"); > > > > Using dev_err > > That's not really an error, although the IS_ERR() suggests otherwise. > The driver works well if a board doesn't need this mux (I'll add a > comment to state that clear). IMHO either keep dev_info or use dev_dgb > instead? > If that, dev_dbg may be suitable. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi,
On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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)
ok, so a fixed regulator with a GPIO enable pin.
> (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.
so you have discrete mux with a GPIO select signal, like below ?
.---.. ..
| || || D+
| || ||<-.
| || || |
| |USB Host-->|P | |
| || |H | |
| || |Y |D-|
| '' |0 |<.|
| | || ||
| | '' .. D+
| | ||-->
| SOCGPIO | ->||
| | | MUX |
| | ||-->
| | .. '' D-
| .. || D- | |
| || |P |<--' |
| || |H | |
| || |Y | |
| | USB Device -->|1 | |
| || || D+ |
| || ||<-'
| || ||
'---'' ''
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.
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.
> 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
correct, this default-B is mandated by OTG spec anyway.
> Signed-off-by: David Cohen
> ---
>
> 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.
Right I think you're almost there, but I still think that this needs 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.
That DRD library would also be the one enabling the (optional) VBUS
regulator.
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_udc()
know how to properly unload an hcd/udc), but there are details missing,
no doubt.
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 things
working.
That message, btw, shouldn't really depend on extcon-gpio alone because
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 messages
that a generic DRD library can listen to and load/unload the correct
drivers by means of usb_{add,del}_{hcd,gadget_udc}().
With that in mind, I think you can use extcon-gpio.c for your purposes
if the other pieces can be fullfilled by regulator and pinctrl.
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42e5a27..9e81088c6584 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
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
> >>>---
>
> >>>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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
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...
(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
---
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...
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
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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi Sergei,
On Tue, Dec 23, 2014 at 04:10:44PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 12/23/2014 1:43 AM, 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.
>
> >(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
> >---
>
> >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.
>
> >Comments are welcome.
>
> >Br, David
> >---
> >
> > drivers/extcon/Kconfig | 8 ++
> > drivers/extcon/Makefile | 1 +
> > drivers/extcon/extcon-otg_gpio.c | 200
> > +++
> > 3 files changed, 209 insertions(+)
> > create mode 100644 drivers/extcon/extcon-otg_gpio.c
> >
> >diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> >index 6a1f7de6fa54..e8010cda4642 100644
> >--- a/drivers/extcon/Kconfig
> >+++ b/drivers/extcon/Kconfig
> >@@ -93,4 +93,12 @@ config EXTCON_SM5502
> > Silicon Mitus SM5502. The SM5502 is a USB port accessory
> > detector and switch.
> >
> >+config EXTCON_OTG_GPIO
> >+tristate "VIRTUAL USB OTG PORT support"
> >+depends on GPIOLIB
> >+help
> >+ Say Y here to enable support for virtual USB OTG port device
> >+ controlled by GPIOs. This driver can be used when at least USB ID pin
> >+ is connected directly to GPIO.
> >+
>
>The entries in this file seem alphabetically sorted.
I'll fix it.
>
> > endif # MULTISTATE_SWITCH
> >diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> >index 0370b42e5a27..9e81088c6584 100644
> >--- a/drivers/extcon/Makefile
> >+++ b/drivers/extcon/Makefile
> >@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> > obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
> > obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> > obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
> >+obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
>
>The lines here are sorted too.
Ditto.
>
> >diff --git a/drivers/extcon/extcon-otg_gpio.c
> >b/drivers/extcon/extcon-otg_gpio.c
> >new file mode 100644
> >index ..c5ee765a5f4f
> >--- /dev/null
> >+++ b/drivers/extcon/extcon-otg_gpio.c
> >@@ -0,0 +1,200 @@
> [...]
> >+static irqreturn_t vuport_isr(int irq, void *priv)
> >+{
> >+return IRQ_WAKE_THREAD;
> >+}
>
>It's the same as the default IRQ handler...
>
> >+ret = devm_request_threaded_irq(dev, gpiod_to_irq(vup->gpio_usb_id),
> >+vuport_isr, vuport_thread_isr,
>
>... so you probably can just pass NULL instead of vuport_isr, no?
I'll review that.
>
> [...]
>
> >+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.
Br, David
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hi Peter,
Thanks for the review.
On Tue, Dec 23, 2014 at 09:25:18AM +0800, Peter Chen wrote:
> On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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)
> > (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.
>
> Would you explain how it works? Choosing controller runtime?
Both controllers are (indirectly) connected to the same micro B port.
The D+/- goes from the port to a switch operated by a GPIO. From the
switch, D+/- may go to Host controller's phy or Device controller's phy.
Depends on the GPIO level.
>
> >
> > As per initial version, this driver has the duty to control whether
> > USB-Host cable is plugged in or not:
>
> You mean Micro-AB cable, right?
In my case I'd say micro B. But USB-Host would be any cable or
combination of cables where USB ID is grounded.
>
> > - 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
> > ---
> >
> > 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.
> >
> > Comments are welcome.
> >
> > Br, David
> > ---
> >
> > drivers/extcon/Kconfig | 8 ++
> > drivers/extcon/Makefile | 1 +
> > drivers/extcon/extcon-otg_gpio.c | 200
> > +++
> > 3 files changed, 209 insertions(+)
> > create mode 100644 drivers/extcon/extcon-otg_gpio.c
> >
> > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> > index 6a1f7de6fa54..e8010cda4642 100644
> > --- a/drivers/extcon/Kconfig
> > +++ b/drivers/extcon/Kconfig
> > @@ -93,4 +93,12 @@ config EXTCON_SM5502
> > Silicon Mitus SM5502. The SM5502 is a USB port accessory
> > detector and switch.
> >
> > +config EXTCON_OTG_GPIO
> > + tristate "VIRTUAL USB OTG PORT support"
> > + depends on GPIOLIB
> > + help
> > + Say Y here to enable support for virtual USB OTG port device
> > + controlled by GPIOs. This driver can be used when at least USB ID pin
> > + is connected directly to GPIO.
> > +
> > endif # MULTISTATE_SWITCH
> > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> > index 0370b42e5a27..9e81088c6584 100644
> > --- a/drivers/extcon/Makefile
> > +++ b/drivers/extcon/Makefile
> > @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> > obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
> > obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> > obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
> > +obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
> > diff --git a/drivers/extcon/extcon-otg_gpio.c
> > b/drivers/extcon/extcon-otg_gpio.c
> > new file mode 100644
> > index ..c5ee765a5f4f
> > --- /dev/null
> > +++ b/drivers/extcon/extcon-otg_gpio.c
> > @@ -0,0 +1,200 @@
> > +/*
> > + * Virtual USB OTG Port driver controlled by gpios
> > + *
> > + * Copyright (c) 2014, Intel Corporation.
> > + * Author: David Cohen
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRV_NAME "usb_otg_port"
> > +
> > +struct vuport {
> > + struct device *dev;
> > + struct gpio_desc *gpio_vbus_en;
> > + struct gpio_desc *gpio_usb_id;
> > + struct gpio_desc *gpio_usb_mux;
> > +
> > + struct extcon_dev edev;
> > +};
> > +
> > +static const char *const vuport_extcon_cable[] = {
> > + [0] = "USB-Host",
> > + NULL,
> > +};
> > +
> > +/*
> > + * If id == 1, USB port should be set to peripheral
> > + * if id == 0, USB port should be set to host
> > + *
> > + * Peripheral: set USB mux to peripheral and disable VBU
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
Hello.
On 12/23/2014 1:43 AM, 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?
(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
---
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.
Comments are welcome.
Br, David
---
drivers/extcon/Kconfig | 8 ++
drivers/extcon/Makefile | 1 +
drivers/extcon/extcon-otg_gpio.c | 200 +++
3 files changed, 209 insertions(+)
create mode 100644 drivers/extcon/extcon-otg_gpio.c
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de6fa54..e8010cda4642 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,12 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_OTG_GPIO
+ tristate "VIRTUAL USB OTG PORT support"
+ depends on GPIOLIB
+ help
+ Say Y here to enable support for virtual USB OTG port device
+ controlled by GPIOs. This driver can be used when at least USB ID pin
+ is connected directly to GPIO.
+
The entries in this file seem alphabetically sorted.
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42e5a27..9e81088c6584 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
+obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
The lines here are sorted too.
diff --git a/drivers/extcon/extcon-otg_gpio.c b/drivers/extcon/extcon-otg_gpio.c
new file mode 100644
index ..c5ee765a5f4f
--- /dev/null
+++ b/drivers/extcon/extcon-otg_gpio.c
@@ -0,0 +1,200 @@
[...]
+static irqreturn_t vuport_isr(int irq, void *priv)
+{
+ return IRQ_WAKE_THREAD;
+}
It's the same as the default IRQ handler...
+ ret = devm_request_threaded_irq(dev, gpiod_to_irq(vup->gpio_usb_id),
+ vuport_isr, vuport_thread_isr,
... so you probably can just pass NULL instead of vuport_isr, no?
[...]
+static int __init vuport_init(void)
+{
+ return platform_driver_register(&vuport_driver);
+}
+subsys_initcall(vuport_init);
Hm, why?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Mon, Dec 22, 2014 at 02:43:37PM -0800, 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)
> (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.
Would you explain how it works? Choosing controller runtime?
>
> As per initial version, this driver has the duty to control whether
> USB-Host cable is plugged in or not:
You mean Micro-AB cable, right?
> - 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
> ---
>
> 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.
>
> Comments are welcome.
>
> Br, David
> ---
>
> drivers/extcon/Kconfig | 8 ++
> drivers/extcon/Makefile | 1 +
> drivers/extcon/extcon-otg_gpio.c | 200
> +++
> 3 files changed, 209 insertions(+)
> create mode 100644 drivers/extcon/extcon-otg_gpio.c
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de6fa54..e8010cda4642 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -93,4 +93,12 @@ config EXTCON_SM5502
> Silicon Mitus SM5502. The SM5502 is a USB port accessory
> detector and switch.
>
> +config EXTCON_OTG_GPIO
> + tristate "VIRTUAL USB OTG PORT support"
> + depends on GPIOLIB
> + help
> + Say Y here to enable support for virtual USB OTG port device
> + controlled by GPIOs. This driver can be used when at least USB ID pin
> + is connected directly to GPIO.
> +
> endif # MULTISTATE_SWITCH
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42e5a27..9e81088c6584 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> +obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
> diff --git a/drivers/extcon/extcon-otg_gpio.c
> b/drivers/extcon/extcon-otg_gpio.c
> new file mode 100644
> index ..c5ee765a5f4f
> --- /dev/null
> +++ b/drivers/extcon/extcon-otg_gpio.c
> @@ -0,0 +1,200 @@
> +/*
> + * Virtual USB OTG Port driver controlled by gpios
> + *
> + * Copyright (c) 2014, Intel Corporation.
> + * Author: David Cohen
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "usb_otg_port"
> +
> +struct vuport {
> + struct device *dev;
> + struct gpio_desc *gpio_vbus_en;
> + struct gpio_desc *gpio_usb_id;
> + struct gpio_desc *gpio_usb_mux;
> +
> + struct extcon_dev edev;
> +};
> +
> +static const char *const vuport_extcon_cable[] = {
> + [0] = "USB-Host",
> + NULL,
> +};
> +
> +/*
> + * If id == 1, USB port should be set to peripheral
> + * if id == 0, USB port should be set to host
> + *
> + * Peripheral: set USB mux to peripheral and disable VBUS
> + * Host: set USB mux to host and enable VBUS
> + */
> +static void vuport_set_port(struct vuport *vup, int id)
> +{
> + int mux_val = id;
> + int vbus_val = !id;
> +
> + if (!IS_ERR(vup->gpio_usb_mux))
> + gpiod_direction_output(vup->gpio_usb_mux, mux_val);
> +
> + if (!IS_ERR(vup->gpio_vbus_en))
> + gpiod_direction_output(vup->gpio_vbus_en, vbus_val);
> +}
> +
> +static void vuport_do_usb_id(struct vuport *vup)
> +{
> + int id = gpiod_get_value(vup->gpio_usb_id);
> +
> + dev_info(vup->dev, "USB PORT ID: %s\n", id ? "PERIPHERAL" : "HOST");
dev_dbg
> +
> + /*
> + * id == 1: PERIPHERAL
> + * id == 0: HOST
> + */
>
[RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
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)
(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
---
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.
Comments are welcome.
Br, David
---
drivers/extcon/Kconfig | 8 ++
drivers/extcon/Makefile | 1 +
drivers/extcon/extcon-otg_gpio.c | 200 +++
3 files changed, 209 insertions(+)
create mode 100644 drivers/extcon/extcon-otg_gpio.c
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de6fa54..e8010cda4642 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,12 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_OTG_GPIO
+ tristate "VIRTUAL USB OTG PORT support"
+ depends on GPIOLIB
+ help
+ Say Y here to enable support for virtual USB OTG port device
+ controlled by GPIOs. This driver can be used when at least USB ID pin
+ is connected directly to GPIO.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42e5a27..9e81088c6584 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
diff --git a/drivers/extcon/extcon-otg_gpio.c b/drivers/extcon/extcon-otg_gpio.c
new file mode 100644
index ..c5ee765a5f4f
--- /dev/null
+++ b/drivers/extcon/extcon-otg_gpio.c
@@ -0,0 +1,200 @@
+/*
+ * Virtual USB OTG Port driver controlled by gpios
+ *
+ * Copyright (c) 2014, Intel Corporation.
+ * Author: David Cohen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "usb_otg_port"
+
+struct vuport {
+ struct device *dev;
+ struct gpio_desc *gpio_vbus_en;
+ struct gpio_desc *gpio_usb_id;
+ struct gpio_desc *gpio_usb_mux;
+
+ struct extcon_dev edev;
+};
+
+static const char *const vuport_extcon_cable[] = {
+ [0] = "USB-Host",
+ NULL,
+};
+
+/*
+ * If id == 1, USB port should be set to peripheral
+ * if id == 0, USB port should be set to host
+ *
+ * Peripheral: set USB mux to peripheral and disable VBUS
+ * Host: set USB mux to host and enable VBUS
+ */
+static void vuport_set_port(struct vuport *vup, int id)
+{
+ int mux_val = id;
+ int vbus_val = !id;
+
+ if (!IS_ERR(vup->gpio_usb_mux))
+ gpiod_direction_output(vup->gpio_usb_mux, mux_val);
+
+ if (!IS_ERR(vup->gpio_vbus_en))
+ gpiod_direction_output(vup->gpio_vbus_en, vbus_val);
+}
+
+static void vuport_do_usb_id(struct vuport *vup)
+{
+ int id = gpiod_get_value(vup->gpio_usb_id);
+
+ dev_info(vup->dev, "USB PORT ID: %s\n", id ? "PERIPHERAL" : "HOST");
+
+ /*
+* id == 1: PERIPHERAL
+* id == 0: HOST
+*/
+ vuport_set_port(vup, id);
+
+ /*
+* id == 0: HOST connected
+* id == 1: Host disconnected
+*/
+ extcon_set_cable_state(&vup->edev, "USB-Host", !id);
+}
+
+static irqreturn_t vuport_thread_isr(int irq, void *priv)
+{
+ struct vuport *vup = priv;
+
+ vuport_do_usb_id(vup);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t vuport_isr(int irq, void *
