Implement USB device/host switch for Vybrid

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.

This patch almost reverts most of commit "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.

Signed-off-by Sanchayan Maity <[email protected]>

---
 drivers/usb/chipidea/core.c  | 64 ++++++++++++++++++++++++--------------------
 drivers/usb/chipidea/otg.c   | 39 +--------------------------
 include/linux/usb/chipidea.h |  2 --
 3 files changed, 36 insertions(+), 69 deletions(-)

drivers/usb/chipidea/core.c +23 -25

index 7404064..d29118d 100644
@@ -607,14 +607,15 @@ static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
 	struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
 	struct ci_hdrc *ci = vbus->ci;
 
+	pm_runtime_get_sync(ci->dev);
+
 	if (event)
-		vbus->state = true;
+		usb_gadget_vbus_connect(&ci->gadget);
 	else
-		vbus->state = false;
+		usb_gadget_vbus_disconnect(&ci->gadget);
 
-	vbus->changed = true;
+	pm_runtime_put_sync(ci->dev);
 
-	ci_irq(ci->irq, ci);
 	return NOTIFY_DONE;
 }
 

@@ -624,14 +625,19 @@ static int ci_id_notifier(struct notifier_block *nb, unsigned long event,
 	struct ci_hdrc_cable *id = container_of(nb, struct ci_hdrc_cable, nb);
 	struct ci_hdrc *ci = id->ci;
 
-	if (event)
-		id->state = false;
-	else
-		id->state = true;
+	pm_runtime_get_sync(ci->dev);
+
+	ci_role_stop(ci);
+
+	hw_wait_phy_stable();
+
+	if (ci_role_start(ci, event ? CI_ROLE_HOST : CI_ROLE_GADGET))
+		dev_err(ci->dev,
+			"Can't start %s role\n",
+			event ? "host" : "gadget");
 
-	id->changed = true;
+	pm_runtime_put_sync(ci->dev);
 
-	ci_irq(ci->irq, ci);
 	return NOTIFY_DONE;
 }
 

@@ -738,25 +744,10 @@ static int ci_get_platdata(struct device *dev,
 	cable->nb.notifier_call = ci_vbus_notifier;
 	cable->edev = ext_vbus;
 
-	if (!IS_ERR(ext_vbus)) {
-		ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
-		if (ret)
-			cable->state = true;
-		else
-			cable->state = false;
-	}
-
 	cable = &platdata->id_extcon;
 	cable->nb.notifier_call = ci_id_notifier;
 	cable->edev = ext_id;
 
-	if (!IS_ERR(ext_id)) {
-		ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
-		if (ret)
-			cable->state = false;
-		else
-			cable->state = true;
-	}
 	return 0;
 }
 

@@ -896,6 +887,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	void __iomem	*base;
 	int		ret;
 	enum usb_dr_mode dr_mode;
+	struct ci_hdrc_cable *cable;
 
 	if (!dev_get_platdata(dev)) {
 		dev_err(dev, "platform data missing\n");

@@ -963,6 +955,12 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 	ci_get_otg_capable(ci);
 
+	ret = ci_extcon_register(ci);
+	if (ret) {
+		dev_err(dev, "extcon registration failed\n");
+		goto deinit_phy;
+	}
+
 	dr_mode = ci->platdata->dr_mode;
 	/* initialize role(s) before the interrupt is requested */
 	if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {

drivers/usb/chipidea/core.c +3 -0

+						"USB-HOST") == true)
+					ci->role = CI_ROLE_HOST;
+			}
 		}
 	} else {
 		ci->role = ci->roles[CI_ROLE_HOST]

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.

Quoted 9 lines · 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.

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.

Quoted 11 lines · Sanchayan Maity

Quoted 9 lines

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.

Quoted 7 lines

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.

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

Quoted 34 lines · Peter Chen

Quoted 11 lines · Sanchayan Maity

Quoted 9 lines

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.

Quoted 7 lines

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.

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:

Quoted 5 lines

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

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

Quoted 16 lines

Quoted 16 lines · Peter Chen

Quoted 13 lines · Sanchayan Maity

Quoted 9 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

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.

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

Quoted 7 lines

Quoted 7 lines

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

Quoted 6 lines

Quoted 6 lines

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

Quoted 3 lines

Quoted 1 line

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

case.

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