lkml.org 
[lkml]   [2015]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
    On Fri, Feb 20, 2015 at 11:17:00AM -0800, David Cohen wrote:
    > Hi Linus and Robert,
    >
    > CC'ing Heikki as it involves a RFC from him.
    >
    > On Fri, Feb 20, 2015 at 10:53:44AM +0100, Linus Walleij wrote:
    > > On Fri, Feb 20, 2015 at 7:41 AM, Robert Baldyga <r.baldyga@samsung.com> wrote:
    > > > Hi David,
    > > >
    > > > On 02/19/2015 08:59 PM, David Cohen wrote:
    > > >> Some Intel platforms have an USB OTG port fully (or partially)
    > > >> controlled by GPIOs:
    > > >>
    > > >> (1) USB ID is connected directly to a pulled up GPIO.
    > > >>
    > > >> Optionally:
    > > >> (2) VBUS is enabled/disabled by a GPIO
    > > >> (3) Platform has 2 USB controllers connected to same port: one for
    > > >> device and one for host role. D+/- are switched between phys.
    > > >> according to this GPIO level.
    > > >>
    > > >> This driver configures USB OTG port for device or host role according to
    > > >> USB ID value.
    > > >> - If USB ID's GPIO level is low, OTG port is configured for host role
    > > >> by sourcing VBUS and switching D+/- to host phy.
    > > >> - If USB ID's GPIO level is high, by standard, the OTG port is
    > > >> configured for device role by not sourcing VBUS and switching D+/- to
    > > >> device controller.
    > > >
    > > > IMO it's not very elegant to handle VBUS power on/off in extcon driver.
    > > > Creating fixed regulator would allow to make VBUS handling more generic.
    >
    > I agree. But please, see below.
    >
    > >
    > > IMHO it's just layers of abstraction piled on top of each other here.
    > >
    > > I would put this adjacent to the phy driver somewhere in drivers/usb/*
    > > and make the actual USB-driver thing handle its GPIOs directly.
    > > But I guess David and Felipe have already discussed that as we're
    > > seeing this patch?
    >
    > Felipe suggested to "divide to conquer" instead of having a single
    > extcon driver to handle all these functions:
    >
    > - The mux functions would be controlled by a possible new pinctrl-gpio
    > driver (Linus, your input here would be nice :)
    > - The VBUS would be a fixed regulator
    > - The USB ID would make usage of existent extcon-gpio
    >
    > But the on fw side, this is a single ACPI device representing a virtual
    > device for USB OTG port, which is nothing but a bunch of independent
    > GPIOs.
    >
    > I could make a mfd driver to register devices for those simpler and more
    > generic drivers, but according to [1] community recognized it as a hack
    > with ACPI since I'd need to give them the GPIO without requesting on
    > mfd.
    >
    > I'm open for suggestions :)

    use MFD to create children devices and pass the required data to each
    one ?

    --
    balbi
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2015-02-20 21:01    [W:4.968 / U:0.432 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site