On Tue, Jun 3, 2014 at 9:38 AM, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 06/03/2014 10:17 AM, Tim Harvey wrote: >> On Mon, May 19, 2014 at 1:21 PM, Stephen Warren <swar...@wwwdotorg.org> >> wrote: >>> From: Stephen Warren <swar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
