On Tue, Jun 21, 2016 at 10:26:00AM +0300, Felipe Balbi wrote:

Hi,

quoted

quoted

So far, I haven't seen anybody talking about real USB OTG (the spec)
when they say OTG. Usually they just mean "a method for swapping between
host and peripheral roles, but we really don't want all the extra cost
of the OTG specification".

That's what I thought before, but the request from the Marketing guy is
"To prove the SoC is OTG compliance, support HNP and SRP", don't you
see the SoC reference manual say "it supports HNP and SRP"?

If there is no request, who else wants to implement so complicated FSM
but seldom use cases, and go to pass OTG compliance test (tested by PET).

I stand corrected :-)

So there is one user for this layer. And this user has its own role
control registers. I'm not convinced we need this large generic layer
for one user.

You mean chipidea or dwc3? I have more comments below.

quoted

quoted

quoted

For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.

Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

quoted

Notice, it needs to swap role without disconnect cable.

right, I can swap role without changing cable, but that's not OTG. The
mechanism for that, AFAICT, is not HNP. I don't know details about
CarPlay because the spec isn't public, but my understanding is that
CarPlay doesn't rely on anything from OTG spec.

Since it is non-public, I can't say much. Some flows of its role-swap
refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification. 

But OTG FSM is not the only way, the platform which can do role-swap
without disconnection can support it too.

quoted

quoted

quoted

quoted

quoted

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index f4fc0aa..1d74fb8 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h

@@ -328,6 +328,7 @@ struct usb_gadget_ops {
  * @in_epnum: last used in ep number
  * @mA: last set mA value
  * @otg_caps: OTG capabilities of this gadget.
+ * @otg_dev: OTG controller device, if needs to be used with OTG core.

do you really know of any platform which has a separate OTG controller?

It may not be a real separate OTG controller. It can be a hardware part
(external connector, external IC, SoC OTG register area, etc) to handle vbus
,id and other signals which are used for role swap.

That's already solved. EXTCON solved that years back and OMAP has been
using EXTCON to program its UTMI mailbox.

No, that's not the same thing, it does not include the swap role.

Read your original comment:

"handle vbus, id and other signals which are *used for* role swap"

You didn't include role swap in your original comment. Semantics aside...

quoted

Consider the use case the host driver is at host/ and udc driver is
at gadget/udc, how to finish to role swap?

... why does the source code placement matter? And what do you mean by
"finish role swap"?

Well, it depends on your driver design, do you want the host driver's
API is still be called when current role is peripheral? One typical
problem you can refer below:

commit 11c011a5e777c83819078a18672543f04482b3ec
Author: Srinivas Kandagatla [off-list ref]
Date:   Thu May 19 11:12:56 2016 +0100

    usb: echi-hcd: Add ehci_setup check before echi_shutdown
        


In some cases, the USB code (gadget/hcd->start/stop) needs to be called
during the role swap. For example, if you have mux driver, you may
need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
how can we do that?

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html