[U-Boot] [PATCH v2 1/3] ARM: Tegra: FDT: Add USB EHCI function for T30/T114

[Stephen Warren]

On 06/16/2013 04:30 AM, Thierry Reding wrote:
> On Sat, Jun 15, 2013 at 11:28:25PM +0200, Marek Vasut wrote:
>> Dear Thierry Reding,
>> 
>>> On Fri, Jun 14, 2013 at 06:41:40PM +0800, Jim Lin wrote: [...]
>>> 
>>>> diff --git a/board/nvidia/dts/tegra30-beaver.dts 
>>>> b/board/nvidia/dts/tegra30-beaver.dts
>>> 
>>> [...]
>>> 
>>>> @@ -68,4 +69,9 @@
>>>> 
>>>> status = "okay"; bus-width = <8>;  };
>>>> 
>>>> + +	usb at 7d008000 { +		nvidia,vbus-gpio = <&gpio 61 3>; /*
>>>> PH5, USB13_VBUS_PULLUP */
>>> 
>>> This doesn't work for me on Beaver. I need to turn the above
>>> line into this:
>>> 
>>> nvidia,vbus-gpio = <&gpio 236 0>; /* PDD4 */
>>> 
>>> PDD4 is the correct GPIO according to the schematics and the
>>> pin is high-active. Also as far as I can tell, 3 is not a
>>> meaningful value for the U-Boot GPIO bindings. Only the value 1
>>> (low-active) is used.
>>> 
>>> With that change applied on top of your patches I can see that
>>> a USB flash drive connected to USB3 is indeed powered. However
>>> I noticed something strange. When I try to use USB, I get
>>> this:
>>> 
>>> Tegra30 (Beaver) # usb start (Re)start USB... USB0:
>>> set_host_mode: GPIO 236 high USB EHCI 1.00 scanning bus 0 for
>>> devices... 1 USB Device(s) found scanning usb for storage
>>> devices... 0 Storage Device(s) found scanning usb for ethernet
>>> devices... 0 Ethernet Device(s) found
>>> 
>>> So no storage device is detected, even though a USB flash drive
>>> is connected and powered properly. If I repeat the same
>>> command, however, the storage device is detected:
>>> 
>>> Tegra30 (Beaver) # usb reset (Re)start USB... USB0:
>>> set_host_mode: GPIO 236 high USB EHCI 1.00 scanning bus 0 for
>>> devices... 2 USB Device(s) found scanning usb for storage
>>> devices... 1 Storage Device(s) found scanning usb for ethernet
>>> devices... 0 Ethernet Device(s) found
>>> 
>>> Any idea what might be going on here?
>> 
>> Try waiting a little after setting the GPIO maybe? The drive
>> might need some time to settle.
> 
> I can make it work on the first invocation of "usb start" by adding
> a rather long mdelay() at the very end of ehci_hcd_init() in the
> Tegra EHCI driver. The magic value seems to be 853 ms. 852 ms
> wasn't enough in any of the test runs. 853 ms always worked.
> 
> However 850+ ms seems like a very long time for the device to
> settle, and keeping it in the driver probably isn't a good idea.
> Furthermore I cannot reproduce the same issue with a newer flash
> drive, which works fine with no additional delays.

Interesting. I see this exact same issue on Dalmore (Tegra114) with my
SD card reader too. I tried inserting a 1000ms delay at the end of
ehci_hcd_init() and that solves the problem for me too.

I already have 020bbcb "usb: hub: Power-cycle on root-hub ports"
reverted locally, although when I reverted it, IIRC there was a
conflict, so it's possible I just hacked around that and ended up
reverting all/part of 0bf796f "usb: hub: Parallelize power-cycling of
root-hub ports" too; see my branch at:

git://github.com:swarren/u-boot.git mainline_dev

... if you want to see the revert (about 8 commits down).

Another interesting aspect to this: An NVIDIA intern is trying to get
the Linux Tegra USB driver working on Tegra114. All the devices we've
tried except this SD card reader work fine with that driver, so
there's obviously something quirky with it. However, once I've run
"usb start" twice in U-Boot, or added the mdelay() to U-Boot and run
"usb start" once in U-Boot, then the kernel driver works with the
problematic SD card reader...