Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Felipe Balbi <felipe.balbi@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]