From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY
Date: Tue, 03 Jun 2014 10:38:30 -0600 [thread overview]
Message-ID: <538DFA06.7040805@wwwdotorg.org> (raw)
In-Reply-To: <CAJ+vNU18UKhxvn+KEyMg=D2sOZ59dnRv7xJ1nxOtYJAh4GFCew@mail.gmail.com>
On 06/03/2014 10:17 AM, Tim Harvey wrote:
> On Mon, May 19, 2014 at 1:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@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?
> 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?
next prev parent reply other threads:[~2014-06-03 16:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 20:21 [U-Boot] [PATCH 1/2] usb: hub: fix power good delay timing Stephen Warren
2014-05-19 20:21 ` [U-Boot] [PATCH 2/2] usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY Stephen Warren
2014-06-03 16:17 ` Tim Harvey
2014-06-03 16:38 ` Stephen Warren [this message]
2014-06-03 17:38 ` Marek Vasut
2014-06-03 18:11 ` Tim Harvey
2014-05-29 21:25 ` [U-Boot] [PATCH 1/2] usb: hub: fix power good delay timing Stephen Warren
2014-06-01 17:20 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=538DFA06.7040805@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox