Messages in this thread | | | From | Felipe Balbi <> | Subject | Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux | Date | Tue, 07 Jun 2016 16:04:27 +0300 |
| |
Hi,
Roger Quadros <rogerq@ti.com> writes: >> But you said I must run an unnecessary OTG state machine, even thought it >> has nothing to do with my system, only because the two sides of my port >> mux device is a host and peripheral controller. > > We have a minimal dual-role state machine that just looks at ID pin > and toggles the port role.
I don't know if we want to bring all that extra baggage just to write a few bits in a single register. Even for DWC3-only dual-role (what Synopsys licenses as part of some DWC3 instantiations), the OTG/DRD layer is a bit overkill.
If you take my testing/next, for example, we have everything we need for dual-role; except for OTG/DRD IRQ handler. Just look at how we implement ->suspend()/->resume() and it's be clear that we're just missing one step.
I might be able to find some time to implement a proof of concept which would allow your platforms to get dual-role with code we already have, but I need DWC3's OTG support which, I'm assuming, you already have :-)
If you wanna try something offline, just ping me ;-) I'll be happy to help.
> How are you switching the port mux between host and peripheral? Only > by sysfs or do you have a GPIO for ID pin as well?
depends. Some SoCs have GPIO-controller muxes while some just have mux's select signals (one for ID, one for VBUS) mapped on xHCI's address space.
> What happens to the gadget controller when the port is muxed to the > host controller? Is it stopped or it continues to run?
it continues running, but that's pretty irrelevant for Intel's dual-role setup. We have an actual physical (inside the die, though) mux which muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only DWC3.
-- balbi [unhandled content-type:application/pgp-signature]
| |