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

login
register
mail settings
Submitter Jim Lin
Date June 14, 2013, 10:41 a.m.
Message ID <1371206502-6031-1-git-send-email-jilin@nvidia.com>
Download mbox | patch
Permalink /patch/251325/
State Superseded
Delegated to: Tom Warren
Headers show

Comments

Jim Lin - June 14, 2013, 10:41 a.m.
Add DT node for USB EHCI function.
Add support for T30-Cardhu, T30-Beaver, T114-Dalmore boards.

Signed-off-by: Jim Lin <jilin@nvidia.com>
---
 arch/arm/dts/tegra114.dtsi            |   27 +++++++++++++++++++++++++++
 arch/arm/dts/tegra30.dtsi             |   27 +++++++++++++++++++++++++++
 board/nvidia/dts/tegra114-dalmore.dts |    7 +++++++
 board/nvidia/dts/tegra30-beaver.dts   |    6 ++++++
 board/nvidia/dts/tegra30-cardhu.dts   |    6 ++++++
 include/fdtdec.h                      |    2 ++
 lib/fdtdec.c                          |    2 ++
 7 files changed, 77 insertions(+), 0 deletions(-)
Thierry Reding - June 14, 2013, 7:31 p.m.
On Fri, Jun 14, 2013 at 06:41:40PM +0800, Jim Lin wrote:
> Add DT node for USB EHCI function.
> Add support for T30-Cardhu, T30-Beaver, T114-Dalmore boards.
> 
> Signed-off-by: Jim Lin <jilin@nvidia.com>

Hi Jim,

none of the patches in this series have a changelog that list the
changes between v1 to v2. It's customary to include one between the
separator and the diffstat (as pointed out below). That makes it easier
for people reviewing or testing your patches because they know what to
look for or test.

> ---

Changelog goes here.

>  arch/arm/dts/tegra114.dtsi            |   27 +++++++++++++++++++++++++++
>  arch/arm/dts/tegra30.dtsi             |   27 +++++++++++++++++++++++++++
>  board/nvidia/dts/tegra114-dalmore.dts |    7 +++++++
>  board/nvidia/dts/tegra30-beaver.dts   |    6 ++++++
>  board/nvidia/dts/tegra30-cardhu.dts   |    6 ++++++
>  include/fdtdec.h                      |    2 ++
>  lib/fdtdec.c                          |    2 ++
>  7 files changed, 77 insertions(+), 0 deletions(-)

Thierry
Marek Vasut - June 15, 2013, 12:38 p.m.
Dear Thierry Reding,

> On Fri, Jun 14, 2013 at 06:41:40PM +0800, Jim Lin wrote:
> > Add DT node for USB EHCI function.
> > Add support for T30-Cardhu, T30-Beaver, T114-Dalmore boards.
> > 
> > Signed-off-by: Jim Lin <jilin@nvidia.com>
> 
> Hi Jim,
> 
> none of the patches in this series have a changelog that list the
> changes between v1 to v2. It's customary to include one between the
> separator and the diffstat (as pointed out below). That makes it easier
> for people reviewing or testing your patches because they know what to
> look for or test.

Good point. Unless anyone is against this patchset, I'll pick it after I know 
what changed in this version.

Best regards,
Marek Vasut
Marek Vasut - June 15, 2013, 7:46 p.m.
Dear Jim Lin,

> Add DT node for USB EHCI function.
> Add support for T30-Cardhu, T30-Beaver, T114-Dalmore boards.

I'd like to get ACK from someone with the actual hardware.

btw. How usable is the cardhu with current U-Boot ? That's the ASUS TF700, 
right? How can I install U-Boot on it, is there any howto?

Best regards,
Marek Vasut
Thierry Reding - June 15, 2013, 9:25 p.m.
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@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?

Thierry
Marek Vasut - June 15, 2013, 9:28 p.m.
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@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.

Best regards,
Marek Vasut
Thierry Reding - June 16, 2013, 10:30 a.m.
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@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.

Thierry
Marek Vasut - June 16, 2013, 8:48 p.m.
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@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.

Best regards,
Marek Vasut
Jim Lin - June 17, 2013, 3:07 a.m.
On Sun, 2013-06-16 at 03:46 +0800, Marek Vasut wrote:
> Dear Jim Lin,
> 
> > Add DT node for USB EHCI function.
> > Add support for T30-Cardhu, T30-Beaver, T114-Dalmore boards.
> 
> I'd like to get ACK from someone with the actual hardware.
> 
> btw. How usable is the cardhu with current U-Boot ? That's the ASUS TF700, 
> right? How can I install U-Boot on it, is there any howto?
I know nothing about ASUS TF700.
The T30-Cardhu board I have is a demo board.




-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Thierry Reding - June 17, 2013, 10:23 a.m.
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@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
Thierry Reding - June 17, 2013, 10:31 a.m.
On Sat, Jun 15, 2013 at 09:46:19PM +0200, Marek Vasut wrote:
> Dear Jim Lin,
> 
> > Add DT node for USB EHCI function.
> > Add support for T30-Cardhu, T30-Beaver, T114-Dalmore boards.
> 
> I'd like to get ACK from someone with the actual hardware.
> 
> btw. How usable is the cardhu with current U-Boot ? That's the ASUS TF700, 
> right? How can I install U-Boot on it, is there any howto?

I don't think Cardhu and TF700 are the same hardware. I'm not familiar
with the TF700, but if you have access to the recovery mode you should
be able to put mainline U-Boot on it using documentation found here:

	ftp://download.nvidia.com/tegra-public-appnotes/index.html

There's also a pretty new tool to perform almost all of the required
steps automatically:

	https://github.com/NVIDIA/tegra-uboot-flasher-scripts

You should follow the instructions in the README-developer.txt to get
started.

But given that the hardware might not be the same as Cardhu, I'm not
sure you can actually run mainline U-Boot on it. I don't suppose the
schematics for the TF700 are available anywhere? =)

Thierry
Marek Vasut - June 17, 2013, 8:39 p.m.
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@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.

Best regards,
Marek Vasut
Stephen Warren - June 17, 2013, 9:16 p.m.
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@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.
Thierry Reding - June 18, 2013, 10:58 a.m.
On Mon, Jun 17, 2013 at 10:39:12PM +0200, 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@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.

I should repeat that things work fine for a more recent flash drive, so
it doesn't look all that bad. Bisecting will be difficult because the
patches for Tegra30 haven't been merged upstream yet. Also I can't tell
for sure if this particular flash driver ever worked as expected since
I've never tried it before.

Given that I have limited time over the next few weeks, I'll see if I
can come up with a successful bisection. If I do I'll let you know.

Thierry
Marek Vasut - June 18, 2013, 11:28 a.m.
Dear Thierry Reding,

> On Mon, Jun 17, 2013 at 10:39:12PM +0200, 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@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.
> 
> I should repeat that things work fine for a more recent flash drive, so
> it doesn't look all that bad. Bisecting will be difficult because the
> patches for Tegra30 haven't been merged upstream yet. Also I can't tell
> for sure if this particular flash driver ever worked as expected since
> I've never tried it before.
> 
> Given that I have limited time over the next few weeks, I'll see if I
> can come up with a successful bisection. If I do I'll let you know.

You can try checking 2013.01, I recall merging some usb-storage related changes 
after that release.

Best regards,
Marek Vasut
Marek Vasut - June 18, 2013, 11:29 a.m.
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@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?

Best regards,
Marek Vasut
Stephen Warren - June 18, 2013, 3:34 p.m.
On 06/18/2013 04:58 AM, Thierry Reding wrote:
> On Mon, Jun 17, 2013 at 10:39:12PM +0200, Marek Vasut wrote:
...
>> 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.
> 
> I should repeat that things work fine for a more recent flash
> drive, so it doesn't look all that bad. Bisecting will be difficult
> because the patches for Tegra30 haven't been merged upstream yet.
> Also I can't tell for sure if this particular flash driver ever
> worked as expected since I've never tried it before.

You can easily cherry-pick changes on top of each commit while you're
doing a bisect to add the board support in if you need; just be
careful to say "git bisect good|bad
the_commit_which_git_bisect_told_me_to_test" where
"the_commit_which_git_bisect_told_me_to_test" is before the
cherry-picks you did.

Doesn't the problem happen on a Tegra20 board though; it might be easier
to test there since no cherry-picks would be needed.
Stephen Warren - June 18, 2013, 3:35 p.m.
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@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.
Stephen Warren - June 18, 2013, 10:59 p.m.
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@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...

Patch

diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index f86d18d..f87d05a 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -216,4 +216,31 @@ 
 		clocks = <&tegra_car 15>;
 		status = "disable";
 	};
+
+	usb@7d000000 {
+		compatible = "nvidia,tegra114-ehci";
+		reg = <0x7d000000 0x4000>;
+		interrupts = <52>;
+		phy_type = "utmi";
+		clocks = <&tegra_car 22>;	/* PERIPH_ID_USBD */
+		status = "disabled";
+	};
+
+	usb@7d004000 {
+		compatible = "nvidia,tegra114-ehci";
+		reg = <0x7d004000 0x4000>;
+		interrupts = <53>;
+		phy_type = "utmi";
+		clocks = <&tegra_car 58>;	/* PERIPH_ID_USB2 */
+		status = "disabled";
+	};
+
+	usb@7d008000 {
+		compatible = "nvidia,tegra114-ehci";
+		reg = <0x7d008000 0x4000>;
+		interrupts = <129>;
+		phy_type = "utmi";
+		clocks = <&tegra_car 59>;	/* PERIPH_ID_USB3 */
+		status = "disabled";
+	};
 };
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index ccf154f..e5275c2 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -216,4 +216,31 @@ 
 		clocks = <&tegra_car 15>;
 		status = "disabled";
 	};
+
+	usb@7d000000 {
+		compatible = "nvidia,tegra30-ehci";
+		reg = <0x7d000000 0x4000>;
+		interrupts = <52>;
+		phy_type = "utmi";
+		clocks = <&tegra_car 22>;	/* PERIPH_ID_USBD */
+		status = "disabled";
+	};
+
+	usb@7d004000 {
+		compatible = "nvidia,tegra30-ehci";
+		reg = <0x7d004000 0x4000>;
+		interrupts = <53>;
+		phy_type = "utmi";
+		clocks = <&tegra_car 58>;	/* PERIPH_ID_USB2 */
+		status = "disabled";
+	};
+
+	usb@7d008000 {
+		compatible = "nvidia,tegra30-ehci";
+		reg = <0x7d008000 0x4000>;
+		interrupts = <129>;
+		phy_type = "utmi";
+		clocks = <&tegra_car 59>;	/* PERIPH_ID_USB3 */
+		status = "disabled";
+	};
 };
diff --git a/board/nvidia/dts/tegra114-dalmore.dts b/board/nvidia/dts/tegra114-dalmore.dts
index 86e9459..435c01e 100644
--- a/board/nvidia/dts/tegra114-dalmore.dts
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -14,6 +14,7 @@ 
 		i2c4 = "/i2c@7000c700";
 		sdhci0 = "/sdhci@78000600";
 		sdhci1 = "/sdhci@78000400";
+		usb0 = "/usb@7d008000";
 	};
 
 	memory {
@@ -61,4 +62,10 @@ 
 		bus-width = <8>;
 		status = "okay";
 	};
+
+	usb@7d008000 {
+		/* SPDIF_IN: USB_VBUS_EN1 */
+		nvidia,vbus-gpio = <&gpio 86 0>;
+		status = "okay";
+	};
 };
diff --git a/board/nvidia/dts/tegra30-beaver.dts b/board/nvidia/dts/tegra30-beaver.dts
index 836169f..b003ae1 100644
--- a/board/nvidia/dts/tegra30-beaver.dts
+++ b/board/nvidia/dts/tegra30-beaver.dts
@@ -14,6 +14,7 @@ 
 		i2c4 = "/i2c@7000c700";
 		sdhci0 = "/sdhci@78000600";
 		sdhci1 = "/sdhci@78000000";
+		usb0 = "/usb@7d008000";
 	};
 
 	memory {
@@ -68,4 +69,9 @@ 
 		status = "okay";
 		bus-width = <8>;
 	};
+
+	usb@7d008000 {
+		nvidia,vbus-gpio = <&gpio 61 3>; /* PH5, USB13_VBUS_PULLUP */
+		status = "okay";
+	};
 };
diff --git a/board/nvidia/dts/tegra30-cardhu.dts b/board/nvidia/dts/tegra30-cardhu.dts
index 4d22b48..071a464 100644
--- a/board/nvidia/dts/tegra30-cardhu.dts
+++ b/board/nvidia/dts/tegra30-cardhu.dts
@@ -14,6 +14,7 @@ 
 		i2c4 = "/i2c@7000c700";
 		sdhci0 = "/sdhci@78000600";
 		sdhci1 = "/sdhci@78000000";
+		usb0 = "/usb@7d008000";
 	};
 
 	memory {
@@ -63,4 +64,9 @@ 
 		status = "okay";
 		bus-width = <8>;
 	};
+
+	usb@7d008000 {
+		nvidia,vbus-gpio = <&gpio 233 3>;	/* PDD1, EN_3V3_PU */
+		status = "okay";
+	};
 };
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 4e8032b..d19b9f3 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -64,6 +64,8 @@  struct fdt_memory {
 enum fdt_compat_id {
 	COMPAT_UNKNOWN,
 	COMPAT_NVIDIA_TEGRA20_USB,	/* Tegra20 USB port */
+	COMPAT_NVIDIA_TEGRA30_USB,	/* Tegra30 USB port */
+	COMPAT_NVIDIA_TEGRA114_USB,	/* Tegra114 USB port */
 	COMPAT_NVIDIA_TEGRA114_I2C,	/* Tegra114 I2C w/single clock source */
 	COMPAT_NVIDIA_TEGRA20_I2C,	/* Tegra20 i2c */
 	COMPAT_NVIDIA_TEGRA20_DVC,	/* Tegra20 dvc (really just i2c) */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index ac1fe0b..ffc4369 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -37,6 +37,8 @@  DECLARE_GLOBAL_DATA_PTR;
 static const char * const compat_names[COMPAT_COUNT] = {
 	COMPAT(UNKNOWN, "<none>"),
 	COMPAT(NVIDIA_TEGRA20_USB, "nvidia,tegra20-ehci"),
+	COMPAT(NVIDIA_TEGRA30_USB, "nvidia,tegra30-ehci"),
+	COMPAT(NVIDIA_TEGRA114_USB, "nvidia,tegra114-ehci"),
 	COMPAT(NVIDIA_TEGRA114_I2C, "nvidia,tegra114-i2c"),
 	COMPAT(NVIDIA_TEGRA20_I2C, "nvidia,tegra20-i2c"),
 	COMPAT(NVIDIA_TEGRA20_DVC, "nvidia,tegra20-i2c-dvc"),