ehci: speed up initialization

PATCH New Vincent Palatin 4 participants 9 messages Dec 5, 2011 – Dec 20, 2011

Subsystems (2)

USB USB ehci driver

lore

Share & tools

lore

Vincent Palatin

author

2011-12-05 22:52 UTC #0 lore raw

PATCH 1/1 ehci: speed up initialization

According to EHCI specification v1.0, the controller should stabilize the power on a port at most 20 ms after the port power bit transition. So, we put this setting in the virtual descriptor corresponding field, (bPwrOn2PwrGood = 10 => 10 x 2ms = 20ms), this saves about 500ms at each controller initialization/enumeration.

Signed-off-by Vincent Palatin <[email protected]>

---
 drivers/usb/host/ehci-hcd.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

drivers/usb/host/ehci-hcd.c +1 -1

index 2197119..caa0cfb 100644
@@ -48,7 +48,7 @@ static struct descriptor {
 		0x29,		/* bDescriptorType: hub descriptor */
 		2,		/* bNrPorts -- runtime modified */
 		0,		/* wHubCharacteristics */
-		0xff,		/* bPwrOn2PwrGood */
+		10,		/* bPwrOn2PwrGood */
 		0,		/* bHubCntrCurrent */
 		{},		/* Device removable */
 		{}		/* at most 7 ports! XXX */

Signature · 1 line

1.7.3.1

Remy Bohmer

2011-12-10 16:29 UTC #1 lore raw

PATCH 1/1 ehci: speed up initialization

Hi,

2011/12/5 Vincent Palatin <[email protected]>:

Quoted 10 lines

According to EHCI specification v1.0, the controller should stabilize the power on a port at most 20 ms after the port power bit transition. So, we put this setting in the virtual descriptor corresponding field, (bPwrOn2PwrGood = 10 => 10 x 2ms = 20ms), this saves about 500ms at each controller initialization/enumeration.
Signed-off-by Vincent Palatin <[email protected]>
---
?drivers/usb/host/ehci-hcd.c | ? ?2 +-
?1 files changed, 1 insertions(+), 1 deletions(-)

Applied to u-boot-usb.

Kind regards,

Remy

Wolfgang Grandegger

2011-12-19 12:07 UTC #2 lore raw

PATCH 1/1 ehci: speed up initialization

Quoted 9 lines · Remy Bohmer

Hi,
2011/12/5 Vincent Palatin <[email protected]>:
Quoted 6 lines
According to EHCI specification v1.0, the controller should stabilize the power on a port at most 20 ms after the port power bit transition. So, we put this setting in the virtual descriptor corresponding field, (bPwrOn2PwrGood = 10 => 10 x 2ms = 20ms), this saves about 500ms at each controller initialization/enumeration.

Quoted 6 lines

Quoted 4 lines
Signed-off-by Vincent Palatin <[email protected]>
---
 drivers/usb/host/ehci-hcd.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Applied to u-boot-usb.

I just realized that this patch breaks "usb start" on my mx53loco board:

MX53LOCO U-Boot > usb start
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 0 Ethernet Device(s) found

MX53LOCO U-Boot > usb start
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found

The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.

Wolfgang.

Vincent Palatin

author

2011-12-19 12:51 UTC #3 lore raw

PATCH 1/1 ehci: speed up initialization

Quoted 18 lines · Wolfgang Grandegger

I just realized that this patch breaks "usb start" on my mx53loco board:
?MX53LOCO U-Boot > usb start
?(Re)start USB...
?USB: ? Register 10011 NbrPorts 1
?USB EHCI 1.00
?scanning bus for devices... 1 USB Device(s) found
? ? ? ? scanning bus for storage devices... 0 Storage Device(s) found ? ? ? ? scanning bus for ethernet devices... 0 Ethernet Device(s) found
?MX53LOCO U-Boot > usb start
?(Re)start USB...
?USB: ? Register 10011 NbrPorts 1
?USB EHCI 1.00
?scanning bus for devices... 2 USB Device(s) found
? ? ? ? scanning bus for storage devices... 0 Storage Device(s) found ? ? ? ? scanning bus for ethernet devices... 1 Ethernet Device(s) found

Quoted 3 lines

The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.

This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk.

Signature · 1 line

Vincent

Wolfgang Grandegger

2011-12-19 13:31 UTC #4 lore raw

PATCH 1/1 ehci: speed up initialization

Quoted 23 lines · Vincent Palatin

Quoted 18 lines · Wolfgang Grandegger
I just realized that this patch breaks "usb start" on my mx53loco board:
MX53LOCO U-Boot > usb start
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 0 Ethernet Device(s) found
MX53LOCO U-Boot > usb start
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found
Quoted 3 lines
The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.

Quoted 5 lines

This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk.

I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See:

http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567

Wolfgang.

Remy Bohmer

2011-12-19 16:59 UTC #5 lore raw

PATCH 1/1 ehci: speed up initialization

Hi Wolfgang,

2011/12/19 Wolfgang Grandegger <[email protected]>:

Quoted 14 lines · Vincent Palatin

Quoted 7 lines · Wolfgang Grandegger
Quoted 5 lines
I just realized that this patch breaks "usb start" on my mx53loco board:
The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.
Quoted 5 lines
This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk.

Quoted 4 lines

I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See:
?http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567

I would prefer a solution in line with the specification, but what is the reason why Linux takes 100 msec here?
Is that just chosen randomly , or was there a good reason for it? If there is a good reason (which I assume) I would prefer to follow Linux here and go for the 100 msec.

Can you please provide a patch?

Kind regards,

Remy

Vincent Palatin

author

2011-12-19 18:18 UTC #6 lore raw

PATCH 1/1 ehci: speed up initialization

Quoted 17 lines · Remy Bohmer

Hi Wolfgang,
2011/12/19 Wolfgang Grandegger <[email protected]>:
Quoted 14 lines · Vincent Palatin
Quoted 12 lines · Wolfgang Grandegger
Quoted 5 lines
I just realized that this patch breaks "usb start" on my mx53loco board:
The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.
This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk.

Quoted 7 lines

Quoted 4 lines
I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See:
?http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567
I would prefer a solution in line with the specification, but what is the reason why Linux takes 100 msec here?

The patch adding this delay was the following one :

commit b789696af8b4102b7cc26dec30c2c51ce51ee18b

Author: David Brownell <[email protected]>
Date:   Wed Aug 31 10:41:44 2005 -0700

[PATCH] USB: relax usbcore reset timings

This appears to help some folk, please merge.
This patch relaxes reset timings. There are some reports that it helps make enumeration work better on some high speed devices.

Signed-off-by David Brownell <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Quoted 1 line

Is that just chosen randomly , or was there a good reason for it?

So random timings based on user inputs.

Signature · 1 line

Vincent Palatin

Wolfgang Grandegger

2011-12-20 16:10 UTC #7 lore raw

PATCH 1/1 ehci: speed up initialization

In reply to Remy Bohmer

Quoted 22 lines · Remy Bohmer

Hi Wolfgang,
2011/12/19 Wolfgang Grandegger <[email protected]>:
Quoted 14 lines · Vincent Palatin
Quoted 7 lines · Wolfgang Grandegger
Quoted 5 lines
I just realized that this patch breaks "usb start" on my mx53loco board:
The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.
Quoted 5 lines
This doesn't match the EHCI standard which explicity states that the power should be good after 20ms (paragraph 2.3.9 in EHCI 1.0), so we should probably find whether we are missing another delay somewhere in the generic EHCI code (which used to be hidden and should be fixed) or if i.MX53 is not compliant with the standard and need a special quirk.
Quoted 4 lines
I'm not an USB expert but if I look into the hub_power_on() function of the Linux kernel it waits at least 100ms (and only once). See:
http://lxr.linux.no/#linux+v3.1.5/drivers/usb/core/hub.c#L567

Quoted 7 lines

I would prefer a solution in line with the specification, but what is the reason why Linux takes 100 msec here?
Is that just chosen randomly , or was there a good reason for it? If there is a good reason (which I assume) I would prefer to follow Linux here and go for the 100 msec.
Can you please provide a patch?

OK, should find time tomorrow.

Wolfgang.

Wolfgang Denk

2011-12-19 15:32 UTC #8 lore raw

PATCH 1/1 ehci: speed up initialization

In reply to Wolfgang Grandegger

Dear Wolfgang Grandegger,

Quoted 4 lines · In message <[email protected]> you wrote:

The device is not found at the first attempt. Obviously, a value of 10 for bPwrOn2PwrGood seems too short but 20 works fine. Would that be a resonable compromise? If yes, I could send a patch.

If 10 doesn't work, but 20 does, then we should use at least 25 or even 30.

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
The inappropriate cannot be beautiful.
             - Frank Lloyd Wright _The Future of Architecture_ (1953)