Hi Felipe,

On 22/06/16 09:56, Felipe Balbi wrote:

Hi,

Peter Chen [off-list ref] writes:

quoted

quoted

Peter Chen [off-list ref] writes:

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.

quoted

quoted

quoted

quoted

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.

Okay, we have two scenarios here:

1. You need full OTG compliance

	For this, granted, you need the state machine if your HW doesn't
	track it. This is a given. With only one user, however, perhaps
	we don't need a generic layer. There are not enough different
	setups to design a good enough generic layer. We will end up
	with a pseudo-generic framework which is coupled with its only
	user.

2. Dual-role support, without OTG compliance

	In this case, you don't need a stack. All you need is a signal
	to tell you state of ID pin and another to tell you state of
	VBUS level. If you have those, you don't need to walk an OTG
	state machine at all. You don't need any of those quirky OTG
	timers, agreed?

	Given the above, why would you even want to use a subset of OTG
	state machine to implement something that's _usually_ as simple
	as:

8<----------------------------------------------------------------------
	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
        id = read(ID_STATE); /* could be a gpio_get_value() */

        set_role(id);
        set_vbus(vbus);
------------------------------------------------------------------------

In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

What do you mean by same driver?
Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can be 3 totally
independent drivers unlike dwc3 where you have a single driver in control of
both host and gadget.

Questions not clear to me are:
1) Which driver handles ID/VBUS events and makes a decision to do the role swap?
Probably the PHY/MUX driver?
2) How does it perform the role swap? Probably a register write to the PHY/MUX
without needing to stop/start controllers? Easy case is both controllers can
run in co-existence without interference. Is there any platform other than dwc3
where this is not the case?
3) Even if host and gadget controllers can operate in coexistence, there is no need for
both to be running for embedded applications which are usually power conservative.
How can we achieve that?

quoted

quoted

quoted

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?

You don't really need to remove the gadget. Just mask its interrupts and
ignore any calls to any gadget_driver ops, right? Likewise for
XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
the point of view of dwc3, it's simpler to unregister the platform
device we create for xhci-plat.c. I need no changes in XHCI to do that
and driver model will make sure to call xhci-plat's ->remove() which
will handle everything for me correctly.

I admit it can do in a IP driver, eg both host and peripheral for the
single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
or what else for HCD at mux driver?

dwc3's OTG block has control of that, however, what I'll do is
platform_device_del() xhci-plat's device. Not one line changes inside
XHCI.

Let's talk about how non dwc3 based platforms can get it done.

Yoshihiro-san, could you please share your platform requirements from dual-role
perspective?

cheers,
-roger