[U-Boot] [PATCH 2/2] usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY

[Tim Harvey]

On Tue, Jun 3, 2014 at 9:38 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 06/03/2014 10:17 AM, Tim Harvey wrote:
>> On Mon, May 19, 2014 at 1:21 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> Now that we wait the correct specification-mandated time at the end of
>>> usb_hub_power_on(), I suspect that CONFIG_USB_HUB_MIN_POWER_ON_DELAY has
>>> no purpose.
>>>
>>> For cm_t35.h, we already wait longer than the original MIN_POWER_ON_DELAY,
>>> so this change is safe.
>>>
>>> For gw_ventana.h, we will wait as long as the original MIN_POWER_ON_DELAY
>>> iff pgood_delay was at least 200ms. I'm not sure if this is the case or
>>> not, hence I've CC'd relevant people to test this change.
>
>>> diff --git a/include/configs/gw_ventana.h b/include/configs/gw_ventana.h
>
>>> -#define CONFIG_USB_HUB_MIN_POWER_ON_DELAY 1200
>
>> Stephen,
>>
>> Sorry for the late reply - I'm just getting around to testing this
>> (and I realize that Marek already committed it which is ok by me).
>>
>> I have a variety of USB Mass Storage devices that I tested when I was
>> looking at this and out of about 12 devices I found I had 1 'usb
>> stick' that requires 2100ms in order to respond and be successfully
>
> Was that 2100ms or 1200ms? I ask because gw_ventana.h only had 1200, so
> if devices require 2100ms then they presumably didn't work with the code
> before my patch?

it was 2100ms for that particular device. I don't have in my notes why
I chose 1200 over 1000 but a quick test today showed all other USB
sticks I have worked fine with your 1000ms change.

>
>> scanned: 048d:1327 Integrated Technology Express, Inc 32GB USB stick.
>> I also found that rotational media (ie Seagate and Western Digital USB
>> drives) would not respond in 1000ms either which didn't surprise me as
>> I figured they needed some extra spin-up time. For all other devices I
>> had I found that 1000ms was adequate.
>>
>> So do these devices I mention simply violate the USB spec?
>
> I *think* so yes.
>
>> I wonder if the delay should be able to be overridden with an env var
>> or an argument to 'usb start' to account for devices like this?
>
> Yes, perhaps it is worth U-Boot probing for longer than the minimum
> time, either always or on-demand as requested by an environment
> variable. The only downside would be that "usb start" would take longer
> even in the absence of these broken(?) devices if we always delay
> longer, rather than triggering the process via an environment variable.
> Marek, what are your thoughts?

I wouldn't want to hard code a longer default and make everyone else
pay for abnormal devices.

Tim