Skip to contentSkip to conversation

USB: EHCI: Initialize multiple USB controllers at once

PATCH Superseded Jim Lin 4 participants 11 messages Jun 26, 2012 – Jul 31, 2012 5 messages not in the archive

Subsystems (3)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Jim Lin

author
#0 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Add support for command line "usb reset" or "usb start" to initialize , "usb stop" to stop multiple USB controllers at once. Other commands like "usb tree" also support multiple controllers.

New added definitions to be defined in header file are:
CONFIG_USB_INIT_MULTI CONFIG_USB_MAX_CONTROLLER_COUNT

---
 common/cmd_usb.c              |   10 +++
 common/usb.c                  |  100 +++++++++++++++++++++++++++-
 common/usb_hub.c              |    4 +
 drivers/usb/host/ehci-hcd.c   |  150 +++++++++++++++++++++++++++++-----------
 drivers/usb/host/ehci-tegra.c |    2 +-
 drivers/usb/host/ehci.h       |    5 ++
 include/usb.h                 |   10 +++
 7 files changed, 237 insertions(+), 44 deletions(-)
common/cmd_usb.c +10 -0
index 9eba271..4c01a78 100644
@@ -553,7 +553,17 @@ int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
        }
        if (strncmp(argv[1], "tree", 4) == 0) {
                printf("\nDevice Tree:\n");
+#ifdef CONFIG_USB_INIT_MULTI
+               for (i = 0; i < USB_MAX_DEVICE; i++) {
+                       dev = usb_get_dev_index(i);
+                       if (dev == NULL)
+                               break;
+                       if (dev->parent == NULL)
+                               usb_show_tree(dev);
+               }
+#else
                usb_show_tree(usb_get_dev_index(0));
+#endif
                return 0;
        }
        if (strncmp(argv[1], "inf", 3) == 0) {
common/usb.c +98 -2

149 lines not on this page · raw message

common/usb_hub.c +4 -0
index e0edaad..6c27761 100644
@@ -243,7 +243,11 @@ void usb_hub_port_connect_change(struct usb_device *dev, int port)
        mdelay(200);
 
        /* Allocate a new device struct for it */
+#ifdef CONFIG_USB_INIT_MULTI
+       usb = usb_alloc_new_device(dev->controller);
+#else
        usb = usb_alloc_new_device();
+#endif
 
        if (portstatus & USB_PORT_STAT_HIGH_SPEED)
                usb->speed = USB_SPEED_HIGH;
drivers/usb/host/ehci-hcd.c +109 -41

307 lines not on this page · raw message

drivers/usb/host/ehci-tegra.c +1 -1
index a7e105b..f7fd6a7 100644
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009 NVIDIA Corporation
+ * Copyright (c) 2009-2012 NVIDIA Corporation
  *
  * See file CREDITS for list of people who contributed to this
  * project.
drivers/usb/host/ehci.h +5 -0
index cc00ce4..059827a 100644
@@ -201,7 +201,12 @@ struct QH {
 };
 
 /* Low level init functions */
+#ifdef CONFIG_USB_INIT_MULTI
+int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor);
+int ehci_hcd_stop(int index);
+#else
 int ehci_hcd_init(void);
 int ehci_hcd_stop(void);
+#endif
 
 #endif /* USB_EHCI_H */
include/usb.h +10 -0
index 48e4bcd..0ac6ed4 100644
@@ -128,6 +128,7 @@ struct usb_device {
        int portnr;
        struct usb_device *parent;
        struct usb_device *children[USB_MAXCHILDREN];
+       void *controller;               /* hardware controller private data */
 };
 
 /**********************************************************************
@@ -141,8 +142,13 @@ struct usb_device {
        defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \
        defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X)
 
+#ifdef CONFIG_USB_INIT_MULTI
+void *usb_lowlevel_init(int index);
+int usb_lowlevel_stop(int index);
+#else
 int usb_lowlevel_init(void);
 int usb_lowlevel_stop(void);
+#endif
 int submit_bulk_msg(struct usb_device *dev, unsigned long pipe,
                        void *buffer, int transfer_len);
 int submit_control_msg(struct usb_device *dev, unsigned long pipe, void *buffer,
@@ -370,7 +376,11 @@ void usb_hub_reset(void);
 int hub_port_reset(struct usb_device *dev, int port,
                          unsigned short *portstat);
 
+#ifdef CONFIG_USB_INIT_MULTI
+struct usb_device *usb_alloc_new_device(void *controller);
+#else
 struct usb_device *usb_alloc_new_device(void);
+#endif
 int usb_new_device(struct usb_device *dev);
 
 #endif /*_USB_H_ */

--
1.7.3

nvpublic

#1 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

Quoted 3 lines · In message <[email protected]>…

Add support for command line "usb reset" or "usb start" to initialize , "usb stop" to stop multiple USB controllers at once. Other commands like "usb tree" also support multiple controllers.

Why would this be needed?

U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself.

So why?

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A failure will not appear until a unit has passed final inspection.

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

sending the very same message eight (8!) times doesnot make it a bit more convincing - on contrary.

Quoted 8 lines · In message <[email protected]>…
Quoted 6 lines

U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself.

So why?

Because of this complaint and request for devices under different controllers to be working at same time.

You make another claim here, but don't explain how this is supposed to work or whay the exact use case would be where this was needed. U-Boot will not be able to access multiple devices at the same time, so why would it be necessary to enable these? It should be sufficient to enable the controller that is responsible for the single device that is currently being used.

Quoted 8 lines

"One particularly annoying consequence of this is when you use the Seaboard configuration on Springbank.
Seaboard selects Tegra's USB3 as "usb 0" device, which is the one you can use, in order not to conflict with the flashing USB port USB1. However, Springbank only exposes USB1 since USB3 is used internally for the USB keyboard/mouse. As such, you cannot use the USB port on Springbank under U-Boot at the moment.
"

I have to admit that I cannot make any sense from this statement. The only thing I understand is that you are trying to use a configuration for one hardware (Seaboard) on another, incompatible hardware (Springbank).

The simple answer to this problem is: don't do that, then.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
        Ordnung ist die Lust der Vernunft,
        aber Unordnung die Wonne der Phantasie         - Paul Claudel
#8 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Quoted 31 lines · Wolfgang Denk

Dear Jim Lin,

sending the very same message eight (8!) times doesnot make it a bit more convincing - on contrary.

Quoted 8 lines · In message <[email protected]>…
Quoted 6 lines

U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself.

So why?

Because of this complaint and request for devices under different controllers to be working at same time.

You make another claim here, but don't explain how this is supposed to work or whay the exact use case would be where this was needed. U-Boot will not be able to access multiple devices at the same time, so why would it be necessary to enable these? It should be sufficient to enable the controller that is responsible for the single device that is currently being used.

Quoted 8 lines

"One particularly annoying consequence of this is when you use the Seaboard configuration on Springbank.
Seaboard selects Tegra's USB3 as "usb 0" device, which is the one you can use, in order not to conflict with the flashing USB port USB1. However, Springbank only exposes USB1 since USB3 is used internally for the USB keyboard/mouse. As such, you cannot use the USB port on Springbank under U-Boot at the moment.
"

Quoted 6 lines

I have to admit that I cannot make any sense from this statement. The only thing I understand is that you are trying to use a configuration for one hardware (Seaboard) on another, incompatible hardware (Springbank).

The simple answer to this problem is: don't do that, then.

Seaboard and Springbank are essentially the same board, and hence are almost 100% SW compatible, so there's no problem running a Seaboard build of U-Boot/kernel/... on Springbank.

The primary issue here is that many boards have multiple USB ports. Users could plug e.g. a USB->Ethernet device into any of the ports. Requiring the user to know which port is which ID so they can issue the correct "usb start <n>" command is painful; no other SW stack limits itself to a single port and so most people don't have a clue which ports are numbered what; they just want USB to work.

The specific issue on Springbank is that there are multiple USB ports that are useful at the essentially the same time. One of the USB ports hosts a built-in USB keyboard (inside a sealed clamshell/netbook case), which we would like to use for the U-boot console. Another USB port is external, and people will plug in a USB->Ethernet dongle or USB storage device there. so, if I need to "usb start 0" to get the keyboard, and "usb start 1" to get USB Ethernet, then as soon as I "usb start 1" to get the Ethernet, I've just lost the console, and am unable to interact with U-Boot any more...

author
#9 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Quoted 57 lines

-----Original Message-----
From: Stephen Warren [mailto:swarren at wwwdotorg.org]
Sent: Thursday, June 28, 2012 12:58 AM
To: Wolfgang Denk>
Cc: Jim Lin; 'U-Boot at lists.denx.de'; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Quoted 32 lines · Wolfgang Denk

Dear Jim Lin,

sending the very same message eight (8!) times doesnot make it a bit more convincing - on contrary.

Quoted 8 lines · In message <[email protected]>…
Quoted 6 lines

U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself.>

So why?

Because of this complaint and request for devices under different controllers to be working at same time.

You make another claim here, but don't explain how this is supposed to work or whay the exact use case would be where this was needed. U-Boot will not be able to access multiple devices at the same time, so why would it be necessary to enable these? It should be sufficient to enable the controller that is responsible for the single device that is currently being used.

Quoted 8 lines

"One particularly annoying consequence of this is when you use the Seaboard configuration on Springbank.
Seaboard selects Tegra's USB3 as "usb 0" device, which is the one you can use, in order not to conflict with the flashing USB port USB1. However, Springbank only exposes USB1 since USB3 is used internally for the USB keyboard/mouse. As such, you cannot use the USB port on Springbank under U-Boot at the moment.
"

Quoted 6 lines

I have to admit that I cannot make any sense from this statement. The only thing I understand is that you are trying to use a configuration for one hardware (Seaboard) on another, incompatible hardware (Springbank).

The simple answer to this problem is: don't do that, then.

Seaboard and Springbank are essentially the same board, and hence are almost 100% SW compatible, so there's no problem running a Seaboard build of U-Boot/kernel/... on Springbank.

The primary issue here is that many boards have multiple USB ports. Users could plug e.g. a USB->Ethernet device into any of the ports. Requiring the user to know which port is which ID so they can issue the correct "usb start <n>" command is painful; no other SW stack limits itself to a single port and so most people don't have a clue which ports are numbered what; they just want USB to work.

Quoted 9 lines

The specific issue on Springbank is that there are multiple USB ports that are useful at the essentially the same time. One of the USB ports hosts a built-in USB keyboard (inside a sealed clamshell/netbook case), which we would like to use for the U-boot console. Another USB port is external, and people will plug in a USB->Ethernet dongle or USB storage device there. so, if I need to "usb start 0" to get the keyboard, and "usb start 1" to get USB Ethernet, then as soon as I "usb start 1" to get the Ethernet, I've just lost the console, and am unable to interact with U-Boot any more..

Wolfgang,
Any further thought about Stephen's request?
Thanks.

nvpublic

author
#10 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

In reply to Stephen Warren

Wolfgang,
Is there any chance to get this feature in after Stephen explained to you?

Thanks.

Quoted 57 lines

-----Original Message-----
From: Stephen Warren [mailto:swarren at wwwdotorg.org]
Sent: Thursday, June 28, 2012 12:58 AM
To: Wolfgang Denk
Cc: Jim Lin; 'U-Boot at lists.denx.de'; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Quoted 31 lines · Wolfgang Denk

Dear Jim Lin,

sending the very same message eight (8!) times doesnot make it a bit more convincing - on contrary.

Quoted 8 lines · In message <[email protected]>…
Quoted 6 lines

U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself.

So why?

Because of this complaint and request for devices under different controllers to be working at same time.

You make another claim here, but don't explain how this is supposed to work or whay the exact use case would be where this was needed. U-Boot will not be able to access multiple devices at the same time, so why would it be necessary to enable these? It should be sufficient to enable the controller that is responsible for the single device that is currently being used.

Quoted 8 lines

"One particularly annoying consequence of this is when you use the Seaboard configuration on Springbank.
Seaboard selects Tegra's USB3 as "usb 0" device, which is the one you can use, in order not to conflict with the flashing USB port USB1. However, Springbank only exposes USB1 since USB3 is used internally for the USB keyboard/mouse. As such, you cannot use the USB port on Springbank under U-Boot at the moment.
"

Quoted 6 lines

I have to admit that I cannot make any sense from this statement. The only thing I understand is that you are trying to use a configuration for one hardware (Seaboard) on another, incompatible hardware (Springbank).

The simple answer to this problem is: don't do that, then.

Seaboard and Springbank are essentially the same board, and hence are almost 100% SW compatible, so there's no problem running a Seaboard build of U-Boot/kernel/... on Springbank.

The primary issue here is that many boards have multiple USB ports. Users could plug e.g. a USB->Ethernet device into any of the ports. Requiring the user to know which port is which ID so they can issue the correct "usb start <n>" command is painful; no other SW stack limits itself to a single port and so most people don't have a clue which ports are numbered what; they just want USB to work.

Quoted 9 lines

The specific issue on Springbank is that there are multiple USB ports that are useful at the essentially the same time. One of the USB ports hosts a built-in USB keyboard (inside a sealed clamshell/netbook case), which we would like to use for the U-boot console. Another USB port is external, and people will plug in a USB->Ethernet dongle or USB storage device there. so, if I need to "usb start 0" to get the keyboard, and "usb start 1" to get USB Ethernet, then as soon as I "usb start 1" to get the Ethernet, I've just lost the console, and am unable to interact with U-Boot any more...

--
nvpublic

#11 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

Quoted 4 lines

Wolfgang,
Is there any chance to get this feature in after Stephen explained to you?

Thanks.

[...]

I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the controller number to 1 for those that don't define CONFIG_USB_MULTI now (everyone) and adding some wrapping goo?

Best regards,
Marek Vasut

author
#12 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Quoted 7 lines

-----Original Message-----
From: Marek Vasut [mailto:marek.vasut at gmail.com]
Sent: Friday, July 27, 2012 5:26 PM
To: u-boot at lists.denx.de
Cc: Jim Lin; Wolfgang Denk; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Quoted 6 lines
Quoted 3 lines

Wolfgang,
Is there any chance to get this feature in after Stephen explained to you?

I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the controller number to 1 for those that don't define CONFIG_USB_MULTI now (everyone)

I assume you want me to add these in next patch.
1 . Use CONFIG_USB_MULTI, instead of CONFIG_USB_INIT_MULTI
(current patch),
2. If CONFIG_USB_MULTI is not defined, then define CONFIG_USB_MAX_CONTROLLER_COUNT as 1.

Quoted 1 line

and adding some wrapping goo?

Don't understand what you meant.
Could you provide an example?
Thanks.

nvpublic

#13 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

Quoted 16 lines
Quoted 8 lines

-----Original Message-----
From: Marek Vasut [mailto:marek.vasut at gmail.com]
Sent: Friday, July 27, 2012 5:26 PM
To: u-boot at lists.denx.de
Cc: Jim Lin; Wolfgang Denk; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Quoted 7 lines
Quoted 3 lines

Wolfgang,
Is there any chance to get this feature in after Stephen explained to you?

I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the controller number to 1 for those that don't define CONFIG_USB_MULTI now (everyone)

Quoted 5 lines

I assume you want me to add these in next patch. 1 . Use CONFIG_USB_MULTI, instead of CONFIG_USB_INIT_MULTI
(current patch),
2. If CONFIG_USB_MULTI is not defined, then define CONFIG_USB_MAX_CONTROLLER_COUNT as 1.

Yes, is that a problem? Aka. have this always enabled and don't treat not having multiple controllers as a special case.

Quoted 4 lines
Quoted 1 line

and adding some wrapping goo?

Don't understand what you meant.
Could you provide an example?

Just don't treat having 1 controller as a special case, that's all I meant.

Quoted 3 lines

Thanks.

nvpublic

Best regards,
Marek Vasut

author
#14 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Quoted 25 lines

-----Original Message-----
From: Marek Vasut [mailto:marek.vasut at gmail.com]
Sent: Monday, July 30, 2012 8:02 PM
To: Jim Lin
Cc: Wolfgang Denk; Tom Warren; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

Quoted 16 lines
Quoted 15 lines

-----Original Message-----
From: Marek Vasut [mailto:marek.vasut at gmail.com]
Sent: Friday, July 27, 2012 5:26 PM
To: u-boot at lists.denx.de
Cc: Jim Lin; Wolfgang Denk; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Quoted 3 lines

Wolfgang,
Is there any chance to get this feature in after Stephen explained to you?

I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the controller number to 1 for those that don't define CONFIG_USB_MULTI now (everyone)

Quoted 8 lines
Quoted 5 lines

I assume you want me to add these in next patch. 1 . Use CONFIG_USB_MULTI, instead of CONFIG_USB_INIT_MULTI
(current patch),
2. If CONFIG_USB_MULTI is not defined, then define CONFIG_USB_MAX_CONTROLLER_COUNT as 1.

Yes, is that a problem? Aka. have this always enabled and don't treat not having multiple controllers as a special case.

Item 2 is not necessary.
Because CONFIG_USB_MAX_CONTROLLER_COUNT will not be used if CONFIG_USB_MULTI is not defined.

--
nvpublic

#15 lore raw

PATCH 1/1 USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

Quoted 34 lines
Quoted 34 lines

-----Original Message-----
From: Marek Vasut [mailto:marek.vasut at gmail.com]
Sent: Monday, July 30, 2012 8:02 PM
To: Jim Lin
Cc: Wolfgang Denk; Tom Warren; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Dear Jim Lin,

Quoted 23 lines
Quoted 8 lines

-----Original Message-----
From: Marek Vasut [mailto:marek.vasut at gmail.com]
Sent: Friday, July 27, 2012 5:26 PM
To: u-boot at lists.denx.de
Cc: Jim Lin; Wolfgang Denk; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

Quoted 7 lines
Quoted 3 lines

Wolfgang,
Is there any chance to get this feature in after Stephen explained to you?

I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the controller number to 1 for those that don't define CONFIG_USB_MULTI now (everyone)

I assume you want me to add these in next patch. 1 . Use CONFIG_USB_MULTI, instead of CONFIG_USB_INIT_MULTI

(current patch),

2. If CONFIG_USB_MULTI is not defined, then define CONFIG_USB_MAX_CONTROLLER_COUNT as 1.

Quoted 6 lines
Quoted 2 lines

Yes, is that a problem? Aka. have this always enabled and don't treat not having multiple controllers as a special case.

Item 2 is not necessary.
Because CONFIG_USB_MAX_CONTROLLER_COUNT will not be used if CONFIG_USB_MULTI is not defined.

But we don't need CONFIG_USB_MULTI option at all -- just assume it's always defined and unless a board has multiple controllers, define CONFIG_USB_MAX_CONTROLLER_COUNT to be 1.

Aka. it boils down to sticking

#ifndef CONFIG_USB_MAX_CONTROLLER_COUNT
#define CONFIG_USB_MAX_CONTROLLER_COUNT 1
#endif

somewhere in usb.c or so.

Best regards,
Marek Vasut