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

[Roger Quadros <rogerq@ti.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3042 bytes --]

On 07/06/16 16:04, Felipe Balbi wrote:
> 
> 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.

What you are proposing is a dwc3 only solution. With the otg/dual-role
series we are trying to be generic as much as possible.
Whether controller drivers want to use it or not is upto the driver maintainers
but we should at least ensure that user space ABI if any, is consistent
across different implementations.

> 
>> 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

Isn't that unnecessary waste of power? Or you have firmware assisted
low power mode?

> 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.
> 

Probably irrelevant for Intel's dual-role but many platforms that share
the port can't have device controller running when port is in host mode and vice versa. 
So there has to be a central point of control where the respective controllers
are started/stopped.
That is the other point we are trying to address with the common
otg/dual-role code.

Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we need
to stop the host controller for device mode, right?

If so then who will deal with start/stop of the controllers then?

So for Intel port-mux case it seems that OTG/dual-role is overcomplicated
and I wouldn't force you to use it. It is upto Peter to decide how he wants
dual-role users to behave.

cheers,
-roger


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]