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

[Stephen Warren]

On 06/18/2013 05:29 AM, Marek Vasut wrote:
> Dear Stephen Warren,
> 
>> On 06/17/2013 02:39 PM, Marek Vasut wrote:
>>> Dear Thierry Reding,
>>>
>>>> On Sun, Jun 16, 2013 at 10:48:45PM +0200, Marek Vasut wrote:
>>>>> Dear Thierry Reding,
>>>>>
>>>>>> 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.
>>>>>
>>>>> Try reverting 020bbcb "usb: hub: Power-cycle on root-hub ports" ...
>>>>> there's a thread in the ML that it caused issues.
>>>>
>>>> I reverted the following two patches:
>>>> 	0bf796f usb: hub: Parallelize power-cycling of root-hub ports
>>>> 	020bbcb usb: hub: Power-cycle on root-hub ports
>>>>
>>>> because it wasn't trivial to revert only 020bbcb alone. However it
>>>> didn't change anything regarding the problem I was seeing.
>>>>
>>>> Thierry
>>>
>>> Ok, this looks ugly and calls for a bisect. Can you check it ? I'll try
>>> to test if USB works for me on some EHCI-enabled device.
>>
>> The problem is definitely caused by 020bbcb "usb: hub: Power-cycle on
>> root-hub ports"; I reverted just that locally and it fixed my problems.
> 
> Even this one ? Did we already get any reply from the patch author?

Oh, it's possible this is a different symptom, although I'd wager since
it's narrowed down to a patch that's known to cause another problem
already, it's the same patch that caused it, but yes that should be
verified explicitly.

No, I haven't heard anything at all from the patch author.