[U-Boot] [PATCH] 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 vpalatin@chromium.org --- drivers/usb/host/ehci-hcd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 2197119..caa0cfb 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -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 */
Hi,
2011/12/5 Vincent Palatin vpalatin@chromium.org:
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 vpalatin@chromium.org
drivers/usb/host/ehci-hcd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Applied to u-boot-usb.
Kind regards,
Remy
On 12/10/2011 05:29 PM, Remy Bohmer wrote:
Hi,
2011/12/5 Vincent Palatin vpalatin@chromium.org:
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 vpalatin@chromium.org
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.
Wolfgang.
On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger wg@grandegger.com wrote:
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.
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.
On 12/19/2011 01:51 PM, Vincent Palatin wrote:
On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger wg@grandegger.com wrote:
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.
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.
Hi Wolfgang,
2011/12/19 Wolfgang Grandegger wg@grandegger.com:
On 12/19/2011 01:51 PM, Vincent Palatin wrote:
On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger wg@grandegger.com wrote:
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.
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
On Mon, Dec 19, 2011 at 08:59, Remy Bohmer linux@bohmer.net wrote:
Hi Wolfgang,
2011/12/19 Wolfgang Grandegger wg@grandegger.com:
On 12/19/2011 01:51 PM, Vincent Palatin wrote:
On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger wg@grandegger.com wrote:
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.
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 david-b@pacbell.net 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 dbrownell@users.sourceforge.net Signed-off-by: Greg Kroah-Hartman gregkh@suse.de
Is that just chosen randomly , or was there a good reason for it?
So random timings based on user inputs.
On 12/19/2011 05:59 PM, Remy Bohmer wrote:
Hi Wolfgang,
2011/12/19 Wolfgang Grandegger wg@grandegger.com:
On 12/19/2011 01:51 PM, Vincent Palatin wrote:
On Mon, Dec 19, 2011 at 04:07, Wolfgang Grandegger wg@grandegger.com wrote:
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.
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?
OK, should find time tomorrow.
Wolfgang.
Dear Wolfgang Grandegger,
In message 4EEF290B.9060106@grandegger.com 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
participants (4)
-
Remy Bohmer -
Vincent Palatin -
Wolfgang Denk -
Wolfgang Grandegger