[U-Boot] [PATCH] ehci: speed up initialization

[U-Boot] [PATCH] ehci: speed up initialization

[Vincent Palatin]

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 */
-- 
1.7.3.1

[U-Boot] [PATCH] ehci: speed up initialization

[Remy Bohmer]

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

[U-Boot] [PATCH] ehci: speed up initialization

[Wolfgang Grandegger]

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.

[U-Boot] [PATCH] ehci: speed up initialization

[Vincent Palatin]

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.

-- 
Vincent

[U-Boot] [PATCH] ehci: speed up initialization

[Wolfgang Grandegger]

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.

[U-Boot] [PATCH] ehci: speed up initialization

[Wolfgang Denk]

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

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

[U-Boot] [PATCH] ehci: speed up initialization

[Remy Bohmer]

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

[U-Boot] [PATCH] ehci: speed up initialization

[Vincent Palatin]

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.

-- 
Vincent Palatin

[U-Boot] [PATCH] ehci: speed up initialization

[Wolfgang Grandegger]

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.