Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1392163 > unrolled thread

[PATCH v7 00/14] USB OTG/dual-role framework

Back to article view | Back to linux.kernel

Contents

  [PATCH v7 00/14] USB OTG/dual-role framework Roger Quadros <rogerq@ti.com> - 2016-05-02 14:20 +0200
    [PATCH v7 02/14] usb: otg-fsm: Prevent build warning "VDBG" redefined Roger Quadros <rogerq@ti.com> - 2016-05-02 14:20 +0200
      Re: [PATCH v7 02/14] usb: otg-fsm: Prevent build warning "VDBG"  redefined Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 10:30 +0200
    [PATCH v7 07/14] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 07/14] usb: otg: get rid of CONFIG_USB_OTG_FSM in  favour of CONFIG_USB_OTG Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 10:40 +0200
    [PATCH v7 09/14] usb: of: add an API to get OTG device from USB controller node Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 09/14] usb: of: add an API to get OTG device from USB  controller node Rob Herring <robh@kernel.org> - 2016-05-04 15:20 +0200
      Re: [PATCH v7 09/14] usb: of: add an API to get OTG device from USB  controller node Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 10:50 +0200
        Re: [PATCH v7 09/14] usb: of: add an API to get OTG device from USB  controller node Roger Quadros <rogerq@ti.com> - 2016-05-11 13:10 +0200
    [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG() Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG() Peter Chen <hzpeterchen@gmail.com> - 2016-05-06 11:20 +0200
        Re: [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG() Roger Quadros <rogerq@ti.com> - 2016-05-09 11:50 +0200
          Re: [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG() Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 11:00 +0200
    [PATCH v7 14/14] usb: host: xhci-plat: Add otg device to platform data Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 14/14] usb: host: xhci-plat: Add otg device to  platform data Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 11:10 +0200
    [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Peter Chen <hzpeterchen@gmail.com> - 2016-05-06 11:50 +0200
        Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Roger Quadros <rogerq@ti.com> - 2016-05-09 11:50 +0200
          Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Peter Chen <hzpeterchen@gmail.com> - 2016-05-10 05:30 +0200
            Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Roger Quadros <rogerq@ti.com> - 2016-05-10 09:40 +0200
              Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Felipe Balbi <balbi@kernel.org> - 2016-05-10 10:20 +0200
                Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Roger Quadros <rogerq@ti.com> - 2016-05-10 11:20 +0200
              RE: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Jun Li <jun.li@nxp.com> - 2016-05-10 10:20 +0200
                Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Roger Quadros <rogerq@ti.com> - 2016-05-10 11:30 +0200
                  Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 08:30 +0200
    [PATCH v7 12/14] usb: hcd: Adapt to OTG core Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 12/14] usb: hcd: Adapt to OTG core Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 11:10 +0200
    [PATCH v7 01/14] usb: hcd: Initialize hcd->flags to 0 Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 01/14] usb: hcd: Initialize hcd->flags to 0 Peter Chen <hzpeterchen@gmail.com> - 2016-05-06 11:20 +0200
    [PATCH v7 06/14] usb: gadget.h: Add OTG to gadget interface Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
    [PATCH v7 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 10:50 +0200
        Re: [PATCH v7 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-05-11 13:10 +0200
    [PATCH v7 13/14] usb: gadget: udc: adapt to OTG core Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
    [PATCH v7 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations  into usb_otg->hcd_ops Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 08:20 +0200
        Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations  into usb_otg->hcd_ops Roger Quadros <rogerq@ti.com> - 2016-05-11 13:10 +0200
          Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations  into usb_otg->hcd_ops Roger Quadros <rogerq@ti.com> - 2016-05-11 14:40 +0200
            Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations  into usb_otg->hcd_ops Peter Chen <hzpeterchen@gmail.com> - 2016-05-12 10:30 +0200
              Re: [PATCH v7 05/14] usb: otg-fsm: move host controller operations  into usb_otg->hcd_ops Roger Quadros <rogerq@ti.com> - 2016-05-12 10:40 +0200
    [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-02 14:30 +0200
      Re: [PATCH v7 10/14] usb: otg: add hcd companion support Rob Herring <robh@kernel.org> - 2016-05-04 15:20 +0200
        Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-04 15:50 +0200
          Re: [PATCH v7 10/14] usb: otg: add hcd companion support Rob Herring <robh@kernel.org> - 2016-05-11 16:00 +0200
            Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-11 16:20 +0200
              Re: [PATCH v7 10/14] usb: otg: add hcd companion support Alan Stern <stern@rowland.harvard.edu> - 2016-05-11 16:50 +0200
                RE: [PATCH v7 10/14] usb: otg: add hcd companion support Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> - 2016-05-12 06:10 +0200
                  Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-12 10:40 +0200
                    Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-12 11:40 +0200
                      RE: [PATCH v7 10/14] usb: otg: add hcd companion support Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> - 2016-05-12 12:40 +0200
                        Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-12 14:20 +0200
                          Re: [PATCH v7 10/14] usb: otg: add hcd companion support Peter Chen <hzpeterchen@gmail.com> - 2016-05-16 04:30 +0200
                            Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-16 10:10 +0200
                              Re: [PATCH v7 10/14] usb: otg: add hcd companion support Peter Chen <hzpeterchen@gmail.com> - 2016-05-16 10:30 +0200
                                Re: [PATCH v7 10/14] usb: otg: add hcd companion support Roger Quadros <rogerq@ti.com> - 2016-05-16 10:40 +0200
                  RE: [PATCH v7 10/14] usb: otg: add hcd companion support Alan Stern <stern@rowland.harvard.edu> - 2016-05-12 20:20 +0200
      Re: [PATCH v7 10/14] usb: otg: add hcd companion support Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 11:00 +0200
    Re: [PATCH v7 00/14] USB OTG/dual-role framework Peter Chen <hzpeterchen@gmail.com> - 2016-05-11 10:50 +0200
      Re: [PATCH v7 00/14] USB OTG/dual-role framework Roger Quadros <rogerq@ti.com> - 2016-05-11 13:10 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1392180 — [PATCH v7 10/14] usb: otg: add hcd companion support

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

Since some host controller (e.g. EHCI) needs a companion host controller
(e.g. OHCI), this patch adds such a configuration to use it in the OTG
core.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 Documentation/devicetree/bindings/usb/generic.txt |  3 +++
 drivers/usb/common/usb-otg.c                      | 32 ++++++++++++++++-------
 include/linux/usb/otg.h                           |  7 ++++-
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
index f6866c1..1db1c33 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -27,6 +27,9 @@ Optional properties:
  - otg-controller: phandle to otg controller. Host or gadget controllers can
 			contain this property to link it to a particular OTG
 			controller.
+ - hcd-needs-companion: must be present if otg controller is dealing with
+			EHCI host controller that needs a companion OHCI host
+			controller.
 
 This is an attribute to a USB controller such as:
 
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 702bca8..77048aa 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -20,6 +20,7 @@
 #include <linux/list.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/usb/of.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/gadget.h>
 #include <linux/workqueue.h>
@@ -582,6 +583,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
 	else
 		INIT_WORK(&otg->work, usb_drd_work);
 
+	if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
+	    config->hcd_needs_companion)	/* needs companion ? */
+		otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
+
 	otg->wq = create_singlethread_workqueue("usb_otg");
 	if (!otg->wq) {
 		dev_err(dev, "otg: %s: can't create workqueue\n",
@@ -805,15 +810,18 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
 	/* HCD will be started by OTG fsm when needed */
 	mutex_lock(&otg->fsm.lock);
 	if (otg->primary_hcd.hcd) {
-		/* probably a shared HCD ? */
-		if (usb_otg_hcd_is_primary_hcd(hcd)) {
+		/* probably a shared HCD or a companion OHCI HCD ? */
+		if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+		    usb_otg_hcd_is_primary_hcd(hcd)) {
 			dev_err(otg_dev, "otg: primary host already registered\n");
 			goto err;
 		}
 
-		if (hcd->shared_hcd == otg->primary_hcd.hcd) {
+		if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
+		    (hcd->shared_hcd == otg->primary_hcd.hcd)) {
 			if (otg->shared_hcd.hcd) {
-				dev_err(otg_dev, "otg: shared host already registered\n");
+				dev_err(otg_dev,
+					"otg: shared/companion host already registered\n");
 				goto err;
 			}
 
@@ -821,10 +829,12 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
 			otg->shared_hcd.irqnum = irqnum;
 			otg->shared_hcd.irqflags = irqflags;
 			otg->shared_hcd.ops = ops;
-			dev_info(otg_dev, "otg: shared host %s registered\n",
+			dev_info(otg_dev,
+				 "otg: shared/companion host %s registered\n",
 				 dev_name(hcd->self.controller));
 		} else {
-			dev_err(otg_dev, "otg: invalid shared host %s\n",
+			dev_err(otg_dev,
+				"otg: invalid shared/companion host %s\n",
 				dev_name(hcd->self.controller));
 			goto err;
 		}
@@ -847,14 +857,17 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
 	 * we're ready only if we have shared HCD
 	 * or we don't need shared HCD.
 	 */
-	if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
+	if (otg->shared_hcd.hcd ||
+	    (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+	     !otg->primary_hcd.hcd->shared_hcd)) {
 		otg->host = hcd_to_bus(hcd);
 		/* FIXME: set bus->otg_port if this is true OTG port with HNP */
 
 		/* start FSM */
 		usb_otg_start_fsm(otg);
 	} else {
-		dev_dbg(otg_dev, "otg: can't start till shared host registers\n");
+		dev_dbg(otg_dev,
+			"otg: can't start till shared/companion host registers\n");
 	}
 
 	mutex_unlock(&otg->fsm.lock);
@@ -905,7 +918,8 @@ int usb_otg_unregister_hcd(struct usb_hcd *hcd)
 			 dev_name(hcd_dev));
 	} else if (hcd == otg->shared_hcd.hcd) {
 		otg->shared_hcd.hcd = NULL;
-		dev_info(otg_dev, "otg: shared host %s unregistered\n",
+		dev_info(otg_dev,
+			 "otg: shared/companion host %s unregistered\n",
 			 dev_name(hcd_dev));
 	} else {
 		dev_err(otg_dev, "otg: host %s wasn't registered with otg\n",
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index b094352..6f4ca77 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -57,7 +57,8 @@ struct otg_hcd {
  * @list: list of otg controllers
  * @work: otg state machine work
  * @wq: otg state machine work queue
- * @flags: to track if host/gadget is running
+ * @flags: to track if host/gadget is running, or to indicate if hcd needs
+ *	   companion
  */
 struct usb_otg {
 	u8			default_a;
@@ -84,6 +85,7 @@ struct usb_otg {
 	u32 flags;
 #define OTG_FLAG_GADGET_RUNNING (1 << 0)
 #define OTG_FLAG_HOST_RUNNING (1 << 1)
+#define OTG_FLAG_HCD_NEEDS_COMPANION (1 << 2)
 	/* use otg->fsm.lock for serializing access */
 
 /*------------- deprecated interface -----------------------------*/
@@ -125,11 +127,14 @@ struct usb_otg_caps {
  * @caps: otg capabilities of the controller
  * @ops: otg fsm operations
  * @otg_work: optional custom otg state machine work function
+ * @hcd_needs_companion: Indicates if host controller needs a companion
+ *			 controller
  */
 struct usb_otg_config {
 	struct usb_otg_caps *otg_caps;
 	struct otg_fsm_ops *fsm_ops;
 	void (*otg_work)(struct work_struct *work);
+	bool hcd_needs_companion;
 };
 
 extern const char *usb_otg_state_string(enum usb_otg_state state);
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1394279 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote:
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> 
> Since some host controller (e.g. EHCI) needs a companion host controller
> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> core.
> 
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
>  drivers/usb/common/usb-otg.c                      | 32 ++++++++++++++++-------
>  include/linux/usb/otg.h                           |  7 ++++-
>  3 files changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> index f6866c1..1db1c33 100644
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> @@ -27,6 +27,9 @@ Optional properties:
>   - otg-controller: phandle to otg controller. Host or gadget controllers can
>  			contain this property to link it to a particular OTG
>  			controller.
> + - hcd-needs-companion: must be present if otg controller is dealing with
> +			EHCI host controller that needs a companion OHCI host
> +			controller.

Don't you need to have a link to the companion controller node?

>  
>  This is an attribute to a USB controller such as:
>  

[toc] | [prev] | [next] | [standalone]

#1394300 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On 04/05/16 16:17, Rob Herring wrote:
> On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote:
>> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>
>> Since some host controller (e.g. EHCI) needs a companion host controller
>> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
>> core.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
>>  drivers/usb/common/usb-otg.c                      | 32 ++++++++++++++++-------
>>  include/linux/usb/otg.h                           |  7 ++++-
>>  3 files changed, 32 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
>> index f6866c1..1db1c33 100644
>> --- a/Documentation/devicetree/bindings/usb/generic.txt
>> +++ b/Documentation/devicetree/bindings/usb/generic.txt
>> @@ -27,6 +27,9 @@ Optional properties:
>>   - otg-controller: phandle to otg controller. Host or gadget controllers can
>>  			contain this property to link it to a particular OTG
>>  			controller.
>> + - hcd-needs-companion: must be present if otg controller is dealing with
>> +			EHCI host controller that needs a companion OHCI host
>> +			controller.
> 
> Don't you need to have a link to the companion controller node?

primary and companion controllers are totally independent of each other
e.g. EHCI and OHCI. They are enabled by separate Kconfig options and
the system can operate with either or both of them enabled.

At the OTG layer we don't have information as to whether we should be waiting
for both of them to register or not and hence need this "hcd-needs-companion" flag.

> 
>>  
>>  This is an attribute to a USB controller such as:
>>  

--
cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1399110 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On Wed, May 04, 2016 at 04:47:18PM +0300, Roger Quadros wrote:
> On 04/05/16 16:17, Rob Herring wrote:
> > On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote:
> >> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >>
> >> Since some host controller (e.g. EHCI) needs a companion host controller
> >> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> >> core.
> >>
> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >> ---
> >>  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> >>  drivers/usb/common/usb-otg.c                      | 32 ++++++++++++++++-------
> >>  include/linux/usb/otg.h                           |  7 ++++-
> >>  3 files changed, 32 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> >> index f6866c1..1db1c33 100644
> >> --- a/Documentation/devicetree/bindings/usb/generic.txt
> >> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> >> @@ -27,6 +27,9 @@ Optional properties:
> >>   - otg-controller: phandle to otg controller. Host or gadget controllers can
> >>  			contain this property to link it to a particular OTG
> >>  			controller.
> >> + - hcd-needs-companion: must be present if otg controller is dealing with
> >> +			EHCI host controller that needs a companion OHCI host
> >> +			controller.
> > 
> > Don't you need to have a link to the companion controller node?
> 
> primary and companion controllers are totally independent of each other
> e.g. EHCI and OHCI. They are enabled by separate Kconfig options and
> the system can operate with either or both of them enabled.
> 
> At the OTG layer we don't have information as to whether we should be waiting
> for both of them to register or not and hence need this "hcd-needs-companion" flag.

What I mean is if you have 2 EHCI controllers with 2 companion 
controllers, don't you need to know which companion goes with which EHCI 
controller? Just like you do for the otg-controller property.

Rob

[toc] | [prev] | [next] | [standalone]

#1399160 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On 11/05/16 16:54, Rob Herring wrote:
> On Wed, May 04, 2016 at 04:47:18PM +0300, Roger Quadros wrote:
>> On 04/05/16 16:17, Rob Herring wrote:
>>> On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote:
>>>> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>>>
>>>> Since some host controller (e.g. EHCI) needs a companion host controller
>>>> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
>>>> core.
>>>>
>>>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
>>>>  drivers/usb/common/usb-otg.c                      | 32 ++++++++++++++++-------
>>>>  include/linux/usb/otg.h                           |  7 ++++-
>>>>  3 files changed, 32 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
>>>> index f6866c1..1db1c33 100644
>>>> --- a/Documentation/devicetree/bindings/usb/generic.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/generic.txt
>>>> @@ -27,6 +27,9 @@ Optional properties:
>>>>   - otg-controller: phandle to otg controller. Host or gadget controllers can
>>>>  			contain this property to link it to a particular OTG
>>>>  			controller.
>>>> + - hcd-needs-companion: must be present if otg controller is dealing with
>>>> +			EHCI host controller that needs a companion OHCI host
>>>> +			controller.
>>>
>>> Don't you need to have a link to the companion controller node?
>>
>> primary and companion controllers are totally independent of each other
>> e.g. EHCI and OHCI. They are enabled by separate Kconfig options and
>> the system can operate with either or both of them enabled.
>>
>> At the OTG layer we don't have information as to whether we should be waiting
>> for both of them to register or not and hence need this "hcd-needs-companion" flag.
> 
> What I mean is if you have 2 EHCI controllers with 2 companion 
> controllers, don't you need to know which companion goes with which EHCI 
> controller? Just like you do for the otg-controller property.
> 

That is a very good point. I'm not very sure and it seems that current code won't work
with multiple EHCI + companion instances.

Alan, does USB core even know which EHCI and OHCI are linked to the same port
or the handoff is software transparent?

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1399202 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On Wed, 11 May 2016, Roger Quadros wrote:

> > What I mean is if you have 2 EHCI controllers with 2 companion 
> > controllers, don't you need to know which companion goes with which EHCI 
> > controller? Just like you do for the otg-controller property.
> > 
> 
> That is a very good point. I'm not very sure and it seems that current code won't work
> with multiple EHCI + companion instances.
> 
> Alan, does USB core even know which EHCI and OHCI are linked to the same port
> or the handoff is software transparent?

The core knows.  It doesn't use the information for a whole lot of 
things, but it does use it in a couple of places.  Search for 
"companion" in core/hcd-pci.c and you'll see.

Alan Stern

[toc] | [prev] | [next] | [standalone]

#1399660 — RE: [PATCH v7 10/14] usb: otg: add hcd companion support

Hi,

> From: Alan Stern
> Sent: Wednesday, May 11, 2016 11:47 PM
> 
> On Wed, 11 May 2016, Roger Quadros wrote:
> 
> > > What I mean is if you have 2 EHCI controllers with 2 companion
> > > controllers, don't you need to know which companion goes with which EHCI
> > > controller? Just like you do for the otg-controller property.
> > >
> >
> > That is a very good point. I'm not very sure and it seems that current code won't work
> > with multiple EHCI + companion instances.

I may misunderstand this topic, but if I use the following environment, it works correctly.

< My environment >
- an otg controller: Sets hcd-needs-companion.
- ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
- ehci1 and ohci1: No "otg-controller" property.
- ehci2 and ohci2: No "otg-controller" property.

In this environment, all hosts works correctly.
Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
Or, does this topic assume an otg controller handles 2 EHCI controllers?
I'm not sure such environment actually exists.

> > Alan, does USB core even know which EHCI and OHCI are linked to the same port
> > or the handoff is software transparent?
> 
> The core knows.  It doesn't use the information for a whole lot of
> things, but it does use it in a couple of places.  Search for
> "companion" in core/hcd-pci.c and you'll see.

Thank you for the information. I didn't know this code.
If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
So, I will try to add such a code if needed.

Best regards,
Yoshihiro Shimoda

> Alan Stern

[toc] | [prev] | [next] | [standalone]

#1399750 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On 12/05/16 07:00, Yoshihiro Shimoda wrote:
> Hi,
> 
>> From: Alan Stern
>> Sent: Wednesday, May 11, 2016 11:47 PM
>>
>> On Wed, 11 May 2016, Roger Quadros wrote:
>>
>>>> What I mean is if you have 2 EHCI controllers with 2 companion
>>>> controllers, don't you need to know which companion goes with which EHCI
>>>> controller? Just like you do for the otg-controller property.
>>>>
>>>
>>> That is a very good point. I'm not very sure and it seems that current code won't work
>>> with multiple EHCI + companion instances.
> 
> I may misunderstand this topic, but if I use the following environment, it works correctly.
> 
> < My environment >
> - an otg controller: Sets hcd-needs-companion.
> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
> - ehci1 and ohci1: No "otg-controller" property.
> - ehci2 and ohci2: No "otg-controller" property.
> 
> In this environment, all hosts works correctly.
> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.

The topic is about more than one otg controllers and how to tie the right ehci and ohci
to the correct otg_dev instance especially in cases where we can't depend on probe order.

> Or, does this topic assume an otg controller handles 2 EHCI controllers?
> I'm not sure such environment actually exists.

No it is not about that.

> 
>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
>>> or the handoff is software transparent?
>>
>> The core knows.  It doesn't use the information for a whole lot of
>> things, but it does use it in a couple of places.  Search for
>> "companion" in core/hcd-pci.c and you'll see.
> 
> Thank you for the information. I didn't know this code.
> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.

That is correct.

> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
> So, I will try to add such a code if needed.

I think OTG core would have to rely on USB core in providing the right companion device,
just like we rely on it for the primary vs shared HCD case.

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1399832 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

Hi,

On 12/05/16 11:34, Roger Quadros wrote:
> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
>> Hi,
>>
>>> From: Alan Stern
>>> Sent: Wednesday, May 11, 2016 11:47 PM
>>>
>>> On Wed, 11 May 2016, Roger Quadros wrote:
>>>
>>>>> What I mean is if you have 2 EHCI controllers with 2 companion
>>>>> controllers, don't you need to know which companion goes with which EHCI
>>>>> controller? Just like you do for the otg-controller property.
>>>>>
>>>>
>>>> That is a very good point. I'm not very sure and it seems that current code won't work
>>>> with multiple EHCI + companion instances.
>>
>> I may misunderstand this topic, but if I use the following environment, it works correctly.
>>
>> < My environment >
>> - an otg controller: Sets hcd-needs-companion.
>> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
>> - ehci1 and ohci1: No "otg-controller" property.
>> - ehci2 and ohci2: No "otg-controller" property.
>>
>> In this environment, all hosts works correctly.
>> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
> 
> The topic is about more than one otg controllers and how to tie the right ehci and ohci
> to the correct otg_dev instance especially in cases where we can't depend on probe order.
> 
>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
>> I'm not sure such environment actually exists.
> 
> No it is not about that.
> 
>>
>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
>>>> or the handoff is software transparent?
>>>
>>> The core knows.  It doesn't use the information for a whole lot of
>>> things, but it does use it in a couple of places.  Search for
>>> "companion" in core/hcd-pci.c and you'll see.
>>
>> Thank you for the information. I didn't know this code.
>> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
> 
> That is correct.
> 
>> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
>> So, I will try to add such a code if needed.
> 
> I think OTG core would have to rely on USB core in providing the right companion device,
> just like we rely on it for the primary vs shared HCD case.
> 

OK, it is not so simple.

EHCI and companion port handoff is really meant to be software transparent.

non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
With device tree we could provide this mapping but for non-device tree case we can't do
anything.

So my suggestion would be to keep dual role implementation limited to one instance for
EHCI + companion case for non-DT.
For PCI case I don't see how dual role can be implemented. I don't think we have any
dual-role PCI cards.
For DT case we could have a DT binding to tie the EHCI and companion and use that
in the OTG framework.

Any objections?

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1399899 — RE: [PATCH v7 10/14] usb: otg: add hcd companion support

Hi,

> From: Roger Quadros
> Sent: Thursday, May 12, 2016 6:32 PM
> 
> Hi,
> 
> On 12/05/16 11:34, Roger Quadros wrote:
> > On 12/05/16 07:00, Yoshihiro Shimoda wrote:
> >> Hi,
> >>
> >>> From: Alan Stern
> >>> Sent: Wednesday, May 11, 2016 11:47 PM
> >>>
> >>> On Wed, 11 May 2016, Roger Quadros wrote:
> >>>
> >>>>> What I mean is if you have 2 EHCI controllers with 2 companion
> >>>>> controllers, don't you need to know which companion goes with which EHCI
> >>>>> controller? Just like you do for the otg-controller property.
> >>>>>
> >>>>
> >>>> That is a very good point. I'm not very sure and it seems that current code won't work
> >>>> with multiple EHCI + companion instances.
> >>
> >> I may misunderstand this topic, but if I use the following environment, it works correctly.
> >>
> >> < My environment >
> >> - an otg controller: Sets hcd-needs-companion.
> >> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
> >> - ehci1 and ohci1: No "otg-controller" property.
> >> - ehci2 and ohci2: No "otg-controller" property.
> >>
> >> In this environment, all hosts works correctly.
> >> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
> >
> > The topic is about more than one otg controllers and how to tie the right ehci and ohci
> > to the correct otg_dev instance especially in cases where we can't depend on probe order.
> >
> >> Or, does this topic assume an otg controller handles 2 EHCI controllers?
> >> I'm not sure such environment actually exists.
> >
> > No it is not about that.

Thank you for the reply. I understood it.

> >>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
> >>>> or the handoff is software transparent?
> >>>
> >>> The core knows.  It doesn't use the information for a whole lot of
> >>> things, but it does use it in a couple of places.  Search for
> >>> "companion" in core/hcd-pci.c and you'll see.
> >>
> >> Thank you for the information. I didn't know this code.
> >> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
> >
> > That is correct.
> >
> >> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
> >> So, I will try to add such a code if needed.
> >
> > I think OTG core would have to rely on USB core in providing the right companion device,
> > just like we rely on it for the primary vs shared HCD case.
> >
> 
> OK, it is not so simple.
> 
> EHCI and companion port handoff is really meant to be software transparent.
> 
> non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
> With device tree we could provide this mapping but for non-device tree case we can't do
> anything.
> 
> So my suggestion would be to keep dual role implementation limited to one instance for
> EHCI + companion case for non-DT.
> For PCI case I don't see how dual role can be implemented. I don't think we have any
> dual-role PCI cards.

R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI bus and
one high speed function controller via AXI bus.
One of channel can be used as host or function.

> For DT case we could have a DT binding to tie the EHCI and companion and use that
> in the OTG framework.

R-Car Gen3 SoC (r8a7795 / arm64) will be this type.
(Both USB 2.0 host/function controllers connect to AXI bus.)

> Any objections?

I don't have any objections because I'm just focus on R-Car Gen3 SoC for now.
If someone needs for PCI case, I think it is possible to add such a code somehow later.

Best regards,
Yoshihiro Shimoda

> cheers,
> -roger

[toc] | [prev] | [next] | [standalone]

#1399998 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

Hi,

On 12/05/16 13:31, Yoshihiro Shimoda wrote:
> Hi,
> 
>> From: Roger Quadros
>> Sent: Thursday, May 12, 2016 6:32 PM
>>
>> Hi,
>>
>> On 12/05/16 11:34, Roger Quadros wrote:
>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
>>>> Hi,
>>>>
>>>>> From: Alan Stern
>>>>> Sent: Wednesday, May 11, 2016 11:47 PM
>>>>>
>>>>> On Wed, 11 May 2016, Roger Quadros wrote:
>>>>>
>>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion
>>>>>>> controllers, don't you need to know which companion goes with which EHCI
>>>>>>> controller? Just like you do for the otg-controller property.
>>>>>>>
>>>>>>
>>>>>> That is a very good point. I'm not very sure and it seems that current code won't work
>>>>>> with multiple EHCI + companion instances.
>>>>
>>>> I may misunderstand this topic, but if I use the following environment, it works correctly.
>>>>
>>>> < My environment >
>>>> - an otg controller: Sets hcd-needs-companion.
>>>> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
>>>> - ehci1 and ohci1: No "otg-controller" property.
>>>> - ehci2 and ohci2: No "otg-controller" property.
>>>>
>>>> In this environment, all hosts works correctly.
>>>> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
>>>
>>> The topic is about more than one otg controllers and how to tie the right ehci and ohci
>>> to the correct otg_dev instance especially in cases where we can't depend on probe order.
>>>
>>>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
>>>> I'm not sure such environment actually exists.
>>>
>>> No it is not about that.
> 
> Thank you for the reply. I understood it.
> 
>>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
>>>>>> or the handoff is software transparent?
>>>>>
>>>>> The core knows.  It doesn't use the information for a whole lot of
>>>>> things, but it does use it in a couple of places.  Search for
>>>>> "companion" in core/hcd-pci.c and you'll see.
>>>>
>>>> Thank you for the information. I didn't know this code.
>>>> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
>>>
>>> That is correct.
>>>
>>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
>>>> So, I will try to add such a code if needed.
>>>
>>> I think OTG core would have to rely on USB core in providing the right companion device,
>>> just like we rely on it for the primary vs shared HCD case.
>>>
>>
>> OK, it is not so simple.
>>
>> EHCI and companion port handoff is really meant to be software transparent.
>>
>> non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
>> With device tree we could provide this mapping but for non-device tree case we can't do
>> anything.
>>
>> So my suggestion would be to keep dual role implementation limited to one instance for
>> EHCI + companion case for non-DT.
>> For PCI case I don't see how dual role can be implemented. I don't think we have any
>> dual-role PCI cards.
> 
> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI bus and
> one high speed function controller via AXI bus.
> One of channel can be used as host or function.
> 
>> For DT case we could have a DT binding to tie the EHCI and companion and use that
>> in the OTG framework.

After looking at the code it seems we don't need this special binding as we are already
linking the EHCI controller and companion controller to the single otg controller instance
using the otg-controller property.

So all is good as of now.

For non DT case, it is the responsibility of platform support code to ensure that
it calls usb_otg_add_hcd() with the correct otg controller instance for both EHCI and
companion controller and things should work fine there as well.

--
cheers,
-roger

> 
> R-Car Gen3 SoC (r8a7795 / arm64) will be this type.
> (Both USB 2.0 host/function controllers connect to AXI bus.)
> 
>> Any objections?
> 
> I don't have any objections because I'm just focus on R-Car Gen3 SoC for now.
> If someone needs for PCI case, I think it is possible to add such a code somehow later.
> 
> Best regards,
> Yoshihiro Shimoda
> 
>> cheers,
>> -roger

[toc] | [prev] | [next] | [standalone]

#1401282 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
> Hi,
> 
> On 12/05/16 13:31, Yoshihiro Shimoda wrote:
> > Hi,
> > 
> >> From: Roger Quadros
> >> Sent: Thursday, May 12, 2016 6:32 PM
> >>
> >> Hi,
> >>
> >> On 12/05/16 11:34, Roger Quadros wrote:
> >>> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
> >>>> Hi,
> >>>>
> >>>>> From: Alan Stern
> >>>>> Sent: Wednesday, May 11, 2016 11:47 PM
> >>>>>
> >>>>> On Wed, 11 May 2016, Roger Quadros wrote:
> >>>>>
> >>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion
> >>>>>>> controllers, don't you need to know which companion goes with which EHCI
> >>>>>>> controller? Just like you do for the otg-controller property.
> >>>>>>>
> >>>>>>
> >>>>>> That is a very good point. I'm not very sure and it seems that current code won't work
> >>>>>> with multiple EHCI + companion instances.
> >>>>
> >>>> I may misunderstand this topic, but if I use the following environment, it works correctly.
> >>>>
> >>>> < My environment >
> >>>> - an otg controller: Sets hcd-needs-companion.
> >>>> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
> >>>> - ehci1 and ohci1: No "otg-controller" property.
> >>>> - ehci2 and ohci2: No "otg-controller" property.
> >>>>
> >>>> In this environment, all hosts works correctly.
> >>>> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
> >>>
> >>> The topic is about more than one otg controllers and how to tie the right ehci and ohci
> >>> to the correct otg_dev instance especially in cases where we can't depend on probe order.
> >>>
> >>>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
> >>>> I'm not sure such environment actually exists.
> >>>
> >>> No it is not about that.
> > 
> > Thank you for the reply. I understood it.
> > 
> >>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
> >>>>>> or the handoff is software transparent?
> >>>>>
> >>>>> The core knows.  It doesn't use the information for a whole lot of
> >>>>> things, but it does use it in a couple of places.  Search for
> >>>>> "companion" in core/hcd-pci.c and you'll see.
> >>>>
> >>>> Thank you for the information. I didn't know this code.
> >>>> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
> >>>
> >>> That is correct.
> >>>
> >>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
> >>>> So, I will try to add such a code if needed.
> >>>
> >>> I think OTG core would have to rely on USB core in providing the right companion device,
> >>> just like we rely on it for the primary vs shared HCD case.
> >>>
> >>
> >> OK, it is not so simple.
> >>
> >> EHCI and companion port handoff is really meant to be software transparent.
> >>
> >> non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
> >> With device tree we could provide this mapping but for non-device tree case we can't do
> >> anything.
> >>
> >> So my suggestion would be to keep dual role implementation limited to one instance for
> >> EHCI + companion case for non-DT.
> >> For PCI case I don't see how dual role can be implemented. I don't think we have any
> >> dual-role PCI cards.
> > 
> > R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI bus and
> > one high speed function controller via AXI bus.
> > One of channel can be used as host or function.
> > 
> >> For DT case we could have a DT binding to tie the EHCI and companion and use that
> >> in the OTG framework.
> 
> After looking at the code it seems we don't need this special binding as we are already
> linking the EHCI controller and companion controller to the single otg controller instance
> using the otg-controller property.
> 

Then, how you know this EHCI + companion controller special case during otg adds
hcd, it needs special handling, right?

Peter

> So all is good as of now.
> 
> For non DT case, it is the responsibility of platform support code to ensure that
> it calls usb_otg_add_hcd() with the correct otg controller instance for both EHCI and
> companion controller and things should work fine there as well.
> 
> --
> cheers,
> -roger
> 
> > 
> > R-Car Gen3 SoC (r8a7795 / arm64) will be this type.
> > (Both USB 2.0 host/function controllers connect to AXI bus.)
> > 
> >> Any objections?
> > 
> > I don't have any objections because I'm just focus on R-Car Gen3 SoC for now.
> > If someone needs for PCI case, I think it is possible to add such a code somehow later.
> > 
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1401349 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On 16/05/16 05:13, Peter Chen wrote:
> On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 12/05/16 13:31, Yoshihiro Shimoda wrote:
>>> Hi,
>>>
>>>> From: Roger Quadros
>>>> Sent: Thursday, May 12, 2016 6:32 PM
>>>>
>>>> Hi,
>>>>
>>>> On 12/05/16 11:34, Roger Quadros wrote:
>>>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>>> From: Alan Stern
>>>>>>> Sent: Wednesday, May 11, 2016 11:47 PM
>>>>>>>
>>>>>>> On Wed, 11 May 2016, Roger Quadros wrote:
>>>>>>>
>>>>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion
>>>>>>>>> controllers, don't you need to know which companion goes with which EHCI
>>>>>>>>> controller? Just like you do for the otg-controller property.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is a very good point. I'm not very sure and it seems that current code won't work
>>>>>>>> with multiple EHCI + companion instances.
>>>>>>
>>>>>> I may misunderstand this topic, but if I use the following environment, it works correctly.
>>>>>>
>>>>>> < My environment >
>>>>>> - an otg controller: Sets hcd-needs-companion.
>>>>>> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
>>>>>> - ehci1 and ohci1: No "otg-controller" property.
>>>>>> - ehci2 and ohci2: No "otg-controller" property.
>>>>>>
>>>>>> In this environment, all hosts works correctly.
>>>>>> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
>>>>>
>>>>> The topic is about more than one otg controllers and how to tie the right ehci and ohci
>>>>> to the correct otg_dev instance especially in cases where we can't depend on probe order.
>>>>>
>>>>>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
>>>>>> I'm not sure such environment actually exists.
>>>>>
>>>>> No it is not about that.
>>>
>>> Thank you for the reply. I understood it.
>>>
>>>>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
>>>>>>>> or the handoff is software transparent?
>>>>>>>
>>>>>>> The core knows.  It doesn't use the information for a whole lot of
>>>>>>> things, but it does use it in a couple of places.  Search for
>>>>>>> "companion" in core/hcd-pci.c and you'll see.
>>>>>>
>>>>>> Thank you for the information. I didn't know this code.
>>>>>> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
>>>>>
>>>>> That is correct.
>>>>>
>>>>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
>>>>>> So, I will try to add such a code if needed.
>>>>>
>>>>> I think OTG core would have to rely on USB core in providing the right companion device,
>>>>> just like we rely on it for the primary vs shared HCD case.
>>>>>
>>>>
>>>> OK, it is not so simple.
>>>>
>>>> EHCI and companion port handoff is really meant to be software transparent.
>>>>
>>>> non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
>>>> With device tree we could provide this mapping but for non-device tree case we can't do
>>>> anything.
>>>>
>>>> So my suggestion would be to keep dual role implementation limited to one instance for
>>>> EHCI + companion case for non-DT.
>>>> For PCI case I don't see how dual role can be implemented. I don't think we have any
>>>> dual-role PCI cards.
>>>
>>> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI bus and
>>> one high speed function controller via AXI bus.
>>> One of channel can be used as host or function.
>>>
>>>> For DT case we could have a DT binding to tie the EHCI and companion and use that
>>>> in the OTG framework.
>>
>> After looking at the code it seems we don't need this special binding as we are already
>> linking the EHCI controller and companion controller to the single otg controller instance
>> using the otg-controller property.
>>
> 
> Then, how you know this EHCI + companion controller special case during otg adds
> hcd, it needs special handling, right?

We know the special case by using the hcd_needs_companion flag.

cheers,
-roger

> 
> Peter
> 
>> So all is good as of now.
>>
>> For non DT case, it is the responsibility of platform support code to ensure that
>> it calls usb_otg_add_hcd() with the correct otg controller instance for both EHCI and
>> companion controller and things should work fine there as well.
>>
>> --
>> cheers,
>> -roger
>>
>>>
>>> R-Car Gen3 SoC (r8a7795 / arm64) will be this type.
>>> (Both USB 2.0 host/function controllers connect to AXI bus.)
>>>
>>>> Any objections?
>>>
>>> I don't have any objections because I'm just focus on R-Car Gen3 SoC for now.
>>> If someone needs for PCI case, I think it is possible to add such a code somehow later.
>>>
>>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [prev] | [next] | [standalone]

#1401360 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On Mon, May 16, 2016 at 11:01:27AM +0300, Roger Quadros wrote:
> On 16/05/16 05:13, Peter Chen wrote:
> > On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 12/05/16 13:31, Yoshihiro Shimoda wrote:
> >>> Hi,
> >>>
> >>>> From: Roger Quadros
> >>>> Sent: Thursday, May 12, 2016 6:32 PM
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 12/05/16 11:34, Roger Quadros wrote:
> >>>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>>> From: Alan Stern
> >>>>>>> Sent: Wednesday, May 11, 2016 11:47 PM
> >>>>>>>
> >>>>>>> On Wed, 11 May 2016, Roger Quadros wrote:
> >>>>>>>
> >>>>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion
> >>>>>>>>> controllers, don't you need to know which companion goes with which EHCI
> >>>>>>>>> controller? Just like you do for the otg-controller property.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That is a very good point. I'm not very sure and it seems that current code won't work
> >>>>>>>> with multiple EHCI + companion instances.
> >>>>>>
> >>>>>> I may misunderstand this topic, but if I use the following environment, it works correctly.
> >>>>>>
> >>>>>> < My environment >
> >>>>>> - an otg controller: Sets hcd-needs-companion.
> >>>>>> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
> >>>>>> - ehci1 and ohci1: No "otg-controller" property.
> >>>>>> - ehci2 and ohci2: No "otg-controller" property.
> >>>>>>
> >>>>>> In this environment, all hosts works correctly.
> >>>>>> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
> >>>>>
> >>>>> The topic is about more than one otg controllers and how to tie the right ehci and ohci
> >>>>> to the correct otg_dev instance especially in cases where we can't depend on probe order.
> >>>>>
> >>>>>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
> >>>>>> I'm not sure such environment actually exists.
> >>>>>
> >>>>> No it is not about that.
> >>>
> >>> Thank you for the reply. I understood it.
> >>>
> >>>>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
> >>>>>>>> or the handoff is software transparent?
> >>>>>>>
> >>>>>>> The core knows.  It doesn't use the information for a whole lot of
> >>>>>>> things, but it does use it in a couple of places.  Search for
> >>>>>>> "companion" in core/hcd-pci.c and you'll see.
> >>>>>>
> >>>>>> Thank you for the information. I didn't know this code.
> >>>>>> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
> >>>>>
> >>>>> That is correct.
> >>>>>
> >>>>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
> >>>>>> So, I will try to add such a code if needed.
> >>>>>
> >>>>> I think OTG core would have to rely on USB core in providing the right companion device,
> >>>>> just like we rely on it for the primary vs shared HCD case.
> >>>>>
> >>>>
> >>>> OK, it is not so simple.
> >>>>
> >>>> EHCI and companion port handoff is really meant to be software transparent.
> >>>>
> >>>> non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
> >>>> With device tree we could provide this mapping but for non-device tree case we can't do
> >>>> anything.
> >>>>
> >>>> So my suggestion would be to keep dual role implementation limited to one instance for
> >>>> EHCI + companion case for non-DT.
> >>>> For PCI case I don't see how dual role can be implemented. I don't think we have any
> >>>> dual-role PCI cards.
> >>>
> >>> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI bus and
> >>> one high speed function controller via AXI bus.
> >>> One of channel can be used as host or function.
> >>>
> >>>> For DT case we could have a DT binding to tie the EHCI and companion and use that
> >>>> in the OTG framework.
> >>
> >> After looking at the code it seems we don't need this special binding as we are already
> >> linking the EHCI controller and companion controller to the single otg controller instance
> >> using the otg-controller property.
> >>

[...]
> > 
> > Then, how you know this EHCI + companion controller special case during otg adds
> > hcd, it needs special handling, right?
> 
> We know the special case by using the hcd_needs_companion flag.
> 

You had said "we don't need this..", ok, yes, we do need it.

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1401371 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On 16/05/16 11:13, Peter Chen wrote:
> On Mon, May 16, 2016 at 11:01:27AM +0300, Roger Quadros wrote:
>> On 16/05/16 05:13, Peter Chen wrote:
>>> On Thu, May 12, 2016 at 03:13:48PM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 12/05/16 13:31, Yoshihiro Shimoda wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Roger Quadros
>>>>>> Sent: Thursday, May 12, 2016 6:32 PM
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 12/05/16 11:34, Roger Quadros wrote:
>>>>>>> On 12/05/16 07:00, Yoshihiro Shimoda wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> From: Alan Stern
>>>>>>>>> Sent: Wednesday, May 11, 2016 11:47 PM
>>>>>>>>>
>>>>>>>>> On Wed, 11 May 2016, Roger Quadros wrote:
>>>>>>>>>
>>>>>>>>>>> What I mean is if you have 2 EHCI controllers with 2 companion
>>>>>>>>>>> controllers, don't you need to know which companion goes with which EHCI
>>>>>>>>>>> controller? Just like you do for the otg-controller property.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is a very good point. I'm not very sure and it seems that current code won't work
>>>>>>>>>> with multiple EHCI + companion instances.
>>>>>>>>
>>>>>>>> I may misunderstand this topic, but if I use the following environment, it works correctly.
>>>>>>>>
>>>>>>>> < My environment >
>>>>>>>> - an otg controller: Sets hcd-needs-companion.
>>>>>>>> - ehci0 and ohci0 and a function: They connect to the otg controller using "otg-controller" property.
>>>>>>>> - ehci1 and ohci1: No "otg-controller" property.
>>>>>>>> - ehci2 and ohci2: No "otg-controller" property.
>>>>>>>>
>>>>>>>> In this environment, all hosts works correctly.
>>>>>>>> Also I think if we have 2 otg controlelrs, it should be work because otg_dev instance differs.
>>>>>>>
>>>>>>> The topic is about more than one otg controllers and how to tie the right ehci and ohci
>>>>>>> to the correct otg_dev instance especially in cases where we can't depend on probe order.
>>>>>>>
>>>>>>>> Or, does this topic assume an otg controller handles 2 EHCI controllers?
>>>>>>>> I'm not sure such environment actually exists.
>>>>>>>
>>>>>>> No it is not about that.
>>>>>
>>>>> Thank you for the reply. I understood it.
>>>>>
>>>>>>>>>> Alan, does USB core even know which EHCI and OHCI are linked to the same port
>>>>>>>>>> or the handoff is software transparent?
>>>>>>>>>
>>>>>>>>> The core knows.  It doesn't use the information for a whole lot of
>>>>>>>>> things, but it does use it in a couple of places.  Search for
>>>>>>>>> "companion" in core/hcd-pci.c and you'll see.
>>>>>>>>
>>>>>>>> Thank you for the information. I didn't know this code.
>>>>>>>> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
>>>>>>>
>>>>>>> That is correct.
>>>>>>>
>>>>>>>> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.
>>>>>>>> So, I will try to add such a code if needed.
>>>>>>>
>>>>>>> I think OTG core would have to rely on USB core in providing the right companion device,
>>>>>>> just like we rely on it for the primary vs shared HCD case.
>>>>>>>
>>>>>>
>>>>>> OK, it is not so simple.
>>>>>>
>>>>>> EHCI and companion port handoff is really meant to be software transparent.
>>>>>>
>>>>>> non-PCI devices really don't have knowledge of which OHCI instance is companion to the EHCI.
>>>>>> With device tree we could provide this mapping but for non-device tree case we can't do
>>>>>> anything.
>>>>>>
>>>>>> So my suggestion would be to keep dual role implementation limited to one instance for
>>>>>> EHCI + companion case for non-DT.
>>>>>> For PCI case I don't see how dual role can be implemented. I don't think we have any
>>>>>> dual-role PCI cards.
>>>>>
>>>>> R-Car Gen2 SoCs (r8a779[0134] / arm32) has USB 2.0 host controllers via PCI bus and
>>>>> one high speed function controller via AXI bus.
>>>>> One of channel can be used as host or function.
>>>>>
>>>>>> For DT case we could have a DT binding to tie the EHCI and companion and use that
>>>>>> in the OTG framework.
>>>>
>>>> After looking at the code it seems we don't need this special binding as we are already
>>>> linking the EHCI controller and companion controller to the single otg controller instance
>>>> using the otg-controller property.
>>>>
> 
> [...]
>>>
>>> Then, how you know this EHCI + companion controller special case during otg adds
>>> hcd, it needs special handling, right?
>>
>> We know the special case by using the hcd_needs_companion flag.
>>
> 
> You had said "we don't need this..", ok, yes, we do need it.
> 
I'm sorry for the confusion. What I meant by "we don't need this special binding" was that
we don't need additional binding to link the HCD and companion HCD.

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1400271 — RE: [PATCH v7 10/14] usb: otg: add hcd companion support

On Thu, 12 May 2016, Yoshihiro Shimoda wrote:

> > > Alan, does USB core even know which EHCI and OHCI are linked to the same port
> > > or the handoff is software transparent?
> > 
> > The core knows.  It doesn't use the information for a whole lot of
> > things, but it does use it in a couple of places.  Search for
> > "companion" in core/hcd-pci.c and you'll see.
> 
> Thank you for the information. I didn't know this code.
> If my understanding is correct, the core/hcd-pci.c code will not be used by non-PCI devices.
> In other words, nobody sets "hcd->self.hs_companion" if we use such a device.

That's right.

> So, I will try to add such a code if needed.

The main thing to watch out for is during system resume.  The EHCI
controller must not be resumed until all of its companion controllers
have been resumed.

Alan Stern

[toc] | [prev] | [next] | [standalone]

#1398801 — Re: [PATCH v7 10/14] usb: otg: add hcd companion support

On Mon, May 02, 2016 at 03:18:53PM +0300, Roger Quadros wrote:
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> 
> Since some host controller (e.g. EHCI) needs a companion host controller
> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> core.
> 
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>

Acked-by: Peter Chen <peter.chen@nxp.com>

> ---
>  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
>  drivers/usb/common/usb-otg.c                      | 32 ++++++++++++++++-------
>  include/linux/usb/otg.h                           |  7 ++++-
>  3 files changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> index f6866c1..1db1c33 100644
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> @@ -27,6 +27,9 @@ Optional properties:
>   - otg-controller: phandle to otg controller. Host or gadget controllers can
>  			contain this property to link it to a particular OTG
>  			controller.
> + - hcd-needs-companion: must be present if otg controller is dealing with
> +			EHCI host controller that needs a companion OHCI host
> +			controller.
>  
>  This is an attribute to a USB controller such as:
>  
> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> index 702bca8..77048aa 100644
> --- a/drivers/usb/common/usb-otg.c
> +++ b/drivers/usb/common/usb-otg.c
> @@ -20,6 +20,7 @@
>  #include <linux/list.h>
>  #include <linux/of.h>
>  #include <linux/of_platform.h>
> +#include <linux/usb/of.h>
>  #include <linux/usb/otg.h>
>  #include <linux/usb/gadget.h>
>  #include <linux/workqueue.h>
> @@ -582,6 +583,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
>  	else
>  		INIT_WORK(&otg->work, usb_drd_work);
>  
> +	if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> +	    config->hcd_needs_companion)	/* needs companion ? */
> +		otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> +
>  	otg->wq = create_singlethread_workqueue("usb_otg");
>  	if (!otg->wq) {
>  		dev_err(dev, "otg: %s: can't create workqueue\n",
> @@ -805,15 +810,18 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  	/* HCD will be started by OTG fsm when needed */
>  	mutex_lock(&otg->fsm.lock);
>  	if (otg->primary_hcd.hcd) {
> -		/* probably a shared HCD ? */
> -		if (usb_otg_hcd_is_primary_hcd(hcd)) {
> +		/* probably a shared HCD or a companion OHCI HCD ? */
> +		if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> +		    usb_otg_hcd_is_primary_hcd(hcd)) {
>  			dev_err(otg_dev, "otg: primary host already registered\n");
>  			goto err;
>  		}
>  
> -		if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> +		if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> +		    (hcd->shared_hcd == otg->primary_hcd.hcd)) {
>  			if (otg->shared_hcd.hcd) {
> -				dev_err(otg_dev, "otg: shared host already registered\n");
> +				dev_err(otg_dev,
> +					"otg: shared/companion host already registered\n");
>  				goto err;
>  			}
>  
> @@ -821,10 +829,12 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  			otg->shared_hcd.irqnum = irqnum;
>  			otg->shared_hcd.irqflags = irqflags;
>  			otg->shared_hcd.ops = ops;
> -			dev_info(otg_dev, "otg: shared host %s registered\n",
> +			dev_info(otg_dev,
> +				 "otg: shared/companion host %s registered\n",
>  				 dev_name(hcd->self.controller));
>  		} else {
> -			dev_err(otg_dev, "otg: invalid shared host %s\n",
> +			dev_err(otg_dev,
> +				"otg: invalid shared/companion host %s\n",
>  				dev_name(hcd->self.controller));
>  			goto err;
>  		}
> @@ -847,14 +857,17 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  	 * we're ready only if we have shared HCD
>  	 * or we don't need shared HCD.
>  	 */
> -	if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> +	if (otg->shared_hcd.hcd ||
> +	    (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> +	     !otg->primary_hcd.hcd->shared_hcd)) {
>  		otg->host = hcd_to_bus(hcd);
>  		/* FIXME: set bus->otg_port if this is true OTG port with HNP */
>  
>  		/* start FSM */
>  		usb_otg_start_fsm(otg);
>  	} else {
> -		dev_dbg(otg_dev, "otg: can't start till shared host registers\n");
> +		dev_dbg(otg_dev,
> +			"otg: can't start till shared/companion host registers\n");
>  	}
>  
>  	mutex_unlock(&otg->fsm.lock);
> @@ -905,7 +918,8 @@ int usb_otg_unregister_hcd(struct usb_hcd *hcd)
>  			 dev_name(hcd_dev));
>  	} else if (hcd == otg->shared_hcd.hcd) {
>  		otg->shared_hcd.hcd = NULL;
> -		dev_info(otg_dev, "otg: shared host %s unregistered\n",
> +		dev_info(otg_dev,
> +			 "otg: shared/companion host %s unregistered\n",
>  			 dev_name(hcd_dev));
>  	} else {
>  		dev_err(otg_dev, "otg: host %s wasn't registered with otg\n",
> diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
> index b094352..6f4ca77 100644
> --- a/include/linux/usb/otg.h
> +++ b/include/linux/usb/otg.h
> @@ -57,7 +57,8 @@ struct otg_hcd {
>   * @list: list of otg controllers
>   * @work: otg state machine work
>   * @wq: otg state machine work queue
> - * @flags: to track if host/gadget is running
> + * @flags: to track if host/gadget is running, or to indicate if hcd needs
> + *	   companion
>   */
>  struct usb_otg {
>  	u8			default_a;
> @@ -84,6 +85,7 @@ struct usb_otg {
>  	u32 flags;
>  #define OTG_FLAG_GADGET_RUNNING (1 << 0)
>  #define OTG_FLAG_HOST_RUNNING (1 << 1)
> +#define OTG_FLAG_HCD_NEEDS_COMPANION (1 << 2)
>  	/* use otg->fsm.lock for serializing access */
>  
>  /*------------- deprecated interface -----------------------------*/
> @@ -125,11 +127,14 @@ struct usb_otg_caps {
>   * @caps: otg capabilities of the controller
>   * @ops: otg fsm operations
>   * @otg_work: optional custom otg state machine work function
> + * @hcd_needs_companion: Indicates if host controller needs a companion
> + *			 controller
>   */
>  struct usb_otg_config {
>  	struct usb_otg_caps *otg_caps;
>  	struct otg_fsm_ops *fsm_ops;
>  	void (*otg_work)(struct work_struct *work);
> +	bool hcd_needs_companion;
>  };
>  
>  extern const char *usb_otg_state_string(enum usb_otg_state state);
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1398800

On Mon, May 02, 2016 at 03:18:43PM +0300, Roger Quadros wrote:
> Hi,
> 
> This series centralizes OTG/Dual-role functionality in the kernel.
> As of now I've got Dual-role functionality working pretty reliably on
> dra7-evm and am437x-gp-evm.
> 
> DWC3 controller and platform related patches will be sent separately.
> 
> Series is based on v4.6-rc1 and depends on first 2 patches of [1]
> [1] - OTG fsm cleanup - https://lkml.org/lkml/2016/3/30/186
> 
> Why?:
> ----
> 
> Currently there is no central location where OTG/dual-role functionality is
> implemented in the Linux USB stack and every USB controller driver is
> doing their own thing for OTG/dual-role. We can benefit from code-reuse
> and simplicity by adding the OTG/dual-role core driver.
> 
> Newer OTG cores support standard host interface (e.g. xHCI) so
> host and gadget functionality are no longer closely knit like older
> cores. There needs to be a way to co-ordinate the operation of the
> host and gadget controllers in dual-role mode. i.e. to stop and start them
> from a central location. This central location should be the
> USB OTG/dual-role core.
> 
> Host and gadget controllers might be sharing resources and can't
> be always running. One has to be stopped for the other to run.
> This couldn't be done till now but can be done from the OTG core.
> 
> What?:
> -----
> 
> The OTG/dual-role core consists of a set of APIs that allow
> registration of OTG controller device and OTG capable host and gadget
> controllers.
> 
> - The OTG controller driver can provide the OTG capabilities and the
> Finite State Machine work function via 'struct usb_otg_config'
> at the time of registration i.e. usb_otg_register();
> 
> 	struct usb_otg *usb_otg_register(struct device *dev,
>         	                         struct usb_otg_config *config);
> 	int usb_otg_unregister(struct device *dev);
> 	/**
> 	 * struct usb_otg_config - otg controller configuration
> 	 * @caps: otg capabilities of the controller
> 	 * @ops: otg fsm operations
> 	 * @otg_work: optional custom otg state machine work function
> 	 */
> 	struct usb_otg_config {
> 	        struct usb_otg_caps *otg_caps;
> 	        struct otg_fsm_ops *fsm_ops;
> 	        void (*otg_work)(struct work_struct *work);
> 	};
> 
> The dual-role state machine is built-into the OTG core so nothing
> special needs to be provided if only dual-role functionality is desired.
> The low level OTG controller driver ops are povided via
> 'struct otg_fsm_ops *fsm_ops' in the 'struct usb_otg_config'.
> 
> After registration, the OTG core waits for host, gadget controller
> and the gadget function driver to be registered. Once all resources are
> available it instantiates the Finite State Machine (FSM).
> The host/gadget controllers are started/stopped according to the FSM.
> 
> - Host and gadget controllers that are a part of OTG/dual-role port must
> use the OTG core provided APIs to add/remove the host/gadget.
> i.e. hosts must use usb_otg_add_hcd() usb_otg_remove_hcd(),,
> gadgets must use usb_otg_add_gadget_udc() usb_del_gadget_udc().
> This ensures that the host and gadget controllers are not started till
> the state machine is ready and the right bus conditions are met.
> It also allows the host and gadget controllers to provide the OTG
> controller device to link them together. For Device tree boots
> the related OTG controller is automatically picked up via the
> 'otg-controller' property in the Host/Gadget controller nodes.
> 
> 	int usb_otg_add_hcd(struct usb_hcd *hcd,
> 			    unsigned int irqnum, unsigned long irqflags,
> 			    struct device *otg_dev);
> 	void usb_otg_remove_hcd(struct usb_hcd *hcd);
> 
> 	int usb_otg_add_gadget_udc(struct device *parent,
> 				   struct usb_gadget *gadget,
> 				   struct device *otg_dev);
> 	usb_del_gadget_udc() must be used for removal.
> 
> 
> - During the lifetime of the FSM, the OTG controller driver can provide
> inputs event changes using usb_otg_sync_inputs(). The OTG core will
> then schedule the FSM work function (or internal dual-role state machine)
> to update the FSM state. The FSM then calls the OTG controller
> operations (fsm_ops) as necessary.
> 	void usb_otg_sync_inputs(struct usb_otg *otg);
> 
> - The following 2 functions are provided as helpers for use by the
> OTG controller driver to start/stop the host/gadget controllers.
> 	int usb_otg_start_host(struct usb_otg *otg, int on);
> 	int usb_otg_start_gadget(struct usb_otg *otg, int on);
> 
> - The following function is provided for use by the USB host stack
> to sync OTG related events to the OTG state machine.
> e.g. change in host_bus->b_hnp_enable, gadget->b_hnp_enable
> 	int usb_otg_kick_fsm(struct device *otg_device);
> 
> Changelog:
> ---------
> v7:
> - added dual-role support for host controllers requiring a companion
> controller. e.g. EHCI + OHCI.
> - added of_usb_get_otg() to get the OTG controller device
> from the USB controller's device node.
> - addressed review comments.

Would you please list more for review comments, eg which comment for
which part? It is a big patch set, that will let review easy.

Peter
> 
> v6:
> - added otg specific APIs for host/gadget registration. behaviour of
> original host/gadget API remains unchanged. Platform devices can now
> pass the otg device explicitly while registering host/gadget.
> - moved hcd specific operations from struct otg_fsm to struct hcd_ops.
> - made struct usb_otg mandatory for all otg related APIs.
> - allow otg controller to provide it's own otg_work function so that
> it can implement it's own state machine.
> - removed otg fsm and timers from usb-otg.c. Only dual-role state machine
> is implemented.
> - vbus is controlled in the dual-role state machine.
> - PM runtime is used around drd_statemachine().
> - added otg_dev to xhci platform data to allow platform code to specify
> the otg controller tied to the xhci host controller.
> 
> v5: Internal version. Not sent to mailing list
> 
> v4:
> - Added DT support for tying otg-controller to host and gadget
>  controllers. For DT we no longer have the constraint that
>  OTG controller needs to be parent of host and gadget. They can be
>  tied together using the "otg-controller" property.
> - Relax the requirement for DT case that otg controller must register
>  before host/gadget. We maintain a wait list of host/gadget devices
>  waiting on the otg controller.
> - Use a single struct usb_otg for otg data.
> - Don't override host/gadget start/stop APIs. Let the controller
>  drivers do what they want as they know best. Helper API is provided
>  for controller start/stop that controller driver can use.
> - Introduce struct usb_otg_config to pass the otg capabilities,
>  otg ops and otg timer timeouts during otg controller registration.
> - rebased on Greg's usb.git/usb-next
> 
> v3:
> - all otg related definations now in otg.h
> - single kernel config USB_OTG to enable OTG core and FSM.
> - resolved symbol dependency issues.
> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c
> - rebased on v4.2-rc1
> 
> v2:
> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable
>  the host controller
> - added dual-role-device (DRD) state machine which is a much simpler
>  mode of operation when compared to OTG. Here we don't support fancy
>  OTG features like HNP, SRP, on the fly role-swap. The mode of operation
>  is determined based on ID pin (cable type) and the role doesn't change
>  till the cable type changes.
> 
> --
> cheers,
> -roger
> 
> Roger Quadros (13):
>   usb: hcd: Initialize hcd->flags to 0
>   usb: otg-fsm: Prevent build warning "VDBG" redefined
>   usb: hcd.h: Add OTG to HCD interface
>   usb: otg-fsm: use usb_otg wherever possible
>   usb: otg-fsm: move host controller operations into usb_otg->hcd_ops
>   usb: gadget.h: Add OTG to gadget interface
>   usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG
>   usb: otg: add OTG/dual-role core
>   usb: of: add an API to get OTG device from USB controller node
>   usb: otg: use dev_dbg() instead of VDBG()
>   usb: hcd: Adapt to OTG core
>   usb: gadget: udc: adapt to OTG core
>   usb: host: xhci-plat: Add otg device to platform data
> 
> Yoshihiro Shimoda (1):
>   usb: otg: add hcd companion support
> 
>  Documentation/devicetree/bindings/usb/generic.txt  |    6 +
>  Documentation/usb/chipidea.txt                     |    2 +-
>  drivers/usb/chipidea/Makefile                      |    2 +-
>  drivers/usb/chipidea/ci.h                          |    3 +-
>  drivers/usb/chipidea/core.c                        |   14 +-
>  drivers/usb/chipidea/debug.c                       |    2 +-
>  drivers/usb/chipidea/otg_fsm.c                     |  176 ++--
>  drivers/usb/chipidea/otg_fsm.h                     |    2 +-
>  drivers/usb/chipidea/udc.c                         |   17 +-
>  drivers/usb/common/Makefile                        |    3 +-
>  drivers/usb/common/common.c                        |   27 +
>  drivers/usb/common/usb-otg-fsm.c                   |  203 ++--
>  drivers/usb/common/usb-otg.c                       | 1054 ++++++++++++++++++++
>  .../usb/{chipidea/otg_fsm.h => common/usb-otg.h}   |   61 +-
>  drivers/usb/core/Kconfig                           |   10 +-
>  drivers/usb/core/hcd.c                             |   56 ++
>  drivers/usb/gadget/udc/udc-core.c                  |  161 ++-
>  drivers/usb/host/xhci-plat.c                       |   35 +-
>  drivers/usb/phy/Kconfig                            |    2 +-
>  drivers/usb/phy/phy-fsl-usb.c                      |  155 +--
>  drivers/usb/phy/phy-fsl-usb.h                      |    3 +-
>  include/linux/usb/gadget.h                         |   20 +
>  include/linux/usb/hcd.h                            |   29 +
>  include/linux/usb/of.h                             |    9 +
>  include/linux/usb/otg-fsm.h                        |  154 +--
>  include/linux/usb/otg.h                            |  264 ++++-
>  include/linux/usb/xhci_pdriver.h                   |    3 +
>  27 files changed, 1989 insertions(+), 484 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
>  copy drivers/usb/{chipidea/otg_fsm.h => common/usb-otg.h} (63%)
> 
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1398949

On 11/05/16 11:36, Peter Chen wrote:
> On Mon, May 02, 2016 at 03:18:43PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> This series centralizes OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm and am437x-gp-evm.
>>
>> DWC3 controller and platform related patches will be sent separately.
>>
>> Series is based on v4.6-rc1 and depends on first 2 patches of [1]
>> [1] - OTG fsm cleanup - https://lkml.org/lkml/2016/3/30/186
>>
>> Why?:
>> ----
>>
>> Currently there is no central location where OTG/dual-role functionality is
>> implemented in the Linux USB stack and every USB controller driver is
>> doing their own thing for OTG/dual-role. We can benefit from code-reuse
>> and simplicity by adding the OTG/dual-role core driver.
>>
>> Newer OTG cores support standard host interface (e.g. xHCI) so
>> host and gadget functionality are no longer closely knit like older
>> cores. There needs to be a way to co-ordinate the operation of the
>> host and gadget controllers in dual-role mode. i.e. to stop and start them
>> from a central location. This central location should be the
>> USB OTG/dual-role core.
>>
>> Host and gadget controllers might be sharing resources and can't
>> be always running. One has to be stopped for the other to run.
>> This couldn't be done till now but can be done from the OTG core.
>>
>> What?:
>> -----
>>
>> The OTG/dual-role core consists of a set of APIs that allow
>> registration of OTG controller device and OTG capable host and gadget
>> controllers.
>>
>> - The OTG controller driver can provide the OTG capabilities and the
>> Finite State Machine work function via 'struct usb_otg_config'
>> at the time of registration i.e. usb_otg_register();
>>
>> 	struct usb_otg *usb_otg_register(struct device *dev,
>>         	                         struct usb_otg_config *config);
>> 	int usb_otg_unregister(struct device *dev);
>> 	/**
>> 	 * struct usb_otg_config - otg controller configuration
>> 	 * @caps: otg capabilities of the controller
>> 	 * @ops: otg fsm operations
>> 	 * @otg_work: optional custom otg state machine work function
>> 	 */
>> 	struct usb_otg_config {
>> 	        struct usb_otg_caps *otg_caps;
>> 	        struct otg_fsm_ops *fsm_ops;
>> 	        void (*otg_work)(struct work_struct *work);
>> 	};
>>
>> The dual-role state machine is built-into the OTG core so nothing
>> special needs to be provided if only dual-role functionality is desired.
>> The low level OTG controller driver ops are povided via
>> 'struct otg_fsm_ops *fsm_ops' in the 'struct usb_otg_config'.
>>
>> After registration, the OTG core waits for host, gadget controller
>> and the gadget function driver to be registered. Once all resources are
>> available it instantiates the Finite State Machine (FSM).
>> The host/gadget controllers are started/stopped according to the FSM.
>>
>> - Host and gadget controllers that are a part of OTG/dual-role port must
>> use the OTG core provided APIs to add/remove the host/gadget.
>> i.e. hosts must use usb_otg_add_hcd() usb_otg_remove_hcd(),,
>> gadgets must use usb_otg_add_gadget_udc() usb_del_gadget_udc().
>> This ensures that the host and gadget controllers are not started till
>> the state machine is ready and the right bus conditions are met.
>> It also allows the host and gadget controllers to provide the OTG
>> controller device to link them together. For Device tree boots
>> the related OTG controller is automatically picked up via the
>> 'otg-controller' property in the Host/Gadget controller nodes.
>>
>> 	int usb_otg_add_hcd(struct usb_hcd *hcd,
>> 			    unsigned int irqnum, unsigned long irqflags,
>> 			    struct device *otg_dev);
>> 	void usb_otg_remove_hcd(struct usb_hcd *hcd);
>>
>> 	int usb_otg_add_gadget_udc(struct device *parent,
>> 				   struct usb_gadget *gadget,
>> 				   struct device *otg_dev);
>> 	usb_del_gadget_udc() must be used for removal.
>>
>>
>> - During the lifetime of the FSM, the OTG controller driver can provide
>> inputs event changes using usb_otg_sync_inputs(). The OTG core will
>> then schedule the FSM work function (or internal dual-role state machine)
>> to update the FSM state. The FSM then calls the OTG controller
>> operations (fsm_ops) as necessary.
>> 	void usb_otg_sync_inputs(struct usb_otg *otg);
>>
>> - The following 2 functions are provided as helpers for use by the
>> OTG controller driver to start/stop the host/gadget controllers.
>> 	int usb_otg_start_host(struct usb_otg *otg, int on);
>> 	int usb_otg_start_gadget(struct usb_otg *otg, int on);
>>
>> - The following function is provided for use by the USB host stack
>> to sync OTG related events to the OTG state machine.
>> e.g. change in host_bus->b_hnp_enable, gadget->b_hnp_enable
>> 	int usb_otg_kick_fsm(struct device *otg_device);
>>
>> Changelog:
>> ---------
>> v7:
>> - added dual-role support for host controllers requiring a companion
>> controller. e.g. EHCI + OHCI.
>> - added of_usb_get_otg() to get the OTG controller device
>> from the USB controller's device node.
>> - addressed review comments.
> 
> Would you please list more for review comments, eg which comment for
> which part? It is a big patch set, that will let review easy.

Yes. I will do so for v8.

cheers,
-roger

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web