Hi, Roger Quadros <rogerq@xxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
