Hi Roger-san,

< snip >

quoted

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?

My platform requirements about dual-role are:
- Initial settings of all host, gadget and OTG IP registers are needed before enters [AB]-device recognition procedure.
- In the recognition procedures, a software needs:
 - to check ID pin related register in OTG
 - to set OTG IP registers to change the role
  - and then host or gadget can start.
- In the disconnect detection procedures, a software needs similar checkings/settings with the recognition.

Best regards,
Yoshihiro Shimoda

cheers,
-roger

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