Hi,

Peter Chen [off-list ref] writes:

quoted

quoted

quoted

quoted

quoted

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.

chipidea. From the point of OTG (or DRD) dwc3 is very
self-sufficient. HW itself tracks state machine, much like MUSB does.

You mean HW can do state machine switch? If we are A device,
- Does the hardware knows if B device is HNP enabled or not?

that's enabled through control message, keep a flag.

quoted

- And if B device is HNP enabled, does it can switch itself from host
to peripheral when the B device is disconnected (a_suspend->a_peripheral)

It cannot. It must rely on hnp polling which is, again, a control message.

quoted

Does hardware can really follow Figure 7-1: OTG A-device with HNP State
Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification? And can pass PET test?

Seriously, what does this add to the conversation? It has already been
stated that there's nobody asking for OTG certification on dwc3. So all
of this is vaporware from the point of view of dwc3.

This is just a technical question that I can't understand your words
"HW itself tracks state machine"?

It's simple, really: HW knows that it starts in B_IDLE. All automatic
state changes, HW will do:

B_IDLE -> A_IDLE -> A_WAIT_VRISE -> A_WAIT_BCON -> A_HOST
B_IDLE -> B_WAIT_ACON -> B_PERIPHERAL

Some state changes need SW intervention, for those you need to kick the
correct event so HW makes the state change. But register will still tell
you correct state after HW switches to it.

-- 
balbi