[RFC PATCH 0/4] Implement USB device/host switch for Vybrid

[Sanchayan Maity]

Hello Peter,

The existing usage of extcon in Chipidea driver relies on OTG
registers. In case of SoC with dual role device but not a true
OTG controller, this does not work. Such SoC's should specify
the existing CI_HDRC_DUAL_ROLE_NOT_OTG flag and do the role
switch without checking any of the OTG registers in my opinion.
This is the case for Vybrid which uses a Chipidea IP but does
not have a true 5 pin OTG implemented.

This patch almost reverts most of commit 3ecb3e09b042e70799ff3a1ff464a5ecaa7547d9
"usb: chipidea: Use extcon framework for VBUS and ID detect".
We do not rely anymore on emulating an OTG capable controller
by faking OTG controller reads.

Observations without the following patchset with the current
implementation.

CONFIG_USB_OTG was kept selected. Just the device tree changes
done in the fourth patch of this patch were done.

1. Booting with the USB device connected and then disconnecting
on boot results in "irq 38: nobody cared (try booting with the
"irqpoll" option)" stack trace.

2. Disconnecting the USB device and reconnecting results in a
timeout error message coming ci_handle_id_switch --> hw_wait_reg
while waiting for OTGSC_BSV register field. Why rely on a read
from OTG register while using extcon?

Also, usb_gadget_vbus_connect seems not to be called, render device
mode useless (usb_gadget_vbus_connect according to my understanding
should be called through ci_vbus_notifier -> ci_irq -> ci_otg_work ->
ci_handle_vbus_change).

3. Once in a while doing the switch from host to device would
result "ci_hdrc.0 Freeing queued request" but the switch won't
be successful as expected and I wont get the following message

[ 167.298040] ci_hdrc ci_hdrc.0: USB bus 2 deregistered
[ 167.772520] configfs-gadget gadget: high-speed config #1: c

and further our RNDIS client configuration on said USB connection
won't work. Once in a while I also experience a complete freeze
if I try to ping the interface after this.

4. With the current "OTG" implementation, should the ci->lock not
be acquired before calling ci_role_stop or ci_role_start in the
code path ci_id_notifier -> ci_irq -> otg_workqueue?

Looking at the commit message this extcon was introduced for Qualcomm's
410 Dragonboard and while I did not look at Dragonboard's or 410's DS,
requirement seems similar to Vybrid.?

What are your thoughts on this? Or considering the requirement of Qualcomm
would keeping direct role switch in case of DUAL_ROLE_NOT_OTG flag
and keeping existing OTG reads would be acceptable? Currently in our tree
we keep both implementations. The 410 is a 64bit SoC but grepping arch/
arm64/boot/dts/qcom for an extcon entry I didn't find any.

Regards,
Sanchayan.

Sanchayan Maity (4):
usb: chipidea: Do not rely on OTG while using extcon
usb: chipidea: ci_hdrc_imx: Introduce CI_HDRC_DUAL_ROLE_NOT_OTG for Vybrid
ARM: dts: vfxxx: Make Vybrid match only on it's own compatible string
ARM: dts: vf-colibri: USB device/host switch using extcon gpio

arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 12 ++++++
arch/arm/boot/dts/vf-colibri.dtsi | 7 ++++
arch/arm/boot/dts/vfxxx.dtsi | 2 +-
drivers/usb/chipidea/ci_hdrc_imx.c | 5 +++
drivers/usb/chipidea/core.c | 64 +++++++++++++++++--------------
drivers/usb/chipidea/otg.c | 39 +------------------
include/linux/usb/chipidea.h | 2 -
7 files changed, 61 insertions(+), 70 deletions(-)

--
2.7.3

[Peter Chen]

On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> Hello Peter,
>
> The existing usage of extcon in Chipidea driver relies on OTG
> registers. In case of SoC with dual role device but not a true
> OTG controller, this does not work. Such SoC's should specify
> the existing CI_HDRC_DUAL_ROLE_NOT_OTG flag and do the role
> switch without checking any of the OTG registers in my opinion.
> This is the case for Vybrid which uses a Chipidea IP but does
> not have a true 5 pin OTG implemented.

Sorry to reply you late due to my new born baby.

Are you sure Vybrid is NOT OTG core? Afaik, it is uses the same
IP base with other Freescale SoCs, just the IP core is 2.40a.
When working at device mode, can you read vbus status through
OTGSC? And if there is an ID pin (input pin) for Vybrid? I mean
SoC, not the board.

--
Best Regards,
Peter Chen

[Stefan Agner]

I think the IP is actually OTG capable, the registers are there, but the
signals seem not to be available on the SoC package. That is also what
the RM says...

Quotes from the RM:

"OTG controller should be treated as
Dual role controller that allows the
controller to act as either a Host or a
device with no support for HNP/SRP."

And later, in Chapter 11.1:

"The USB is not a true OTG. It can be configured by software to function
either as
peripheral or as host. The ID pin, which is unique for OTG operation, is
not present in
this implementation. There are no five pin interface. The user will get
four pin host/
device interface."

--
Stefan

[Peter Chen]

Get it, thanks. I am doing a patch for covering this case and vbus always-on case.

Peter

[maitysa...@gmail.com]

Hello Peter,

If I may ask at this point, how would your implementation be covering this case
for Vybrid?

- Sanchayan.

[Peter Chen]

Yes, if the vbus and id status are from the extcon, it will not read register OTGSC.

Peter