| Message ID | 1371206502-6031-1-git-send-email-jilin@nvidia.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Warren |
| Headers | show |
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
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
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
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
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
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
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
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. -----------------------------------------------------------------------------------
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
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
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
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.
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
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
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
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.
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.
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...
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"),
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(-)