[RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

[Stephen Boyd]

Quoting Peter Chen (2016-09-15 02:01:58)
> On Wed, Sep 14, 2016 at 01:45:04AM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-14 01:03:21)
> > > On Tue, Sep 13, 2016 at 10:58:26PM -0700, Stephen Boyd wrote:
> > > > Quoting Peter Chen (2016-09-13 20:32:00)
> > > > > On Tue, Sep 13, 2016 at 06:42:46PM -0700, Stephen Boyd wrote:
> > > > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > > > we need to change this mux to forward the D+/D- lines to either
> > > > > > the port or the hub. Therefore, introduce a driver for this
> > > > > > device that intercepts extcon USB_HOST events and logically
> > > > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > > > attached. When the cable goes away, it will logically deassert
> > > > > > the gpio and mux the "device" lines.
> > > > > 
> > > > > Would you please draw the design? It can also help me review your
> > > > > chipidea patch well.
> > > > > 
> > > > > 1. How many ports on the board?
> > > > > 2. How the lines are connected on the board?
> > > > > 
> > > > 
> > > > The schematic for the db410c is publically available here[2][3].
> > > > 
> > > > There's also the 96boards spec[4] which talks about this switch based
> > > > design a little bit. See the section titled "Single USB port Example".
> > > > 
> > > > [2] https://github.com/96boards/documentation/blob/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf
> > > > [3] https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf
> > > > [4] https://www.96boards.org/wp-content/uploads/2015/02/96BoardsCESpecificationv1.0-EA1.pdf
> > > 
> > > Ok, I see several use cases for this role switch
> > > 
> > > 1. Using the hardware switch (218-4LPST)
> > > In this case, you can set USB_SW_SEL as input gpio, and use
> > > extcon-usb-gpio.c like before, just set this gpio as active
> > > low at dts.
> > 
> > Nice! I didn't think of this case but it's good that we can support
> > that with some work.
> > 
> 
> After looking more, I find the main purpose of this switch is
> what it writes, FORCE DSI SELECTION TO USB HOST MODE
> 
> When the switch is on, the system is host-only.
> When the switch is off, the default role is device mode, and
> switch the role through gpio USB_SW_SEL_PM by software.

Correct.

> 
> > > 
> > > 2. Using USB_HS_ID as vbus-gpio (input), and USB_SW_SEL as id-gpio (output)
> > 
> > This is pretty much what has been implemented. USB_HS_ID is an
> > extcon-usb-gpio.c device.
> 
> At some designs, this gpio is tied to ID pin at MicroB connector, and
> using a Mirco-AB cable to switch the role.
> 
> > 
> > > I can't find hardware relationship between each other, maybe I miss
> > > something.
> > 
> > I believe USB_SW_SEL is the physical switch (218-4LPST) while
> > USB_SW_SEL_PM is the software controllable part using a GPIO. USB_HS_ID
> > is just the vbus line from the uB connector and that line goes straight
> > into the SoC via a GPIO.
> > 
> > > This use case (design) seems strange, usually, we use ID pin controls
> > > vbus, but seldom use vbus pin control ID.
> > > How you would like to implement it? When the USB cable is connected
> > > (between PC), it receives vbus-gpio interrupt, then you set USB_SW_SEL
> > > as low? If disconnected, you set USB_SW_SEL as high?
> > 
> > Right. The documented behavior is to detect the micro-usb cable and
> > drive USB_SW_SEL low. When the cable is unplugged we drive USB_SW_SEL
> > high. Maybe that should be changed though? If we always sampled
> > USB_SW_SEL as a USB_HOST extcon and the vbus line as a USB extcon then
> > we could allow the user to decide either with the physical switch or
> > with some sort of software control to toggle that gpio.
> > 
> > > When the USB controller works at Host mode, what will happen if the user
> > > connects USB cable at device port?
> > 
> > The devices on the two type-A connectors will be disconnected and we'll
> > switch from host mode to device mode.
> > 
> > > 
> > > 3. Using sysfs to switch the role
> > > Set USB_SW_SEL according to "role" at debugfs
> > 
> > sysfs isn't debugfs, but yes I wonder if we need to worry about the
> > debugfs role switching support here and toggle the gpio manually without
> > involving extcon. That would mean we need to have a way for the chipidea
> > controller to toggle this gpio/mux itself.
> > 
> > > 
> > > Which one you would like to implement? Or anything else I miss?
> > > 
> > 
> > Mostly #2, but I'm concerned that the DT binding is going to force that
> > decision on others who may have the same switch and want to do #1 or #3.
> > So how to design it in a way that makes it work in all cases? Also, what
> > to do if the USB_SW_SEL switch is driven high by the physical switch?
> > That will "override" any software control we might be able to use, so
> > hopefully we can detect this somehow and prevent the role switch from
> > happening.
> 
> From my point, the physical switch is only used to force host mode. The
> #1 and #2 can't be supported at the same time.

Sure. I mean to say support all use cases with the same DT binding.

> For #3, it is not the
> use case for this design. #3 is usually used for the single port which
> needs to support switching role on the fly without disconnection.
> So, you may only need to consider #2, you can't use extcon-usb-gpio.c
> directly since you need to set one gpio to mux the dp/dm, Baolu Lu had
> USB MUX patch set before which may satisfy your requirement. [1]

Ok. Did the usb mux patches go anywhere? It seemed to get tangled up in
DRD framework and I haven't been following along. I'll look into these
patches more.